lpr

rga rga na centrum.cz
Čtvrtek Červen 4 17:52:41 CEST 2009


> Server sestavuje TCP spojení na tiskárnu, ohlašuje MSS=1400
> tiskárna odpovídá, ohlašuje MSS=1460.
> Server začne posílat IP datagramy o velikosti 1460 B.
> VPN je fragmentuje na 1440 B+ 20 B, takto doráží na tiskárnu.
> Tiskárna odpovídá zpět ICMP Type 12 Code 0, Pointer je nastaven na 36.
>
> Sniffingem na druhé straně vidím, že tam ICMP nedoráží!
> Tipuji, že přecijen firewall nepropouští všechny ICMP, jak nám tvrdí správce firewallu.
>
> Protože server nedostává TCP potvrzení, provádí re-transmitting původních packetů,
> pořád ale o velikosti 1460 B, opět dochází k fragmentaci,
> tiskárna opět odpovídá ICMP Type 12 Code 0,
> a to celé dokud nevyprší timouty.
>
> Zeptám se, nějak už se nechytám a nemůžu se nic jasného u strýčka Googla dopátrat,
> proč tiskárna odesílá právě tyto ICMP? A takdy se nemůžu dopátrat, proč je Pointer 36?
> Přeci 36. bajt IP datagramu už by měla být samotná data, nebo ne?
> A když se dívám do TCP streamu, tak vidím, že data jsou v pořádku,
> "jen" jsou useklá, protože server po vypršení timeoutů tisk vzdá.

Tak jsem se tak dlouho šťoural v nasbíraných packetech z obou stran,
až mě prásklo do očí něco, čeho jsem si celou dobu nevšiml.
Server odesílá 1460 B packety s nastaveným DF bitem.
Nejenže že Server nedostane od firewallu (který sestavuje VPN) ICMP packet Type3 Code 4
(buďto není firewallem vůbec odeslán, nebo sám sebe filtruje? ;-)),
firewall/VPN si klidně tento packet fragmentuje do dvou IP datagramů (1420 + 40),
kde je takto vidím příjít na druhé straně.
Předpokládám, že tohle bude "nějak" důvodem k následému
ICMP Type 12 Code 0 od tiskárny zpět k serveru (který tam ale dle snifferu vůbec nedorazí).

No není nad služby externí zahraniční profesionální firmy...

Někdo kdo by potvrdil/vyvrátil mé dohady? ;-)





Další informace o konferenci Linux