[Openswan Users] 2.4.5 klips mtu issue

[Brian Candler]

On Fri, Apr 07, 2006 at 07:06:21PM +0200, Paul Wouters wrote:
> We are trying to build a testcase that reproduces this behaviour.

Thanks. I can send you the full Cisco config off-line if that helps.

However I'm very puzzled about the DF bit. In order to try to understand
what's setting it, I tried tcpdumping the ipsec0 interface to see the
outbound L2TP packets prior to encryption.

With openswan 2.4.5 + that one-line patch I posted, the first packet has DF
set and the subsequent ones don't. With plain 2.4.5, all the packets have DF
set.

So what I don't understand now is, who's setting the DF bit? If it's l2tpd,
what characteristic of the interface is it sensing which makes it behave
differently? Or is the kernel messing with the DF bit?

With stock 2.4.5:

root at OpenWrt:~# ifconfig ipsec0
ipsec0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.71.32.1  Mask:255.255.255.240
          NOARP  MTU:16260  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:0 (0.0 B)  TX bytes:1870 (1.8 KiB)

(using ifconfig to set the MTU to 1400 didn't help here)

Changing back to 2.4.5 with that MTU patch:

root at OpenWrt:~# ifconfig ipsec0
ipsec0    Link encap:Ethernet  HWaddr 00:11:D8:01:C5:C5  
          inet addr:10.71.32.1  Mask:255.255.255.240
          UP RUNNING NOARP  MTU:16260  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

But this wasn't repeatable. After switching back to vanilla 2.4.5, I got

root at OpenWrt:~# ifconfig ipsec0
ipsec0    Link encap:Ethernet  HWaddr 00:11:D8:01:C5:C5  
          inet addr:10.71.32.1  Mask:255.255.255.240
          UP RUNNING NOARP  MTU:16260  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:0 (0.0 B)  TX bytes:632 (632.0 B)

and I still see all packets with DF set:

root at OpenWrt:~# tcpdump -i ipsec0 -n -s1500 -X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:10:37.175092 IP 10.71.32.1.1701 > Y.Y.Y.Y.1701:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(256) HOST_NAME(OpenWrt) *VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(53404) *RECV_WIN_SIZE(4)
        0x0000:  4500 0080 0000 4000 4011 fea0 0a47 2001  E..... at .@....G..
        0x0010:  YYYY YYYY 06a5 06a5 006c 3e92 c802 0064  Rm.......l>....d
        0x0020:  0000 0000 0000 0000 8008 0000 0000 0001  ................
        0x0030:  8008 0000 0002 0100 800a 0000 0003 0000  ................
        0x0040:  0003 800a 0000 0004 0000 0000 0008 0000  ................
        0x0050:  0006 0100 000d 0000 0007 4f70 656e 5772  ..........OpenWr
        0x0060:  7480 0f00 0000 086c 3274 7064 2e6f 7267  t......l2tpd.org
        0x0070:  8008 0000 0009 d09c 8008 0000 000a 0004  ................
11:10:38.180506 IP 10.71.32.1.1701 > Y.Y.Y.Y.1701:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(256) HOST_NAME(OpenWrt) *VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(53404) *RECV_WIN_SIZE(4)
        0x0000:  4500 0080 0000 4000 4011 fea0 0a47 2001  E..... at .@....G..
        0x0010:  YYYY YYYY 06a5 06a5 006c 3e92 c802 0064  Rm.......l>....d
        0x0020:  0000 0000 0000 0000 8008 0000 0000 0001  ................
        0x0030:  8008 0000 0002 0100 800a 0000 0003 0000  ................
        0x0040:  0003 800a 0000 0004 0000 0000 0008 0000  ................
        0x0050:  0006 0100 000d 0000 0007 4f70 656e 5772  ..........OpenWr
        0x0060:  7480 0f00 0000 086c 3274 7064 2e6f 7267  t......l2tpd.org
        0x0070:  8008 0000 0009 d09c 8008 0000 000a 0004  ................

Very strange indeed.

Regards,

Brian.