Hi Matthias, I agree with Gregory's opinion, if you want to do the same thing on NuttX as you do on Linux, you'll need both: 1. Support multiple IP addresses in the device structure 2. Support the alias like 'eth0:0' because the ioctl of IPv4 address is designed to set one address per interface, so only with aliases we can set more addresses into one device by ioctl (or use netlink instead of ioctl)
But I do have another idea: Maybe you can try to register two network devices even if you only have a single GMAC, just dup all the rx packets to both interfaces, and let all tx packets go out. Since the IP addresses are different on each interface, the stack may drop packets on the incorrect interface and accept the correct one. It may have some problems in some situations like broadcast I guess, but I think it may have a chance to work. Another note: I'm working on supporting multiple IPv6 addresses per device structure these days, but not yet finished (and not planning for IPv4). I posted it as a draft: https://github.com/apache/nuttx/pull/11054 in case you really want to implement the IPv4 one. Best Regards, Zhe Gregory Nutt wrote: > On 10/25/2023 9:27 AM, Matthias Roosz wrote: > > Hi all, > > > > > > > > forgive my ignorance, I’ve just started diving into networking topics > > (including handling connections via Berkeley sockets). My final goal is to > > make my device reachable via two separate IP addresses with a single PHY. > > Once there are two IP addresses set up I'd bind to each specific address to > > get two socket handles with which my application could work - does that > > make sense (the use case would be in connection with an integrated switch, > > e.g. a KSZ8463)? > > > > In linux systems I think this can be achieved via ifconfig eth0:0 > > [newAddress] netmask [mask] up or by persisting the configuration in > > /etc/network/interfaces (i.e. in my understanding by creating an alias > > network interface). > I think you would need to implement something like this in NuttX too. > > Now in Nuttx ifconfig does not allow this and there is no persistent > > configuration. I can't imaging calling netlib_set_ipv4addr() / > > netlib_set_dripv4addr () / netlib_set_ipv4netmask() twice with the same > > ifname will work so the question remains: how do I get a second interface I > > can work with? Do I even need to integrate more potent hardware such as a > > KSZ9477S that has multiple physical GMACS? > > The network interface is controlled by the network MAC driver. Its > device structure carries the IP address and netmask that are associated > with the MAC via IOCTLs, but I don't think that the driver itself knows > anything about IP (it shouldn't!) > > The IP address and netmask normally defines a subnet and, hence, the > network. Normally two IP addresses would reside on the same network. > In this case do you want to support two different IP address from > different networks? I hope not (only because I don't understand that > model, perhaps it doesn't matter to the software). > > The IP routing is purely based on the IP address stored in the device > structure. If you want routing to two different address on the subnet, > then you would need two IP address in the device structure. Again, > these should have nothing to do with the MAC driver. You would need (1) > a network IOCTL and NSH ifconfig extension to set the second IP address > (following the Linux convention), and (2) logic throughout the network > code to handle the second address. The IP routing is one place, but > there are lots of others. In most of these, where the first IP address > is referenced, you would need to add logic to use the first IP address > OR the second IP address. This would mean both IPv4 and IPv6. > > Supporting the second address has size/performance implications and > probably should be a Kconfig option. > > That would be a significant effort, but not overwhelmingly impossible. > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
