Hi Zhe I am working on tag nuttx-12.2.1.
Your referenced commit did indeed fix the issue. My apologies for not trying on master. I mistakenly though the error was in the TUN device driver, which I noticed had not changed since nuttx-12.2.1. Thanks a lot! Kian ________________________________ From: Zhe Weng 翁�� <weng...@xiaomi.com> Sent: 17 January 2024 04:55 To: Kian Karas (KK) <k...@thrane.eu> Cc: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: TUN device (PPP) issue? Hi Kian, Which version of NuttX are you working on? It behaves like a problem I've met before. Do you have this commit in your code? If not, maybe you could have a try: https://github.com/apache/nuttx/commit/e2c9aa65883780747ca00625a1452dddc6f8a138 Best regards Zhe ________________________________ From: Kian Karas (KK) <k...@thrane.eu> Sent: Tuesday, January 16, 2024 11:53:06 PM To: dev@nuttx.apache.org Subject: TUN device (PPP) issue? 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 #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
