Může switch nebo router spojovat fragmenty TCP?

[mikesznovu]

TLDR: to sítě vstupují IP  pakety o délce 576, ale na počítač jdou o délce 576,1110,1624,2148 a 2672. matematicky to sedí, stačí odečíst 20, odečíst 32 a vydělit 524.

Všiml jsem si zvláštní věci, jde o normální DASH video přes HTTPS přes port 443-TCP přes IPv4, z české televize, které občas dělá problémy (někdy se přehrávání   webu zadrhne- pozoruji, že to je skoro vždy když  příchozí IP pakety o délce výhradně 576b chodí až do stroje, ale o tom to dnes nebude  ). přehrávalo se to teď ne na webu, ale v přehrávači videí, a všiml jsem si ,že conntrack na bráně ukazoval  350 řádků spojení k romuto serveru, ale nethogs, že aktivních jich bylo tak 10 (mezi 10 a 180 kB/s).
Síť: (wifi)brána(ethernet) ---  (ethernet)Wifi-AP(br0:wifi+eth) --- switch --- počítače

brána je RPi, wifi-ap je tzv. wifirouterkombo, už několik let staré, ale relativně vyšší střední třída s Gigabit porty, DSLWAN(deaktivovaným) a switch je  takový nejlevnější gigový 4portový .

Příchozí rámce  do brány mají délku 590b (14+20+32+ 524)b, bez těch 14 to je těch 576.
Poznámka TCP má hlavičku 32 b oproti normální 20 (ecn,ecr+padding).
Odchozí rámce z brány taky.
Příchozí rámce do počítače jsou modifikované, je to spektrum paketů o asi 5 vellikostech a nejpodivnější na tom je, že má i velikost přesahující 1500b.

Trochu ve stínu zustal wifi ap router, vše je zapojeno v LAN portech. Má sice programy ip, jádro 2.6 z roku 2016(?nesoulad), ale prihlašuju se na něj přes telnet. Nemá binárku conntrack, ale  shell sh a  příkaz cat /proc/net/nf_conntrack
 hlásí jen spojení na telnetu, takže se dá předpokládat že jenom bridguje. kromě toho iptables -L {nat,mangle,filter,raw} nic moc, mangle prázdný, raw neexistuje, nat prázdný . filter má nulové čítače kromě inputu. a input  má jen 24 MB dat na -i bridge -j ACCEPT a to asi taky nic není, takže asi jenom fakt bridguje ....

SWITCH:
Předpokládám, že stále platí, že switch maximálně ví, že podle ethertype to jsou IP pakety ale dál s nimi nic nedělá, o IP vrstvu, natož TCP se nestará . Je to hloupý switch bez managementu.

WIRESHARK:
Snad ani wireshark nedělá žádnou magii v prezentaci paketů. Nikde nemám nic jako  záložky Packet / reassembled frame,  ani. IP pakety nejsou fragmentované


Pakety jsem sniffoval přes wireshark, ale sekvenčně pokaždé na jiném konci. (Ideální by bylo souběžně na rozhraní any na všech prvcích.... a zkorelovat je, ale nejsem CSIRT )
Kromě toho je tam nějak modifikované WIN size u na vstupuju bylo něco kolem 500-650 ale u těch modifikovnaných na stanici je10880 .

Proč k některým zdrojům dojde v původní podobě  (jen 576)?
Druhá zvláštnost je MTU.... jakko kdyby neexistovalo., koncová stanice, brána mají v ip address uvedené MTU 1500, router taky(u bridge,eth i wifi)
na jakém prvku dochází k té změně?
Není to třeba tcp offloading, který právě tcpdump nemá šanci zachytit?

Někd nějaké nápady, jak zjistit, co a kde se děje?

[Reklama]

[Vantomas]

To dělá TCP offloading v síťovce. ethtool, parametr tso - tcp segmentation offload.

 

   To enable TSO for a network device eth0 issue:

    # ethtool -K eth0 tx on sg on tso on

    To disable TSO for a network device eth0 issue:

    # ethtool -K eth0 tx off sg off tso off

[mikesznovu]

Zajímavé.  Ale teď když o tom přemýšlím, to, že některé počítače přijímají 524b pakety vlastně říká že na výstupu jsou původní pakety a ta HW transformace se děje na některých  vybraných cílových PC.
Ještě jsem nekoukal na konfiguraci cílové stanice...  na ethtool

Ale po prostudování myslím, že to co hledám, je GRO/LRO .. Generic Receive / Large receive offload.
Jestli to chápu dobře podle popisu tso (TCP Segmentation offload nebo jinak Large Send offload), tak offloading je rozsekávání velkých chunků na malé, ale tady je opačná situace. (a pochybuju, že by mi zvenku chodily 4kB pakety) Na WAN mi chodí 590 rámce

[Vantomas]

Hmm, ano, možná je to GRO/LRO, vím, že tyhle featury existují a že v určitých usecasech můžou dělat potíže.

