2 Byte zuviel vor Paketen

[Togus]

Hallo zusammen,
also ich habe auf einem Rechner FreeBSD installiert und wollte das System in mein bestehendes Netzwerk einhängen. Die Konfiguration der Netzwerkkarte (eine Davicom, die von dc unterstützt wird) usw. lief tadellos. Dann kam der erste versuch vom BSD-System auf ein Linux-System zu pingen - er scheiterte... Dann versuchte ich es andersherum und es klappte. Die Frage war nun: wieso kann ich von der einen Seite den Rechner apingen, der Rechner kann aber nicht mit dem Netz kommunizieren. Die Lösung fand sich dann bei der Analyse der gesendeten Pakete:
Das FreeBSD-System schickt vor dem Frame-Header (also noch vor der Destination-Mac) 2 Byte. Dadurch wird natürlich die Interpretation des Paketes vollkommen verhauen. Der Beginn der Mac-Adresse liegt nicht mehr beim 1. gesendeten Byte, sondern beim 3. gesendeten Byte und der IP-Header beginnt nicht beim 15. Byte, sondern beim 17. ... Das Netzwerk verwirft diese Pakete natürlich direkt, da sich niemand findet mit der angegebenen MAC/IP. Das witzige ist blos, dass beim Echo-Reply des Systems das BSD richtige Pakete verwendet, 14 Byte Frame-Header, der mit der Destination-Mac beginnt usw. Das gleiche Problem liegt beim Versuch vor, mit anderen Programmen als dem Ping Programm auf das Netz zuzugreifen (z.B. eine FTP-Verbindung).
Die Frage ist nun: woher kommen die 2 überflüssigen Byte (die wie ein zusätzlicher Header wirken) am anfang der Pakete und vor allem wie beseitige ich sie?

 

[asg]

Auf was ist denn "mtu" gesetzt?
Ausgabe von ifconfig, erste Zeile der NIC bitte posten.

 

[madCode]

Auch Hi,

im Internet haben viele Leute das Prob mit der komischen Karte.
Das der NIC Muell macht hast du krass konkret mitgesniffert ein Auszug aus:

http://www.freebsd.org/cgi/man.cgi?query=dc&sektion=4&manpath=FreeBSD+5.0-current

The 82c168 and 82c169 PNIC chips also have a receiver bug that sometimes
manifests during periods of heavy receive and transmit activity, where
the chip will improperly DMA received frames to the host.The chips
appear to upload several kilobytes of garbage data along with the
received frame data, dirtying several RX buffers instead of just the
expected one. The dc driver detects this condition and will salvage the
frame; however, it incurs a serious performance penalty in the process.

The PNIC chips also sometimes generate a transmit underrun error when the
driver attempts to download the receiver filter setup frame, which can
result in the receive filter being incorrectly programmed. The dc driver
will watch for this condition and requeue the setup frame until it is
transfered successfully.

Bevor ich mit dem Ding noch lange rumbasteln wuerde, wuerde ich mir fuer 10 Euronen nen anderen NIC kaufen und zur Tagesordnung uebergehen. Das Prob liegt nicht am dc Treiber generell sondern an dem Davidings im besonderen.

 

[Togus]

...

also die MTU ist es wohl sicher nicht :-)
werde mir dann mal gleich eine neue Karte holen, dann bin ich mal gespannt. Interessant ist aber wie gesagt, worum der echo reply einwandfrei funktionierte. Naja, wenn es nicht am Chip lag melde ich mich nochmal :-) Danke erstmal.

 

[asg]

Re: ...

Original geschrieben von Togus
also die MTU ist es wohl sicher nicht :-)
werde mir dann mal gleich eine neue Karte holen, dann bin ich mal gespannt. Interessant ist aber wie gesagt, worum der echo reply einwandfrei funktionierte. Naja, wenn es nicht am Chip lag melde ich mich nochmal :-) Danke erstmal.

Es wird wahrscheinlich an der Karte liegen, wenn man das so liest.
Wenn dem nicht so wäre würde ich immer noch auf eine falsche Angabe der MTU tippen.