Hi Marcel, On 18.03.2015 23:14, Marcel Holtmann wrote: > Hi Andreas, > >> first of all: Whenever you boot from NFS and change your network device >> address, the system is going to freeze. This goal of this patch is to be >> able to run ConnMan in an nfsroot (during development) with as little >> difference to a local boot as possible. There may be additional wireless >> devices attached which need to get configured by ConnMan and a user >> interface should be able to query online states and parameters from >> ConnMan, even though no big changes are allowed to the interface >> carrying the connection to the NFS server. >>> >>>> Booting an nfsroot with connman requires passing -I eth0 to ignore >>>> the interface. This isn't very nice, for at least the following >>>> reasons: >>>> >>>> * A User interface based on connman is led to believe that there's no >>>> network interface and thus connman seems to be offline when it's not. >>>> * The DHCP lease obtained by the kernel won't get renewed. >>>> * DNS servers won't get obtained from DHCP, thus requiring a workaround >>>> to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. >>> >>> this sentence makes no sense to me. I do not even know what /proc/net/pnp >>> actually is. >> >> When passing ip=dhcp to the kernel, which is common for nfsroot setups, >> Linux generates a resolv.conf at /proc/net/pnp, just as a reference, >> without anybody using the nameservers listed in it. >> >> So what you get is a network device configured with DHCP but no working >> nameserver setup. And even if you fix it manually, you have to change >> ConnMan's behaviour (compared to a boot from local storage) by passing >> -r to it to disable the DNS proxy or otherwise it will overwrite >> resolv.conf again, without being able to actually resolve anything >> (because of -I eth0). > > you learn something new every day. I did not know about /proc/net/pnp. And > honestly that naming is horrible and non intuitive at all. > > However this makes this really simple. I think that ConnMan needs to learn on > how to deal with /proc/net/pnp and if that is present honor its information. > Can you post and example of that file here. I never boot over NFS so that > might be reason I never have seen that file in my life. >
#PROTO: DHCP domain example.com nameserver 192.168.1.1 bootserver 192.168.1.2 See pnp_seq_show() in net/ipv4/ipconfig.c of Linux. > I get the feeling that once we handle the presence of this file properly as > an external config (meaning immutable service), then this will all start > working nicely. No need to hack "read-only" into the whole codebase. ConnMan > already has the concept of immutable services. This would solve part of the problem, the DNS functionality. Still (typically) eth0 wouldn't show up in a ConnMan user interface and DHCP leases wouldn't get renewed. We need ConnMan to do DHCP. Parsing /proc/net/pnp wouldn't yield any information that ConnMan couldn't obtain from DHCP itself. In case of manual configuration, there's no way to specify a nameserver on the kernel cmdline. I'll try what Jukka suggested, as it would be less invasive than my first approach. Regards, Andreas _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
