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.
some kernel people should not design interfaces. At least add the ifindex or
ifname into this so people can figure out which interface it belongs to. That
should be patches in the upstream kernel.
#IFINDEX: 2
That is what I would expect to be added to really know which interface is
handled by the kernel. Who is taking charge of adding this extra information to
the kernel?
>> 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.
The kernel does not do DHCP renewals? That is odd now. How do we get the state
of the current lease then?
> In case of manual configuration, there's no way to specify a nameserver
> on the kernel cmdline.
I think I read there is a possibility to put DNS servers in the cmdline. Then
again, turning this into an immutable service from a ConnMan point of view just
makes sense.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
