Hi community

I am experiencing an issue with PPP/TUN and reception of packets. The network 
stack reports different decoding errors in the received packets e.g.:
[   24.560000] [  WARN] ppp: ipv4_in: WARNING: IP packet shorter than length in 
IP header

I can reproduce the issue by sending a number of packets (from my PC over PPP 
to the TUN device in NuttX),  which are all larger than can fit into one IOB 
*and* which are ignored (e.g. unsupported protocol or IP destination) - i.e. 
*not* triggering a response / TX packet. I then send a correct ICMP echo 
request from my PC to NuttX, which causes the above error to be reported.

The following PC commands will trigger the error message. My PC has IP 
172.29.4.1 and the NuttX ppp interface has 172.29.4.2. Note the first command 
sends to the *wrong* IP address so that NuttX ignores the ICMP messages. The 
second commands uses the IP of NuttX and should result in a response. I run the 
test after a fresh boot and with no other network traffic to/from NuttX.

$ ping -I ppp0 -W 0.2 -i 0.2 -c 13 172.29.4.3 -s 156
$ ping -I ppp0 -W 0.2 -c 1 172.29.4.2 -s 0

If I skip the first command, ping works fine.

I think the issue is caused by the IOB management in the TUN device driver 
(drivers/net/tun.c). I am new to NuttX, so I don't quite understand the correct 
use of IOB, so I am just guessing here. I think that when a packet is received 
by tun_write() and too large to fit into a single IOB *and* the packet is 
ignored, the IOB chain "lingers" and is not freed. Subsequent packets received 
by tun_write() does not end up in the beginning of the first IOB and the 
IP/TCP/UDP header may then be split across IOB boundary. The network stack 
assumes the protocol headers are not split across IOB boundaries, so the 
network stack ends up reading outside the IOB io_data[] array boundaries 
resulting in undefined behavior.

With CONFIG_IOB_DEBUG enabled, notice how the "avail" value decrease for each 
ignored packet until the final/correct ICMP request (at time 24.540000) is 
copied to the second IOB in the chain.

[   10.060000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.060000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=184 next=0
[   10.060000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 
bytes new len=182
[   10.070000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the 
chain
[   10.070000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 
next=0
[   10.080000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes 
new len=2
[   10.080000] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.080000] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.260000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.260000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 
len=184 next=0x24002a50
[   10.270000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 
bytes new len=168
[   10.270000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 
len=16 next=0
[   10.280000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes 
new len=16
[   10.280000] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.280000] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.460000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.470000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 
len=184 next=0x24002a50
[   10.470000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 
bytes new len=154
[   10.480000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 
len=30 next=0
[   10.480000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes 
new len=30
[   10.480000] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.490000] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
...
[   12.500000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   12.510000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=14 
len=184 next=0x24002a50
[   12.510000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 14 bytes 
new len=14
[   12.520000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=156 
len=170 next=0
[   12.520000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 170 
bytes new len=170
[   12.520000] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   12.530000] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   24.540000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=28 
offset=0
[   24.540000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=28 next=0x24002a50
[   24.550000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 0 bytes 
new len=0
[   24.550000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=170 
len=28 next=0
[   24.550000] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 28 bytes 
new len=170
[   24.560000] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   24.560000] [  WARN] ppp0: ipv4_in: WARNING: IP packet shorter than length 
in IP header


Im an running NuttX on a proprietary board with an STM32H723. Some of my 
configs, which may be relevant:
CONFIG_MM_IOB=y
CONFIG_IOB_NBUFFERS=24
CONFIG_IOB_BUFSIZE=196
CONFIG_IOB_ALIGNMENT=4
CONFIG_IOB_SECTION=""
CONFIG_IOB_NCHAINS=24
CONFIG_IOB_THROTTLE=0
CONFIG_IOB_DEBUG=y
CONFIG_NET_TUN=y
CONFIG_TUN_NINTERFACES=2
CONFIG_NET_TUN_PKTSIZE=296
CONFIG_NETDEV_LATEINIT=y

The following patch seems to fix the issue, but I have no idea whether it is 
the right approach.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index f77ef7583d..5f6119b624 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -599,6 +599,10 @@ static void tun_net_receive_tun(FAR struct tun_device_s 
*priv)
       netdev_iob_clear(dev);
       tun_fd_transmit(priv);
     }
+  else
+    {
+      netdev_iob_release(dev);
+    }
 }

 /****************************************************************************

I assume that same issue exists for tun_net_receive_tap() too, and that the 
same fix should be applied there (i can't test/verify this scenario).

Best regards
Kian

Reply via email to