komisches Netzwerkproblem mit IOT Modul..

holm

Well-Known Member
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
 
Schon
Code:
net.inet.tcp.drop_synfin: 0
per sysctl(8) auf
Code:
sysctl net.inet.tcp.drop_synfin= 1
gesetzt?
Code:
net.inet.tcp.syncache.rst_on_sock_fail: Send reset on socket allocation failure
net.inet.tcp.delacktime: Time before a delayed ACK is sent
net.inet.tcp.v6pmtud_blackhole_mss: Path MTU Discovery IPv6 Black Hole Detection lowered MSS
net.inet.tcp.pmtud_blackhole_mss: Path MTU Discovery Black Hole Detection lowered MSS
net.inet.tcp.pmtud_blackhole_failed: Path MTU Discovery Black Hole Detection, Failure Count
net.inet.tcp.pmtud_blackhole_activated_min_mss: Path MTU Discovery Black Hole Detection, Activation Count at min MSS
net.inet.tcp.pmtud_blackhole_activated: Path MTU Discovery Black Hole Detection, Activation Count
net.inet.tcp.pmtud_blackhole_detection: Path MTU Discovery Black Hole Detection Enabled
net.inet.tcp.sack.globalholes: Global number of TCP SACK holes currently allocated
net.inet.tcp.sack.globalmaxholes: Global maximum number of TCP SACK holes
net.inet.tcp.sack.maxholes: Maximum number of TCP SACK holes allowed per connection
net.inet.tcp.sack.enable: Enable/Disable TCP SACK support
net.inet.tcp.insecure_rst: Follow RFC793 instead of RFC5961 criteria for accepting RST packets
net.inet.tcp.insecure_syn: Follow RFC793 instead of RFC5961 criteria for accepting SYN packets
net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set
net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet
net.inet.tcp.blackhole: Do not send RST on segments to closed ports

Es transportiert die Daten
bidirektional zwischen der RS232 und dem Telnet Server... so weit so gut.

Wenn ich das Richtig verstehe, besteht eine PPP basierte Verbindung ueber eine serielle Leitung [UART, etc., ...] zwischen Host und Sensor oder basiert der Zugang zum Broadcastmedia auf Ethernet, wie in PR beschrieben?
 
Zuletzt bearbeitet von einem Moderator:
..nein, kein PPP.

Das Modul hat eine RS232 Schnittstelle und eine Ethernet Buchse, es enthält selbst den (closed Source) TCP/IP Stack.
Über die RS232 läuft nur ASCII Traffic.

sysctl net.inet.tcp.drop_synfin
net.inet.tcp.drop_synfin: 0
$

..hat aber IMHO damit nichts zu tun.

Das FreeBSD selbst sendet ein FIN Packet, daran habe ich nichts auszusetzten. Das USR Modul sendet ein Connection Reset ..daran kann ich nichts ändern, darauf hin sendet FreeBSD ein Packet mit Window Size=0, das nervt mich.

http://www.tiffe.de/images/tcpip.png

Gruß,

Holm
 
Wie krass [also das mit dem rst bzw. der "Support"]. :)

Ich guck mir gerade den Stack [Quellcode] an bzw. wiso das so ist.

Was spraeche dagegen, das IoT-Device durch eines von einem anderen Hersteller zu ersetzen?
 
..später mal ja. Ich habe aber erst mal 10 Stück davon da die nun auch noch auf selbst kreierten Subplatinen
sitzen auf denen nun noch eine SPI-UART (SC16C740) zur Ansteuerung des USR Moduls wohnt.
( Die Meinung von USRIOT zu SPI hast Du ja sicherlich gelesen, zu komplex für die avisierten Kunden...)

Ich würde mich längerfristig deshalb sowieso nach einer Lösung umsehen bei der ich auf die Quellen zurückgreifen
kann, aber momentan habe ich erst mal mit der eigentlichen Applikation genug zu tun, das sind auch bereits schon
ca 20000 Zeilen Code..

Gruß,

Holm
 
Mmmhhh, klingt spannend... :)

