Sequence of IP fragment packets on the wire

Sequence of IP fragment packets on the wire

[Henning P. Schmiedehausen]

Hi,

as far as I can see, Linux sends out fragmented IP packets
"butt-first":

11:34:53.927146 alice > bob: (frag 44605:343@1480)
11:34:53.927189 alice.4831 > bob.udpdemo:  udp 1815 (frag 44605:1480@0+)

(where the first packet is actually the fragmented 2nd part of the
second packet).

This confuses at least one firewall appliance. As I understand it,
this is done for efficency reasons. Still, is there any way to
suppress this and get the packets sent out in "head first" sequence? I
know that routers might resort the fragments again but in my case I
have an "alice -- firewall -- bob" topology which at the moment drops
the fragment on the floor...

Is there a way to configure this? Maybe even connection specific? 

I tested 2.2.19 and 2.4.18 with 100 MBit Ethernet (3Com and eepro100).
Both show the same behaviour.

	Regards
		Henning



-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Sequence of IP fragment packets on the wire

[David S. Miller]

   From: "Henning P. Schmiedehausen" <hps@intermeta.de>
   Date: Thu, 3 Oct 2002 10:51:08 +0000 (UTC)

   as far as I can see, Linux sends out fragmented IP packets
   "butt-first":
   
Right.
   
   Is there a way to configure this? Maybe even connection specific? 

No.

Re: Sequence of IP fragment packets on the wire

[David Schwartz]

On Thu, 3 Oct 2002 10:51:08 +0000 (UTC), Henning P. Schmiedehausen wrote:

>as far as I can see, Linux sends out fragmented IP packets
>"butt-first":
>(where the first packet is actually the fragmented 2nd part of the
>second packet).
>
>This confuses at least one firewall appliance.

	I'm afraid that this firewall appliance is fundamentally broken. Nothing you 
can do to Linux can fix this fundamental breakage. I can give further 
examples, analogies, and argumentation, but it really should be obvious that 
IP, fundamentally, does not guarantee any particular reception order and 
anything that assumes it does cannot be fixed except by changing the 
assumption.

	This is as bad as a TCP application that assumes one 'read' call will return 
an entire line or command. You cannot push the problem elsewhere.

	DS

Re: Sequence of IP fragment packets on the wire

[Alan Cox]

On Thu, 2002-10-03 at 11:51, Henning P. Schmiedehausen wrote:
> This confuses at least one firewall appliance. As I understand it,

You should replace that appliance. Packets can get re-ordered by a
million different things on the wire not just by the fact Linux is
optimising the fragment processes.

> Is there a way to configure this? Maybe even connection specific? 

No

Alan

Re: Sequence of IP fragment packets on the wire

[Richard B. Johnson]

> as far as I can see, Linux sends out fragmented IP packets
> "butt-first":
> (where the first packet is actually the fragmented 2nd part of the
> second packet).
> This confuses at least one firewall appliance.
> 

The sequence-number of an IP Packet, whether or not it's fragmented,
has nothing to do with any order of reception. The "2nd" part of
a fragmented packet may be received at any time, in fact multiple
times. Any so-called Network appliance that assumes that there is
any specific order of packets being received is fundamentally
broken.

Well designed network software can sometimes optimize its buffer
handling if it "knows" that the last packet of a fragment has
been received, but it can't count on any specific order because
there isn't any. Even if you put all your "ducks in a row" on
the wire, once the least-cost route becomes different for different
packets, all bets are off. You might get one packet with satellite-
link latency (seconds) and another with terrestrial latency
(miliseconds).

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: Sequence of IP fragment packets on the wire

[Henning Schmiedehausen]

Hi,

thanks to anyone for making this clear. Replacing this particular
system is currently out of question but I will take it on with the
people from SonicWall (oops, now the name did slip, silly me...)
to get this fixed ASAP. 

	Regards
		Henning


On Thu, 2002-10-03 at 14:16, Alan Cox wrote:
> On Thu, 2002-10-03 at 11:51, Henning P. Schmiedehausen wrote:
> > This confuses at least one firewall appliance. As I understand it,
> 
> You should replace that appliance. Packets can get re-ordered by a
> million different things on the wire not just by the fact Linux is
> optimising the fragment processes.
> 
> > Is there a way to configure this? Maybe even connection specific? 
> 
> No
> 
> Alan

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Sequence of IP fragment packets on the wire

[Andi Kleen]

"David S. Miller" <davem@redhat.com> writes:
>    
>    Is there a way to configure this? Maybe even connection specific? 
> 
> No.

Actually there used to be an old netfilter module around (I think it was
one of the early netfilter demo modules) that reversed the fragments. Of 
course it is not efficient at all and not recommended.

-Andi