[Buildroot] Problem with multi interface support in udhcpc script?
Peter Korsgaard
jacmet at uclibc.org
Tue Jan 21 16:25:18 UTC 2014
>>>>> "Danomi" == Danomi Manchego <danomimanchego123 at gmail.com> writes:
Hi,
> Rather than relying on the last search line winning for the future, I
> was thinking that the per-interface search lines should be comments,
> something like:
> nameserver ... # eth0
> #search foo # eth0
> nameserver ... # eth1
> #search bar # eth1
> search foo bar
> (Of course, you can replace "#search" with whatever you want.)
Sure, that's also fine.
> Also, if you run the little libresolv program that I sent earlier,
> then you'll see that the "#" and "COMBINED" show up as search domains
> - at least, I do, with both my Ubuntu 12.04 machine and with my
> embedded target compiled with CodeSourcery 2009q1-203. So I do not
> think that it is safe to have a comment on the aggregated search line.
Ok, as far as I can see uClibc atleast stops parsing on '#', but yeah,
not having it is safer.
> Therefore, if you must identify the combined search line then you
> might want to to grep for '^search '. I was thinking that perhaps it
> would be better to just regenerate the whole thing each time - for
> example:
Yes, with a combined search line you alway need to regenerate the file.
> However, there is still a problem with this strategy - the order of
> the name servers and the search domains affect how DNS queries are
> made. Catting lines to the end of a file will make server and search
> domain priority a function of when DHCP info is acquired, not
> planning. So I ended up funneling all DNS info to our project's
> network app rather than relying on this script to do it for us, to
> roll my own "resolvconf". But then, incremental improvement is still
> improvement, so changing the way this scipt is now may still be a good
> thing.
Yes, you always have the option of using a custom udhcpc script, but it
makes sense to atleast try to do it correctly by default.
Thanks, I'll take a look at implementing it.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list