Jde o to, že přímo procesor síťovky umí poznat, že některé pakety k sobě patří a rovnou je spojí, aby se naplnil buffer hotovými daty a na jedno přerušení se to odbavilo jádru, který už vše dostane předpřipravené a nemusí nad tím pálit čas. V tomto případě se to projevuje tak, že Wireshark vidí pakety větší, než je MTU.

Popravdě netuším jaká je podpora napříč desktop/notebook chipsety, ale na serverech se s tím běžně setkávám u Intelů a Broadcomů. A zejména u toho Intelu bych čekal, že to bude umět i v těch desktopových modelech.

[Michal Kubeček]

1. TSO/GSO se týká odchozích paketů, v podstatě to funguje tak, že skoro celým síťovým stackem projde paket, který je co největší (může to být až skoro 64 KB), a nasegmentuje se až těsně před předáním síťové kartě (GSO) nebo až v ní (TSO). Naopak, GRO/LRO se týká příchozích paketů. LRO dělá přímo síťová karta, ale protože je příliš agresivní v tom, co pospojuje dohromady, nefunguje to dobře s některými protokoly a hlavně to téměř nikdy nefunguje, pokud se ten paket pošle někam dál, takže jádro v mnoha případech automaticky LRO vypíná. Proto vzniklo GRO, které dělá software hned na začátku a které je opatrnější, takže mimo jiné nerozbíjí forwarding (při forwardování se sice pakety virtuálně spojí dohromady, ale dál se forwardují ty původní). Některé nové (a chytřejší) síťové karty podporují i "hardware GRO", kdy jde sice o GRO, ale dělá ho karta.

2. Tak jako tak ale xSO/xRO funguje tak, že po síti běhají krátké pakety a jen uvnitř síťového stacku vidíme ty dlouhé. Protože ale segmentace probíhá až hodně pozdě a sloučení naopak hodně brzy, i libpcap (tcpdump, wireshark, ...) vidí ty dlouhé pakety. Proto je také běžné, že když se díváte na TCP spojení na obou koncích, vidíte na obou stranách dlouhé pakety, ale na každé straně jiné.

3. TSO je naprosto běžný standard i v levných NIC, LRO je taky celkem běžné, ale vzhledem k notorickým problémům s ním bývá defaultně vypnuté. Intel byl jeden z mála, kdo ho měl tradičně defaultně zapnuté, ale nakonec se IIRC nechali přesvědčit, že to opravdu není dobrý nápad. GSO/GRO z podstaty věci nevyžaduje podporu v NIC, takže tam je úplně jedno, od jakého je karta výrobce a jaký je to model.

4. S přerušeními to moc společného nemá. Tvrzení, že co příchozí paket, to přerušení, neplatí už opravdu hodně dlouho (15-20 let). Navíc i kdyby to tak bylo, týkalo by se to stejně jen LRO, kterému je tak jako tak lepší se vyhnout. Skutečný důvod je ten, že většina toho, co se s paketem děje u příchozích i odchozích, pracuje jen s metadaty a hlavičkami, takže je jedno, jak je paket dlouhý; proto je efektivnější pakety, u kterých to jde, zpracovávat dohromady jako jeden velký. U vyšších rychlostí to ani jinak nejde, 10 Gb/s je asi tak hranice toho, co se dá ještě v jednom spojení zvládnout bez GSO/GRO (na dostatečně rychlém procesoru).

[Reklama]

[mikesznovu]

JE TO RTL8153
Jedna z otázek mě taky napadlo k forwardování. Jak se to chová kdyby dotyčný stroj, co umí LRO zároveň forwardoval a MTU by měl 9000, jestli pro forwardování tam nejsou jiný pravidla nebo omezení

Zajímavé, myslel jsem že zkratky G** VS T** roslišují jestli jde o protokol (T)CP nebo pro víc (G)protokolů(i když mi bylo divné, o jaké by mělo jít)

[Michal Kubeček]

Co se LRO a forwardingu týká, nejlepší je si prostě pamatovat, že to nefunguje. Ono by to technicky při troše štěstí někdy i fungovat mohlo, ale těch případů, kdy se to rozbije, je tolik, že je lepší neriskovat. Ostatně jádro už docela dlouho při zapnutém forwardování automaticky LRO vypíná.

Co se týká jiných protkolů, existuje i jakási verze GSO/GRO pro UDP, ale je to poměrně nová záležitost a má to dost omezení. Dělá se to hlavně kvůli QUICu.

[František Ryšánek]

Mimo soutěž / na okraj, zaujala mě zmínka o RTL8153... pro zajímaovst, to je na PCI-e nebo na USB ?

[mikesznovu]

Mimo soutěž / na okraj, zaujala mě zmínka o RTL8153... pro zajímaovst, to je na PCI-e nebo na USB ?

Na interním USB 3.0