net/devif: Reorder ipv4_input packet classification.

[ankohuu]

Summary

After reading the ipv4_input code, I think the behavior is not so clearly, and in some cases it appears incorrect.
For example, when NET_UDP is not enabled + broadcast packets, as well as multicast packets that do not match
any IGMP group, both fall into the ip_forward path. here
So I rework ipv4_input() packet classification to make the control flow clearer and keep the common local-unicast
case first.

This change:

• handles local packets first
• keeps broadcast/multicast handling in dedicated branches

Impact

Refactored the IPv4 input forwarding logic using an equivalent formulation.

Testing

Nuttx SIMulator

• nettest between two SIMulators

Bridge:

brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.5afd2f3721c4       no              tap0
                                                                              tap2

Sim1:
nsh> ifconfig
eth0    Link encap:Ethernet HWaddr 42:42:42:43:44:46 at RUNNING mtu 1500
        inet addr:10.0.0.1 DRaddr:10.0.0.1 Mask:255.255.255.0

nsh> nettest
Binding to IPv4 Address: 00000000
server: Accepting connections on port 5471
server: Connection accepted -- receiving
server: Reading...
server: Received 512 of 512 bytes
server: Sending 512 bytes
server: Sent 512 bytes
server: Wait before closing
server: Terminating

Sim2:
nsh> ifconfig
eth0    Link encap:Ethernet HWaddr 42:b3:0d:d6:82:81 at RUNNING mtu 1500
        inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0

nsh> nettest2 10.0.0.1
Connecting to Address: 0100000a
client: Connected
client: Sending 512 bytes
client: Sent 512 bytes
client: Receiving...
client: Received 512 of 512 bytes
client: Terminating

• 1 SIMulator with 2 tap-nics unicast forward

 ip addr show dev tap0
 98: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
 link/ether c2:ad:53:d1:33:d4 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.1/24 scope global tap0
    valid_lft forever preferred_lft forever
 inet6 fe80::c014:f7ff:fec9:e91/64 scope link
    valid_lft forever preferred_lft forever

 sudo ip netns exec lan ip addr show dev tap1
 99: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
 link/ether c2:dc:48:70:0c:7b brd ff:ff:ff:ff:ff:ff
 inet 10.0.1.1/24 scope global tap1
    valid_lft forever preferred_lft forever
 inet6 fe80::c0dc:48ff:fe70:c7b/64 scope link
    valid_lft forever preferred_lft forever

ifconfig
eth0    Link encap:Ethernet HWaddr 42:b3:0d:d6:82:81 at RUNNING mtu 1500
        inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0

eth1    Link encap:Ethernet HWaddr 42:8a:90:eb:ef:03 at RUNNING mtu 1500
        inet addr:10.0.1.2 DRaddr:10.0.1.1 Mask:255.255.255.0

nsh> route
SEQ   TARGET          NETMASK         ROUTER
   1. 0.0.0.0         0.0.0.0         10.0.1.1

ping -c 1 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=1 ttl=63 time=4.04 ms

--- 10.0.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.036/4.036/4.036/0.000 ms

• 1 SIMulator with 2 tap-nics broadcast forward

sudo ip netns exec lan tshark -i tap1
Running as user "root" and group "root". This could be dangerous.
Capturing on 'tap1'
    1 0.000000000     10.0.0.1 → 10.0.1.255   UDP 70 12345 → 5000 Len=28

ESP32 only one nic

 nsh> uname -a
 NuttX  12.13.0 4e96a3a12b Apr 21 2026 19:00:28 xtensa esp32s3-devkit

 nsh> ifconfig
 wlan0   Link encap:Ethernet HWaddr 50:78:7d:15:de:80 at RUNNING mtu 1500
         inet addr:192.168.0.104 DRaddr:192.168.0.1 Mask:255.255.255.0
 
 nsh> ping www.x.com
 PING 172.66.0.227 56 bytes of data
 56 bytes from 172.66.0.227: icmp_seq=0 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=1 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=2 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=3 time=50.0 ms
 56 bytes from 172.66.0.227: icmp_seq=4 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=5 time=50.0 ms
 56 bytes from 172.66.0.227: icmp_seq=6 time=50.0 ms
 56 bytes from 172.66.0.227: icmp_seq=7 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=8 time=60.0 ms
 56 bytes from 172.66.0.227: icmp_seq=9 time=60.0 ms
 10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
 rtt min/avg/max/mdev = 50.000/57.000/60.000/4.582 ms

[acassis]

@ankohuu I think it is important to do more real world tests before merging it. Unfortunately we don't have good network testing tools. The nettest seems very simple for more complex test. And in fact a real test will require a board and a computer or some application running in the host computer and a test set in the NuttX SIMulator.

[ankohuu]

@ankohuu I think it is important to do more real world tests before merging it. Unfortunately we don't have good network testing tools. The nettest seems very simple for more complex test. And in fact a real test will require a board and a computer or some application running in the host computer and a test set in the NuttX SIMulator.

Thanks acassis. I will try to run more tests and update the PR with the results. Please hold off on merging until then; comments are welcome in the meantime. I will

• use the the NuttX SIMulator to cover some forwarding paths
• learn and do nettest
• recently, @masc2008 sponsored me a DNESP32S3 board, so I will also try to bring up NuttX on real hardware for testing.

[ankohuu]

@anchao could you take a look at this and share feedback? thanks