USR-TCP232-T2 Module hat Jemand Erfarungen?

Holm T. schrieb:
> Hat Irgendwer Erfahrungen mit den Dingern?
Bisher nicht. Liegt hier rum und wartet auf den Einbau.

Was hast Du denn für Effekte?

Der TCP/IP Stack verhält sich teilweise seltsam, ich habe eine Art 
Packet-Krieg auf der Strippe, das USR Module sendet Connection Resets 
und mein BSD antwortet miteinem Zero Window Packet..worauf hin der USR 
Modul wieder ein Connection Reset schickt..das Ganze schaukelt sich auf.
Ich habe bei USR den Support kontaktiert, die haben mir eine neue 
Firmware gemacht die sich von der vorhergehenden nur darin unterscheidet 
das der USR Modul nicht mehr nach einer Weile abstürzt und neu bootet...

Gruß,
Holm

Ich bin jetzt dazugekommen das USR-TCP232-T2 Modul in mein Projekt zu 
integrieren. Ich möchte den Wandler im TCP-Server oder im 
UDP-Server-Mode betreiben.

Die Konfiguration wollte ich nicht mit dem Windows-Tool machen. Der 
erste Versuch war es, dem Ding ein paar Hexwert zu schicken (0x55 0xBD 
oder so).
Keine Reaktion, egal mit welcher Baudrate. Die Hexwerte muss man 
wahrscheinlich über die Netzwerkschnitt hinschicken.

Nächster Versuch: AT-Kommandos
Das funktionierte so wie in der Anleitung beschrieben ("+++" und dann 
ein 'a'), Schnittstelle auf 115200/8N1. Allerdings sind im Manual böse 
Copy&Paste-Fehler drin :-/
Trotz Konfiguration gab es keine Kommunikation.

Dritter Versuch: Die Weboberfläche. Die meldet sich mit Version v4016 
und man kann offensichtlich tatsächlich alles konfigurieren (im 
Gegensatz zur AT-Schnittstelle). Die Einstellungen werden scheinbar erst 
nach Restart gültig, aber die Kommunikation funktionierte. Auf der 
PC-Seite habe ich netcat verwendet. Das kann sowohl TCP als auch 
UDP-Kommunikation.
Heartbeat und das Löschen von alten TCP-Verbindungen habe ich 
deaktiviert.

Connection Resets konnte ich nicht beobachten, dafür stimmt beim 
ARP-reply die FCS nicht. Windows 7 nimmt das Paket trotzdem...

Ich habe die Module über den AT-Kommandosatz konfiguriert bekommen, man 
muß nur erst mal rausfinden was wo versteckt ist.

Die conenction Resets traten bei mir im TCP-Server Modus auf, wenn die 
Telnet (oder netcat) session auf einen Timeout lief und die Maschine ein 
FIN Paket schickte. Statt einer normalen Beendigung gabs dann ein 
Connection Reset..das FreeBSD isteressanter Weise mit einem Zero-Window 
beantwortet (weiß nicht warum)..was dann wieder von mit einem Connection 
Reset des Modules beantwortet wird ...das ging mit der originalen 
Firmware so lange bis der USR-Modul abstürzte und rebootete.
Ich habe eine neue Firmware erhalten, die stürzte nicht mehr ab, macht 
aber genau den selben Senf. Die Chinesen sehen nicht ein das ihr "a 
little nonstandard way" hier stört, angeblich würde sonst was Anderes 
nicht gehen.
Da ich aber zu Hause nicht den Blumentopf überwachen will sondern 1000 
Stück im Kundeneinsatz geplant waren war es das. Ich habe keine Ahnung 
was beim Kunden im Netzwerk läuft und ob ich den großen Laden damit lahm 
lege. Ich werde mir also was Anderes ausdenken müssen.

Meine Anfrage nach SPI Interface wurde verneint, auf deutsch übersetzt 
wären die User zu blöde das einzusetzen weil es zu kompliziert sei..ja 
nee, is klar.

Gruß,

Holm

Holm T. schrieb:
> Die conenction Resets traten bei mir im TCP-Server Modus auf, wenn die
> Telnet (oder netcat) session auf einen Timeout lief und die Maschine ein
> FIN Paket schickte. Statt einer normalen Beendigung gabs dann ein
> Connection Reset
Bei mir verhält sich das Ding unauffällig, ich habe mir das trotzdem 
nochmal angeschaut.
Ich bin jetzt mit TCP nicht so firm, aber das was im Wireshark zu sehen 
ist, sieht anders aus, als bei der Wikipedia:
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Verbindungsabbau

Zum einen ist das RST als Antwort auf FIN komisch und die Absende-IP des 
allerletzten ACK vom USR-TCP232-T2 ist völlig gaga.

Offenbar ist der TCP-Stack von Windows relativ tolerant (und der vom 
USR-TCP232-T2 teilweise broken).
Bei Gelegenheit schau ich mir das mal mit Linux an.