issue with dhcp on buildroot

Buildroot Michael Schweikart 3 participants 5 messages Nov 11, 2015

Share & tools

Michael Schweikart

author

2015-11-11 08:47 UTC #0 lore raw

Hi,

i have setup a buildroot environment and build it. I deploy it on device under test and the systems boots up(Kernel Version 4.3). As soon as the network and udhcpc (v1.24.1) starts i get the following messages.

Sending discover...
udhcpc: sendto: Invalid argument.
Sending discover...
udhcpc: sendto: Invalid argument.
No lease, failing

If i setup an static ip address i am able to ping the device under test. I try to ping a IP form the device under test i get the following error.

ping: sendto: Destination address required

Is there anybody out there how can support me?

best regards

Arnout Vandecappelle

2015-11-11 10:48 UTC #1 lore raw

Quoted 11 lines · Michael Schweikart

Hi,
i have setup a buildroot environment and build it. I deploy it on device under test and the systems boots up(Kernel Version 4.3). As soon as the network and udhcpc (v1.24.1) starts i get the following messages.
Sending discover...
udhcpc: sendto: Invalid argument.
Sending discover...
udhcpc: sendto: Invalid argument.
No lease, failing

Is it possible that the Ethernet device doesn't exist yet when udhcpc starts?

When you start it from the command line, does it work?

Quoted 5 lines

If i setup an static ip address i am able to ping the device under test. I try to ping a IP form the device under test i get the following error.
ping: sendto: Destination address required

So you did the following:

ifconfig eth0 up 192.168.1.1
ping 192.168.1.2

and you get the 'Destination address required' error?

Does ping to the configured address work?

When you wireshark the link, do you see anything coming out?

Regards,
Arnout

Quoted 9 lines

Is there anybody out there how can support me?
best regards
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Michael Schweikart

author

2015-11-11 10:58 UTC #2 lore raw

Hi,

no if i start it from the command line it is the same behavior. Yes ping to the configured device works.

best regards

Quoted 44 lines · Arnout Vandecappelle

Quoted 11 lines · Michael Schweikart
Hi,
i have setup a buildroot environment and build it. I deploy it on device under test and the systems boots up(Kernel Version 4.3). As soon as the network and udhcpc (v1.24.1) starts i get the following messages.
Sending discover...
udhcpc: sendto: Invalid argument.
Sending discover...
udhcpc: sendto: Invalid argument.
No lease, failing
Is it possible that the Ethernet device doesn't exist yet when udhcpc starts?
When you start it from the command line, does it work?
Quoted 4 lines
If i setup an static ip address i am able to ping the device under test. I try to ping a IP form the device under test i get the following error.
ping: sendto: Destination address required
So you did the following:
ifconfig eth0 up 192.168.1.1
ping 192.168.1.2
and you get the 'Destination address required' error?
Does ping to the configured address work?
When you wireshark the link, do you see anything coming out?
Regards,
Arnout
Quoted 8 lines
Is there anybody out there how can support me?
best regards
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Gustavo Zacarias

2015-11-11 11:40 UTC #3 lore raw

In reply to Michael Schweikart

Quoted 12 lines · Michael Schweikart

Hi,
i have setup a buildroot environment and build it. I deploy it on device under test and the systems boots up(Kernel Version 4.3). As soon as the network and udhcpc (v1.24.1) starts i get the following messages.
Sending discover...
udhcpc: sendto: Invalid argument.
Sending discover...
udhcpc: sendto: Invalid argument.
No lease, failing

Quoted 8 lines

If i setup an static ip address i am able to ping the device under test. I try to ping a IP form the device under test i get the following error.
ping: sendto: Destination address required
Is there anybody out there how can support me?
best regards

Hi, by any chance is that x86? (not x86_64)
Because kernel 4.3 and uclibc don't see eye-to-eye and this is one of the problems i've got when trying that combination. Switching to some other libc (musl, glibc) has no problem, and any uclibc variant has this problem.
I guess it's related to the x86 vm86 patches/rework that went into 4.3, since rolling back to 4.2.x makes the problem go away. Regards.

Michael Schweikart

author

2015-11-11 16:56 UTC #4 lore raw

Hi,

yes you are completely right. The configuration is for a x86. When I change to the glibc it works.
Many thanks.

best regards

Quoted 35 lines · Gustavo Zacarias

Quoted 18 lines · Michael Schweikart
Hi,
i have setup a buildroot environment and build it. I deploy it on device under
test and the systems boots up(Kernel Version 4.3). As soon as the network and
udhcpc (v1.24.1) starts i get the following messages.
Sending discover...
udhcpc: sendto: Invalid argument.
Sending discover...
udhcpc: sendto: Invalid argument.
No lease, failing
If i setup an static ip address i am able to ping the device under test. I try
to ping a IP form the device under test i get the following error.
Quoted 5 lines
ping: sendto: Destination address required
Is there anybody out there how can support me?
best regards
Hi, by any chance is that x86? (not x86_64)
Because kernel 4.3 and uclibc don't see eye-to-eye and this is one of the problems i've got when trying that combination. Switching to some other libc (musl, glibc) has no problem, and any uclibc variant has this problem.
I guess it's related to the x86 vm86 patches/rework that went into 4.3, since rolling back to 4.2.x makes the problem go away. Regards.