[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