Re: paket fragmentation and mtu|
Stephan von Krawczynski <skraw,AT,ithnet,DOT,com>|
Wed, 11 Jul 2001 18:10:05 +0200|
---Reply on mail from Stephan von Krawczynski about paket fragmentation and
> I updated all cipes to 1.5.2 yesterday and the problem stays (of course).
> Logfile shows this:
> Jul 11 09:07:21 firewall1-pla kernel: Packet log: uu_in ACCEPT hdlc1
> www.elsa.de:80 win-client:1441 L=1500 S=0x00 I=0 F=0x4000 T=49 (#3)
> And back:
> Jul 11 09:07:21 firewall1-pla kernel: Packet log: uu_out ACCEPT hdlc1
> cipe-router:3 www.elsa.de:4 L=576 S=0xC0 I=21686 F=0x0000 T=253 (#3)
> This repeats several times, and then www.elsa.de timeouts.
> How can we make it work? Obviously cipe should fragment the packet itself,
> and not care about the mtu at all. I thought this should be done by
> mtu in cipe's configfile. But that doesn't seem to work. Anybody out there
> different experience?
Ok, I have an addendum:
I patched cipe 1.5.2 for another option I called "forcefrag", which basically
enables you to work around the mtu-check, and disables the copying of the
ip-fragoff status from the encapsulated packet.
Now I experience the following:
router-a: 2.2.19 with cipe 1.5.2
router-b: 2.4.5 with cipe 1.5.2
"ping -D -s 1472 router-b" on router-a works, the packets are 1500 bytes long
and together with cipe's encapsulation come out with 1528, are handed over
length) to the kernel, that obviously fragments them and sends them to
"ping -D -s 1472 router-a" on router-b does not work! I see no packets being
transferred by the kernel, neither via cipe nor via ethernet. Instead
cipe-error-count goes up per ping packet.
If I do "ping -s 1472 router-a" then the kernel tells me it delivers _two_
via underlying ethernet sized 1480 and 96 bytes. These are fragmented ones I
Does kernel 2.4 do not do any auto-fragmentation of packets bigger than
I have no idea how to solve this.