Fuer Networking und IoT, wuerde einen Blick auf NuttX zu werfen nicht wirklich schaden, da die Implementierung des Network-Stacks von NuttX der des BSD-Network-Stacks sehr "nahe" bzw. "aehnlich" ist.
 
$ netstat -m
258/7842/8100 mbufs in use (current/cache/total)
256/4530/4786/2041802 mbuf clusters in use (current/cache/total/max)
256/3539 mbuf+clusters out of packet secondary zone in use (current/cache)
0/740/740/1020901 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/302489 9k jumbo clusters in use (current/cache/total/max)
0/0/0/170150 16k jumbo clusters in use (current/cache/total/max)
576K/13980K/14557K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 sendfile syscalls
0 sendfile syscalls completed without I/O request
0 requests for I/O initiated by sendfile
0 pages read by sendfile as part of a request
0 pages were valid at time of a sendfile request
0 pages were requested for read ahead by applications
0 pages were read ahead by sendfile
0 times sendfile encountered an already busy page
0 requests for sfbufs denied
0 requests for sfbufs delayed
$ uname -a
FreeBSD atlas.tsht.lan 11.1-STABLE FreeBSD 11.1-STABLE #3 r327467: Tue Jan 2 23:43:52 CET 2018 r@atlas.tsht.lan:/usr/obj/usr/src/sys/ATLAS amd64
$



Gruß,

Holm
 
sorry, war ein paar Tage aus dem Rennen (Herzinfarkt Nr. 3), bin wieder da.

Ne, net.inet.tcp.rfc1323=0 ändert nix:

20:40:44.845939 IP atlas.34705 > fsnet-0.tsht.lan.2323: Flags [.], ack 4294967295, win 0, length 0
20:40:44.846451 IP fsnet-0.tsht.lan.2323 > atlas.34705: Flags [R.], seq 0, ack 1, win 2920, length 0
20:40:44.846462 IP atlas.34705 > fsnet-0.tsht.lan.2323: Flags [.], ack 4294967295, win 0, length 0
20:40:44.847006 IP fsnet-0.tsht.lan.2323 > atlas.34705: Flags [R.], seq 0, ack 1, win 2920, length 0
20:40:44.847017 IP atlas.34705 > fsnet-0.tsht.lan.2323: Flags [.], ack 4294967295, win 0, length 0
20:40:44.847535 IP fsnet-0.tsht.lan.2323 > atlas.34705: Flags [R.], seq 0, ack 1, win 2920, length 0
20:40:44.847544 IP atlas.34705 > fsnet-0.tsht.lan.2323: Flags [.], ack 4294967295, win 0, length 0
20:40:44.848086 IP fsnet-0.tsht.lan.2323 > atlas.34705: Flags [R.], seq 0, ack 1, win 2920, length 0
20:40:44.848093 IP atlas.34705 > fsnet-0.tsht.lan.2323: Flags [.], ack 4294967295, win 0, length 0
20:40:44.848609 IP fsnet-0.tsht.lan.2323 > atlas.34705: Flags [R.], seq 0, ack 1, win 2920, length 0

Ein ifconfig interface down und wieder up unterbricht das Gerödel auf dem Netz, es ist etwa eine Minute Ruhe bos das weiter geht...

Gruß,

Holm
 
sorry, war ein paar Tage aus dem Rennen (Herzinfarkt Nr. 3), bin wieder da.

Herzinfarkt??!?1 O.O .. oh weh, erstmal gute Besserung!

Ne, net.inet.tcp.rfc1323=0 ändert nix:

Wurde schon es mit
Code:
net.inet.tcp.insecure_rst: Follow RFC793 instead of RFC5961 criteria for accepting RST packets
Versucht?

Ich bin dabei mir die Code-base vom Networkstack [bzw. die FSM etwas genauer] zu betrachten, welche Version von FreeBSD wird verwendet?
 
Zuletzt bearbeitet von einem Moderator:
Danke für die Wünsche, aber ich habs gut überstanden, Alles Bestens.

Nach der FBSD Version hattest Du schon gefragt, 11.1 (stable und -Pirgendwas auf 2 Rechnern),
sieht man schon oben. Das insecure_rst versuche ich nachher.

Gruß,
Holm
 
