is that udhcpc is already well into it's DHCP requests before the kernel has even noticed that the network link is up, so a considerable amount of the total time udhcpc is willing to wait, is lost without any requests making it out of the board.
The DHCP server then only has a short amount of time to respond. On a smaller network that is probably fine, but with the large amount of devices in our and the sheer amount of DHCP traffic it's likely taking just a tiny bit too long to respond and the board has already given up.
As I've mentioned before, a recurring theme in the logs you have linked:
http:// validation. linaro. org/scheduler/ job/79440/ log_file# L_15_435 validation. linaro. org/scheduler/ job/79424/ log_file# L_31_367 validation. linaro. org/scheduler/ job/78934/ log_file# L_15_367 validation. linaro. org/scheduler/ job/78926/ log_file# L_29_366
http://
http://
http://
is that udhcpc is already well into it's DHCP requests before the kernel has even noticed that the network link is up, so a considerable amount of the total time udhcpc is willing to wait, is lost without any requests making it out of the board.
The DHCP server then only has a short amount of time to respond. On a smaller network that is probably fine, but with the large amount of devices in our and the sheer amount of DHCP traffic it's likely taking just a tiny bit too long to respond and the board has already given up.