Zephyr Ethernet Interface Supporting Many IPv4 IPs and Many Multicast Addresses

[bob2oneil]

I want to configure a primary Ethernet Interface in Zephyr that will support a range of IPv4 IP addresses (all within the same IP subnet) as well as a range of multicast addresses (all in the same IP subnet).

This would be roughly equivalent to the Linux "alias" command for multi-homing an Ethernet interface to support a range of IPs.

How is this accomplished through kernel configurations, and is there a cap on either Ipv4 addresses or multicast addresses for the standard Ethernet interface?

I would want to handle i/o from that interface using a UDP and TCP BSD socket, presumably not bound to any IP, but I would need to know the destination IP and destination UDP port for routing. TCP will be necessary for a Telnet session.

Assuming I am unable to provide for a range of IPs on this interface through kernel or runtime configuration, I would like to combine a UDP and TCP sockets with a raw socket on the same device interface as the primary Zephyr Ethernet interface.

Certainly, using a promiscuous socket provides access to all IPs as well as the entire Ethernet UDP header, but then I would have to reconstruct the UDP header for outgoing packets without leveraging the interface ARPing and UDP header creation that occurs within the IP stack.

Can these ambitions all be accomplished on the same interface, i.e. a promiscuous raw socket operating at Layer 2 along with a UDP unbound socket and TCP socket operating at Layer 3 within Zephyr?

The following kernel configuration can be used to set a value, but what is the maximum?

config NET_IF_UNICAST_IPV4_ADDR_COUNT
    int "Max number of unicast IPv4 addresses per network interface"
    default 2 if NET_IPV4_AUTO
    default 1
    depends on NET_IPV4 && !NET_RAW_MODE && NETWORKING

[jukkar]

The following kernel configuration can be used to set a value, but what is the maximum?

There is no maximum, only the amount of memory limits it.

Assuming I am unable to provide for a range of IPs on this interface through kernel or runtime configuration,

The IP addresses need to be assigned to the interface at runtime by your application. Just use this function for doing it

struct net_if_addr *net_if_ipv4_addr_add(struct net_if *iface,
					 struct in_addr *addr,
					 enum net_addr_type addr_type,
					 uint32_t vlifetime);

Can these ambitions all be accomplished on the same interface, i.e. a promiscuous raw socket operating at Layer 2 along with a UDP unbound socket and TCP socket operating at Layer 3 within Zephyr?

I could not follow what you are trying to do here. It is possible to have both raw and UDP sockets open at the same time.

As you noticed the CONFIG_NET_IF_UNICAST_IPV4_ADDR_COUNT sets the max number of unicast addresses and the CONFIG_NET_IF_MCAST_IPV4_ADDR_COUNT option is for multicast addresses for each network interface.

Certainly, using a promiscuous socket provides access to all IPs as well as the entire Ethernet UDP header, but then I would have to reconstruct the UDP header for outgoing packets without leveraging the interface ARPing and UDP header creation that occurs within the IP stack.

If you create AF_PACKET type socket with SOCK_DGRAM type, then the system will create the physical-layer header automatically when sending a packet and the application will only need to provide the UDP header.

[bob2oneil]

Many thanks Jukkar

[bob2oneil]

Quick followup, from what I can tell, other than perhaps virtual interfaces, the IPv4 address is configured in the kernel configuration file during application build, or by use of a DCONF command line override when building the binary. It is possible to both runtime change the IP address of a created Ethernet interface, change attributes such as the MTU, perhaps normalized the name reference to something standard and observable like eth0?

[jukkar]

from what I can tell, other than perhaps virtual interfaces, the IPv4 address is configured in the kernel configuration file during application build, or by use of a DCONF command line override when building the binary. It is possible to both runtime change the IP address of a created Ethernet interface, change attributes such as the MTU, perhaps normalized the name reference to something standard and observable like eth0?

The CONFIG_NET_CONFIG_AUTO_INIT and CONFIG_ NET_CONFIG_SETTINGS options enable the config library that can be used to set static IP address to the default network interface. If is meant to be used in the automated testing or if you have a simple setup with only one network interface and one IP address.
If you have anything more complex, it is better to disable the config lib and set all the static IP addresses, netmasks, gateway, routes etc. manually by the application when it starts. Then you can control in detail, when and what addresses to set and to what network interface(s).

[bob2oneil]

Thanks Jukkar, I want to be able to create up to 32 nodes to act as virtual radios in a network, where the primary Ethernet interface will be IPv4 only, static IPs of 192.168.0.x and multicast 200.0.0.x as the primary host data interface, and each application will have a virtual Ethernet interface (138.0.0.x) with an MTU of 9K that all are hooked up externally via a Linux bridge to simulate an RF interface. The simulated radio would bridge traffic between the primary Ethernet interface to the common virtual RF interface in each running instance.

The 2 sockets on each will need to be promiscuous as I need to bridge some raw Layer 2 traffic and there are ranges of IPv4 addresses for the static addresses, and the multicast is in the 200.x.xx range, which is not standard. I would create on a Linux host a TAP interface to act as the data source to each virtual radio similar to the Native POSIX example for the primary data interface to the radio.

Native POSIX 64 is the immediate target, but QEMU_RISCV64 is closer to the target board.

So that is the broad goal to put this discussion into context.

Are there any examples of establishing or created the primary Ethernet interface runtime, set IP, gateway, mask, MTU, perhaps name as opposed to using kernel configuration which would need to vary for each instance?

Notionally each instance will need a different IP/MAC for the 2 Ethernet interfaces, and I would prefer to do that using a command line argument (e.g. --node argument) than having to build each one of the instances using a different kernel configuration. The good folks on this project have already discussed what it takes to get command line arguments into an application.

So notionally, a common binary could be created, and a virtual radio would be invoked with something like "zephyr --node 1"), it would create runtime the 2 Ethernet interfaces using different network settings.

Can you point to anything you know of in the examples space (or broad Zephyr ecosystem) that might get me started in the right direction?

[jukkar]

Are there any examples of establishing or created the primary Ethernet interface runtime, set IP, gateway, mask, MTU, perhaps name as opposed to using kernel configuration which would need to vary for each instance?

For example the samples/net/sockets/echo_server/src/vlan.c has a function that sets IP address etc to the network interface.
Also the virtual network sample app in samples/net/virtual has functions that setup IP addresses etc.

Are you planning to use the virtual network interface support in Zephyr, it was recently introduced to allow stacking network interfaces on top of each other. Currently it is used in Zephyr to create IP tunneling support.