Re: TUN device (PPP) issue?
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 翁�� Sent: 17 January 2024 04:55 To: Kian Karas (KK) Cc: 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) 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.56] [ 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.54) is copied to the second IOB in the chain. [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 len=184 next=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 bytes new len=182 [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the chain [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 next=0 [ 10.08] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes new len=2 [ 10.08] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.08] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 len=184 next=0x24002a50 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 bytes new len=168 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 len=16 next=0 [ 10.28] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes new len=16 [ 10.28] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.28] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.46] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 len=184 next=0x24002a50 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 bytes new len=154 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 len=30 next=0 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes new len=30 [ 10.48] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.49] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! ... [ 12.50] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 l
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) 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.56] [ 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.54) is copied to the second IOB in the chain. [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 len=184 next=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 bytes new len=182 [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the chain [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 next=0 [ 10.08] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes new len=2 [ 10.08] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.08] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 len=184 next=0x24002a50 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 bytes new len=168 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 len=16 next=0 [ 10.28] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes new len=16 [ 10.28] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.28] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.46] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 len=184 next=0x24002a50 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 bytes new len=154 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 len=30 next=0 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes new len=30 [ 10.48] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.49] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! ... [ 12.50] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 12.51] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=14 len=184 next=0x24002a50 [ 12.51] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 14 bytes new len=14 [ 12.52] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=156 len=170 next=0 [ 12.52] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 170 bytes new len=170 [ 12.52] [ INFO] ppp0: tun_net_receive
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.56] [ 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.54) is copied to the second IOB in the chain. [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 len=184 next=0 [ 10.06] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 bytes new len=182 [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the chain [ 10.07] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 next=0 [ 10.08] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes new len=2 [ 10.08] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.08] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.26] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 len=184 next=0x24002a50 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 bytes new len=168 [ 10.27] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 len=16 next=0 [ 10.28] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes new len=16 [ 10.28] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.28] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 10.46] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 len=184 next=0x24002a50 [ 10.47] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 bytes new len=154 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 len=30 next=0 [ 10.48] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes new len=30 [ 10.48] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 10.49] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! ... [ 12.50] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 offset=0 [ 12.51] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=14 len=184 next=0x24002a50 [ 12.51] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 14 bytes new len=14 [ 12.52] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=156 len=170 next=0 [ 12.52] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 170 bytes new len=170 [ 12.52] [ INFO] ppp0: tun_net_receive_tun: IPv4 frame [ 12.53] [ INFO] ppp0: ipv4_in: WARNING: Not destined for us; not forwardable... Dropping! [ 24.54] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=28 offset=0 [ 24.54] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 len=28 next=0x24002a50 [ 24.55] [ INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 0 bytes new len=0 [ 24.55] [ INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=170 le