Hmm, ich gehe mit double-p mit und vermute ebenso das tcp window scaling.
Wie sieht die Ausgabe der sysctls aus?
Code:
sysctl net.inet.tcp | grep send

Es könnte eventuell was bringen, net.inet.tcp.sendspace auf 2920 zu setzen und/oder net.inet.tcp.sendbuf_auto zu deaktivieren.
Ich weiß allerdings nicht, ob sich das direkt auf das window scaling auswirkt oder ob es da nur um Puffer im Stack geht.

Rob
 
Mmmmhhh, ...
Code:
net.inet.tcp.sendbuf_auto: Enable automatic send buffer sizing
sollte mMn unter Anderem vorsorglich ausgeschaltet werden, da wahrscheinlich bzgl. dem Callout-handling der FSM [im Zusammenhang eines gesendeten FIN] etwas sein koennte, da ich vermute, das etwas im Cache "haengengeblieben" ist, wobei ich mir noch nicht ganz sicher bin.

Ich reisze mich aber jetzt zusammen, da ich keinen Spam verursachen moechte, weil das Forum nicht mit nem Twitter-Account verwechselt werden moechte.
 
Zuletzt bearbeitet von einem Moderator:
Ergaenzung, siehe u. a. hier und dort, deswegen empfehle ich [vorerst], das
Code:
net.inet.tcp.sendbuf_auto: Enable automatic send buffer sizing
auszuschalten.
 
net.inet.tcp.sendspace: 32768
net.inet.tcp.sendbuf_max: 2097152
net.inet.tcp.sendbuf_inc: 8192
net.inet.tcp.sendbuf_auto: 1


..ich hatte gestern net.inet.tcp.hostcache.enable ausgeschaltet (ist wieder an) und hatte bisher das Problem noch nicht wieder, was zum Teil daran liegt das ich krank geschrieben bin und eher Lust hat meinen eigenen kaputten Oszi mal zu reparieren als
"dienstlich" in TCPIP Geschichten rum zu stochern ..sorry, ich hatte dann nicht mehr viel gemacht und den Quatsch laufen lassen, tut immer noch.
inet.inet.tcp.sendbuf_auto: 1 ist FreeBSDs Voreinstellung, daran habe ich nichts geschraubt, ich werde morgen die Kiste hier
aber mal rebooten und das mit dem sendbuf_auto checken..

Bin jetzt fertig mit dem Oszi und koche nen Kaffee :-))

Melde mich morgen, bis dahin vielen Dank.

Gruß,
Holm
 
..hat nun etwas länger gedauert..sorry.

# sysctl -w net.inet.tcp.sendbuf_auto=0
net.inet.tcp.sendbuf_auto: 1 -> 0
#

hilft leider auch nicht.
10:20:44.618490 IP fsnet-0.tsht.lan.2323 > atlas.60863: Flags [R.], seq 2, ack 6, win 2920, length 0
10:20:44.618496 IP atlas.60863 > fsnet-0.tsht.lan.2323: Flags [.], ack 1, win 0, length 0
10:20:44.618985 IP fsnet-0.tsht.lan.2323 > atlas.60863: Flags [R.], seq 2, ack 6, win 2920, length 0
10:20:44.618991 IP atlas.60863 > fsnet-0.tsht.lan.2323: Flags [.], ack 1, win 0, length 0
10:20:44.619480 IP fsnet-0.tsht.lan.2323 > atlas.60863: Flags [R.], seq 2, ack 6, win 2920, length 0
10:20:44.619488 IP atlas.60863 > fsnet-0.tsht.lan.2323: Flags [.], ack 1, win 0, length 0


Das Theater bleibt das Selbe.

Gruß,

Holm
 
In den Logs ist leider nichts zu finden was damit zu tun hätte, ich hätte sonst schon davon berichtet.

Ich habe "atlas" gestern auch mal neu gebootet da nach der Montage eines anderen USR-Netzwerkmoduls keien Verbindung zu diesem aufzunehmen war. Offensichtlich was auf Grund der spielerei an den verschiedenen Kernelparametern da irgendwas vergriesgnaddelt..

Gruß,

Holm
 
Zurück
Oben