Hi all, I would like to add a layer 2 Ethernet bridge to NuttX and would appreciate feedback on the design before going further. Draft PRs:
https://github.com/apache/nuttx/pull/20519 https://github.com/apache/nuttx-apps/pull/3819 (brctl command) Motivation: an Ethernet to Wi-Fi bridge on a PIC32MZ-W1 board, where Wi-Fi clients (NuttX as access point) and a wired device must be on the same LAN, and DHCP must be served either by the wired device through the bridge or by NuttX itself. IP forwarding/NAT cannot do that. Today NuttX only defines the SIOCBR* ioctl numbers and include/nuttx/net/if_bridge.h. Summary of the proposal: - br0 is a virtual Ethernet device created with SIOCBRADDBR; ports are added with SIOCBRADDIF (same arguments as Linux). The bridge holds the IP configuration. Learning filtering database, flooding of unknown/group frames, no STP. - RX: a new d_bridge field in struct net_driver_s marks a port. Frames received on a port are diverted to the bridge by a check in the upper-half RX path (all ethertypes) and at the top of ipv4_input(), ipv6_input() and arp_input(), so drivers that do not use the upper-half interface can be ports too (IP/ARP only). - TX: forwarded frames are queued per egress port and sent through a new BRIDGE_POLL poll type in devif_poll(), which passes the frame to the driver without rebuilding the link layer header. This works for both kinds of drivers. - Locking: the upper-half txavail locks the device synchronously, so two ports forwarding to each other could deadlock if one notified the other from its RX path. The port notification and the TX poll of br0 therefore run on LPWORK with no device locked. Questions: 1. Is the d_bridge field plus hooks in ipv4/ipv6/arp_input acceptable, or would you rather restrict bridging to upper-half drivers (like VLAN) and keep a single hook? 2. LPWORK for the TX notification, or should it follow the upper-half work queue configuration? 3. How should the filtering database be exposed (procfs, netlink, ...)? Linux uses SIOCDEVPRIVATE/sysfs, which NuttX does not have. On the simulator (sim:bridge, two TAP devices in separate host network namespaces) it forwards TCP at about 300 Mbit/s and all functional tests pass; details are in the PR. Hardware testing on PIC32MZ-W1 (Ethernet + Wi-Fi AP) is next. Thanks, Daniel Daniel Pereira de Carvalho
