Sorry, erst mal nur Prosa..
ich habe die Aufgabe einen Sensor netzwerkfähig zu machen und habe mir dazu
einen USRIOT USR-TCP232-T 2 Modul gegriffen. Das Ding basiert auf einem Atmel SAM
mit irgend einem PHY (jetzt nicht im Kopf) und versteht mehrere Arbeitsmodi, u.A.
TCP Server mit einstellbarer Portnummer..quasi Telnet Server. Es transportiert die Daten
bidirektional zwischen der RS232 und dem Telnet Server... so weit so gut.
Bei den Modulen mit der Standardfirmwareversion stieß ich bald auf Probleme, die Dinger
starteten eine Art Paket Krieg auf dem Netzwerk, bis sie sich weg hängten und rebooteten.
Ich habe das angenörgelt und habe eine neue Firmware bekommen die sich nicht mehr
weghängt, das Paket-Krieg Problem bleibt aber bestehen.
Wireshark förderte in etwa zu Tage was passiert.
Wenn die Verbindung beendet wird (Timeout z.B.) und der FreeBSD Host ein FIN Paket sendet,
reagiert der USR Modul mit einem Connection Reset, darauf hin sendet FreeBSD ein Zero Window Paket,
also "kein Platz im Puffer"..worauf hin der USR Modul wieder mit einem "Connection Rest" reagiert,
worauf FreeBSD wieder mit eine Zero Window...
Abgesehen davon das es eine Unart ist das FIN Paket mit einem Reset zu beantworten, was soll der Scheiß
mit dem Zero Window den FreeBSD hier verzapft?
USRs Statement dazu ist das sie Reset senden weil sonst irgend eine andere Apllikation bei einem Kunden
oder was weiß ich nicht funktioniert. Warum aber sendet FreeBSD diese Zero Window Pakete? Beides zusammen
führt hier zu Ärger. Ein Windows (Vista) macht keine Probleme in der Hinsicht und der Paket-War bleibt aus.
Eine Anfrage auf freebsd-stable blieb unbeantwortet...hat hier eienr ne Idee?
Hier mal ein Link zu USRIOTs Ticket System..mein Fall, da habe ich auch Wireshark-dumps verlinkt:
(Vorsicht, der erste Link hat einen Tippfehler)
http://h.usriot.com/index.php?c=frontTicket&m=view&id=103324&key=2TA6OkVHjP4J
Gruß,
Holm
ich habe die Aufgabe einen Sensor netzwerkfähig zu machen und habe mir dazu
einen USRIOT USR-TCP232-T 2 Modul gegriffen. Das Ding basiert auf einem Atmel SAM
mit irgend einem PHY (jetzt nicht im Kopf) und versteht mehrere Arbeitsmodi, u.A.
TCP Server mit einstellbarer Portnummer..quasi Telnet Server. Es transportiert die Daten
bidirektional zwischen der RS232 und dem Telnet Server... so weit so gut.
Bei den Modulen mit der Standardfirmwareversion stieß ich bald auf Probleme, die Dinger
starteten eine Art Paket Krieg auf dem Netzwerk, bis sie sich weg hängten und rebooteten.
Ich habe das angenörgelt und habe eine neue Firmware bekommen die sich nicht mehr
weghängt, das Paket-Krieg Problem bleibt aber bestehen.
Wireshark förderte in etwa zu Tage was passiert.
Wenn die Verbindung beendet wird (Timeout z.B.) und der FreeBSD Host ein FIN Paket sendet,
reagiert der USR Modul mit einem Connection Reset, darauf hin sendet FreeBSD ein Zero Window Paket,
also "kein Platz im Puffer"..worauf hin der USR Modul wieder mit einem "Connection Rest" reagiert,
worauf FreeBSD wieder mit eine Zero Window...
Abgesehen davon das es eine Unart ist das FIN Paket mit einem Reset zu beantworten, was soll der Scheiß
mit dem Zero Window den FreeBSD hier verzapft?
USRs Statement dazu ist das sie Reset senden weil sonst irgend eine andere Apllikation bei einem Kunden
oder was weiß ich nicht funktioniert. Warum aber sendet FreeBSD diese Zero Window Pakete? Beides zusammen
führt hier zu Ärger. Ein Windows (Vista) macht keine Probleme in der Hinsicht und der Paket-War bleibt aus.
Eine Anfrage auf freebsd-stable blieb unbeantwortet...hat hier eienr ne Idee?
Hier mal ein Link zu USRIOTs Ticket System..mein Fall, da habe ich auch Wireshark-dumps verlinkt:
(Vorsicht, der erste Link hat einen Tippfehler)
http://h.usriot.com/index.php?c=frontTicket&m=view&id=103324&key=2TA6OkVHjP4J
Gruß,
Holm