Hallo, für den MIPS TTL Rechner: Beitrag "Space Age 2 der 32Bit MIPS Rechner in TTL" ist eine Netzwerkkarte in Planung. Bis auf PHY/FIFO/ROM alles in TTL. Dabei frage ich mich ob ich wirklich einen MAC Filter einbauen sollte. Jedenfalls soll die CPU so weit wie möglich entlastet werden, da diese nur mit 4MHz taktet und dann auchnoch mehrere Zyklen pro Instruktion braucht. Der MAC Filter besteht mal eben aus ~25 TTL ICs und wenn man die einsparen könnte ohne viel CPU Belastung, dann wär das schonmal gut. Nun ist son Switch ja eigentlich auch sone Art MAC Filter, der baut eine MAC Table auf und switcht die Pakete dann nurnoch passend durch (und Broadcasts). Also dürfen nach einer gewissen Zeit eh nurnoch passende Pakete ankommen. Daher die Frage ob MAC Filter: Ja/Nein/Villeicht/Kaffee ?
Mw E. schrieb: > Daher die Frage ob MAC Filter: MAC-Filter sind generell Unsinn. MACs lassen sich bei vielen Geräten leicht manipulieren. Und es genügt ja letztlich sogar ein einziges Gerät, bei dem das möglich ist, um das komplette Konzept ad absurdum zu führen...
Du weist nich worüber das Thema hier läuft ;) Die CPU soll einfach nur keine Pakete bekommen die nicht an sie gerichtet sind. Das hat nix mit MAC White/Black listing zu tun. Jede normale LAN Karte hat sonen MAC Filter eingebaut. (ist aber auch deaktivierbar durch zB Wireshark zum sniffen)
>Also dürfen nach einer gewissen Zeit eh nurnoch passende Pakete
ankommen.
Man kennt den promisc-Mode... Gilt nur für IPv4 (ARP-Modus).
Eine geheime MAC-Adresse macht für mich Sinn.
Mw E. schrieb: > Du weist nich worüber das Thema hier läuft ;) > > Die CPU soll einfach nur keine Pakete bekommen die nicht an sie > gerichtet sind. > Das hat nix mit MAC White/Black listing zu tun. > > Jede normale LAN Karte hat sonen MAC Filter eingebaut. > (ist aber auch deaktivierbar durch zB Wireshark zum sniffen) Aha, jetzt verstehe ich. Kann aber immer noch kein Problem erkennen. Jeder Switch macht das doch sowieso. Das angeschlossene Gerät bekommt nur genau die Pakete, die an es gerichtet sind. Zusätzlich Broadcast-Pakete, auf die man eher nicht verzichten möchte und ggf. Multicast-Pakete, deren Empfang allerdings erstmal aktiv konfiguriert werden müsste. Wo genau also ist dein Problem?
c-hater schrieb: > Jeder Switch macht das doch sowieso. Das angeschlossene Gerät bekommt > nur genau die Pakete, die an es gerichtet sind. Nein, das ist nicht so. Pakete an dem Switch bisher unbekannte Geräte gehen auch an alle raus. Das weiß der TO aber schon.
Bill G. schrieb: > Nein, das ist nicht so. Pakete an dem Switch bisher unbekannte Geräte > gehen auch an alle raus. Welche völlig verschissene Fehlkonstruktion von einem Switch macht denn das? Das ergibt doch absolut keinen Sinn.
Das sollte jeder Switch so machen. Der Switch weiß ja nicht automatisch, welche Geräte alle am anderen Ende des Kabels hängen. Nehmen wir z.B. den folgenden Aufbau und nehmen an, dass alle MACs erstmal bekannt sind: A <-> Switch 1 <-> Switch 2 <-> B Jetzt hängst du ein neues Gerät C an Switch 2 an und sendest ein Paket von A an die MAC des neue Geräts. Switch 1 kennt die MAC von C (noch) nicht und kann somit nur über alle Ports weiterleiten und hoffen das das Paket ankommt. Sobald dann ein Paket von der MAC C kommt, kann der Switch den Port zur MAC zuordnen.
Mw E. schrieb: > ist eine Netzwerkkarte in Planung. Bis auf PHY/FIFO/ROM alles in TTL. Wahrscheinlich habt Ihr den Kern seiner Frage nicht verstanden? Er will seiner lahmen CPU unnütze Arbeit ersparen und filtert nur deswegen unerwünschte MACs schon VORHER aus. Bei mir sind noch Zweifel, ob diese CPU überhaupt flink genug ist, um heute im Netz zeitgerecht zu antworten. Evtl. kann er seine Erfindung modular aufbauen und später erst das MAC-Filter vorschalten wenn sicher ist, daß die CPU mit NUR einer MAC zeitmäßig ordentlich funktioniert. z.B. Test mit Nullmodemkabel?
Ntldr -. schrieb: > Das sollte jeder Switch so machen. Der Switch weiß ja nicht automatisch, > welche Geräte alle am anderen Ende des Kabels hängen. Das braucht er auch nicht zu wissen. Eben dafür gibt es ja die Broadcasts. > Jetzt hängst du ein neues Gerät C an Switch 2 an und sendest ein Paket > von A an die MAC des neue Geräts. Switch 1 kennt die MAC von C (noch) > nicht und kann somit nur über alle Ports weiterleiten und hoffen das das > Paket ankommt. Sobald dann ein Paket von der MAC C kommt, kann der > Switch den Port zur MAC zuordnen. In der Realität vernünftiger Switches läuft das ganz anders. Ein unicast-Paket an eine unbekannte MAC landet grundsätzlich anstandslos im Orcus. Der Absender hat sich darum zu kümmern, dass die Switches Bescheid wissen. Das passiert normalerweise dadurch, dass er einen Broadcast versendet. Will er mit dem Peer z.B. auf IPisch labern, wäre das ein ARP-"who has"-Broadcast. Der Peer hat dazu natürlich einen ARP-"Server" zu laufen zu haben, der auf den Broadcast mit einem ARP "is at" antwortet. Diese Antwort ist dann schon unicast und vertellt nebenbei allen Switches auf dem Weg des Paketes, über welchen Port der Schlingel jeweils aus ihrer Sicht zu erreichen ist, denn dieses Paket enthält die MAC des Peers und die Switches nehmen die freundlich in ihre höchst volatile Liste bekannter MACs auf. Und nach z.B. drei Minuten ohne Kommunikation geht die Sache wegen der Volatilität gern wieder ganz von vorn los,.. Für andere Protokollfamilien gibt es andere Discovery-Protokolle, aber alle haben gemeinsam, dass sie letztlich auf einen Broadcast aufsetzen.
GuteTack schrieb: > Man kennt den promisc-Mode... Gilt nur für IPv4 (ARP-Modus). hä? promisc leitet einfach alles Frames durch und arbeitet nur auf MAC-Level.. Im Normalfall sollte dein MAC im Non-Promisc mode arbeiten, womit er nur Frames empfängt, die die Destination-MAC von dir haben oder Broadcast/Multicast sind. Falls das nicht ist, dann bau ein Filter das diese genannten durchlässt und den Rest rauswirft.
oszi40 schrieb: > Wahrscheinlich habt Ihr den Kern seiner Frage nicht verstanden? Er will > seiner lahmen CPU unnütze Arbeit ersparen und filtert nur deswegen > unerwünschte MACs schon VORHER aus. Nö, das habe ich nach der ersten Iteration schon verstanden. Der Punkt ist nur: das ist unnötig. Der Mann hat nur einfach keine Ahnung davon, wie Ethernet-Netzwerke heute (eigentlich: seit Jahrzehnten) funktionieren, deshalb ist ihm nicht klar, dass es vollkommen unnötig ist. Ich habe nur immer ziemliches Darmgrummeln, wenn Leute mit derart rudimentären Netzwerkkenntnissen irgendwas mit Netzwerk machen. Da kann doch nur Scheiße bei rauskommen...
Statt eines vollstaendigen MAC-Filter, koennte man ein rudimentaeres implementieren, dass nur auf den Hersteller-Part filtert. Passend gewaehlt sollte das auch reichen.
> Darmgrummeln Er wird wissen was er tut, wenn man sein bisheriges CPU-Projekt gesehen hat. Den Link der Netzmafia hat er bestimmt auch schon gefunden. http://www.netzmafia.de/skripten/netze/netz8.html
oszi40 schrieb: >> Darmgrummeln > > Er wird wissen was er tut, wenn man sein bisheriges CPU-Projekt gesehen > hat. Das ist zu bezweifeln. Wer sich mit solch rückwärtsgewandten Projekten beschäftigt, der hat wohl Probleme, was aktuelles, nützliches zu schreiben. Das ist als Hobby natürlich vollkommen akzeptabel. Ich wäre der letzte, der das verbieten wollen würde. Solange es ihm Spaß macht: why not. Aber selbst wenn seine CPU perfekt funktioniert, sagt das rein garnix über die Kompetenz z.B. bezüglich Netzwerkprotokollen aus. Selbst wenn es eine aktuelle CPU wäre, die er da abbildet, würde das immer noch nix über seine Netzwerk-Kompetenz aussagen. Sind einfach zwei Themen, die nur wenig bis nix miteinander zu tun haben.
c-hater schrieb: > solch rückwärtsgewandten Projekten Jedenfalls haben die dabei praktisch mehr gelernt, als Andere nur mit dem neuen Handy daddeln können und für jede Schraube eindrehen eine 100MB-App brauchen. Der TO muß äußerst sparsam mit CPU-Takten und RAM umgehen, was viele hier schon verlernt haben. Lassen wir ihn doch einfach neue Erkenntnisse gewinnen (solange er nicht unser Netz versaut).
Jaja der c-hater, immer nur dumme Sprüche und nix dahinter ;) Zudem nennt man das Hobby da kann man mal in der TTL Spielkiste kramen. Gepflegt ATEX Geräte entwickeln kann ich auf arbeit. oszi40 schrieb: > Bei mir sind noch Zweifel, ob diese > CPU überhaupt flink genug ist, um heute im Netz zeitgerecht zu > antworten. Also für HTTPS wirds garantiert nicht reichen, aber ein HTTP und FTP Server soll schon drauf laufen. Der PHY wird auch fest auf 10mbit/s fullduplex gebootstrapped. 2,5MHz am MII sind handlebar, die 25MHz für 100mbit/s in TTL eher nicht. oszi40 schrieb: > Evtl. kann er seine Erfindung modular aufbauen und später > erst das MAC-Filter vorschalten wenn sicher ist, daß die CPU mit NUR > einer MAC zeitmäßig ordentlich funktioniert. Ne Erfindung isses ja nu nich grade. Aber nachrüstbar wär eine Idee, das Interface würde sich ohne MAC Filter nicht ändern. Wenn dann doch noch zu viel durchkommt vom Switch, aber das sehe ich erstmal nicht kommen. pumuggl schrieb: > Statt eines vollstaendigen MAC-Filter, koennte man ein > rudimentaeres implementieren, dass nur auf den Hersteller-Part > filtert. Passend gewaehlt sollte das auch reichen. Das wäre auch mit dem Nachrüstkonzept möglich. Es wäre auch möglich nur aufs LSByte der MAC zu Filtern, dann ist auch schon genug weg, aber die kommt ja leider erst zum Ende und der Anfang soll nicht in die FIFO solange. Der Kern der Frage war ja ob ich schummeln darf durch weglassen. So ziemlich jede Netzwerkkarte hat diesen Filter, dass nur auf Broadcast und der eigenen MAC gelauscht wird. Aber das ist auch ein Überbleibsel aus den Hub Zeiten. -> Ich lass ihn weg, aber er ist nachrüstbar wenns zu Problemen kommt.
oszi40 schrieb: > Jedenfalls haben die dabei praktisch mehr gelernt, als Andere nur mit > dem neuen Handy daddeln können und für jede Schraube eindrehen eine > 100MB-App brauchen. Sicher. Nur halt nix über Netzwerke. Und genau nur das war wohl Thema des Threads hier... > Der TO muß äußerst sparsam mit CPU-Takten und RAM > umgehen Mein Gott. Ich bin leidenschaftlicher Assembler-Programmierer, ich mache sehr oft genau sowas (meist nur zum Spass, öfters aber auch mal als bezahlte Dienstleistung). Mich brauchst du diesbezüglich jedenfalls ganz sicher nicht zu missionieren...
c-hater schrieb: > Mein Gott. Ich bin leidenschaftlicher Assembler-Programmierer, Soviel zu Rückwärtsgewandt weglach
>oszi40 Er wird wissen was er tut, wenn man sein bisheriges CPU-Projekt gesehen hat. Den Link der Netzmafia hat er bestimmt auch schon gefunden. http://www.netzmafia.de/skripten/netze/netz8.html Das glaube ich auch. Man muss praktisch arbeiten sonst verkommt das Gehirn. Ich mache Kopfrechnen und tatsächlich geht es mit den Jahren fehlerfrei und schnell. Einstein sagte "Gott ist im Detail" (nicht der Teufel). Die Konsumgesellschaft bringt uns um.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.