Jens Breuer wrote:
Hello List, hello Alain,
we finally tracked down the problem.
If dhcp is set to yes in the udpc.config and udpcdialog detects that the "ip" environment variable (set by pxelinux) is set, it will use the extracted IP together with the hardcoded interface name "eth0". Since eth0 hasn't got link in my testsetup ifconfig will fail and udpcdialog presents the error message described in my previous posts.
A workaround is to introduce an new config option where one can set the interface to use.
The easiest workaround would have been not to use the IPAPPEND option... But this is now fortunately moot after your and my fixes (see below).
The patch is added as an attachment (patch #04) of this email. Maybe you and others find it useful and maybe you could include it in the next version of udpcast (udpcdialog). The config option is called "defNic" and you use it by specifying a string like "eth1" to override the hardcoded "eth0" (e.g.: defNic=eth1).
The patches are now applied to version 20091031, after some cleanup (removed needless appending of spaces at end of some lines) and along with some refactoring in interface choosing code (support of BOOTIF, interface choosing also for other methods than dhcp).
Additionally while walking through the code, I think I spotted some potential errors.
Patch #01 fixes a potential buffer size problem. Might have been a typo. I saw a warning from gcc when building busybox.
Agreed & applied
Patch #02 fixes a compiler issue with gcc 4.3.3 which demands a third parameter to the open syscall. The build process of busybox stopped with an error.
Agreed & applied
Patch #03 makes sure that the correct option gets preselected in the use-dhcp-dialog-box.
No it doesn't. It choses exactly the contrary of what was configured. And what's worse, this is the _only_ thing that it does...
I hope that you get the time to review the patches and that you find them useful for inclusion in udpcdialog.
1, 2 and 4 were indeed useful, and are now applied. Thanks for these.
All of this has been done with the additional help of Tobias Selzer.
Kind regards, Jens
As a result of refactoring, now IPAPPEND 2 or IPAPPEND 3 should be used, rather than IPAPPEND 1.
Thanks,
Alain