Hi Justin
On 05/08/2013 04:28 AM, Justin Maggard wrote:
On Tue, Mar 19, 2013 at 2:54 PM, Justin Maggard <[email protected]> wrote:
On Tue, Mar 19, 2013 at 2:03 AM, Daniel Wagner
<[email protected]> wrote:
From: Daniel Wagner <[email protected]>
---
Hi,
It seems we having the same problems for internal project. In our
case the router starts slower than the embedded board. ConnMan
falls back to IPv4LL because the router does not answer the DHCP request.
This patch here is completely untested but I think you get the idea :)
cheers,
daniel
I tried the patch, and it does detect when a DHCP server comes online if it
comes online quickly after the initial timeout. But the DHCP IP address never
gets set.
However, in my isolated switch test, things go south. Seems there are some
nested callbacks, which eventually puts us in a situation where we have many,
many DHCP and IPv4LL address requests going on concurrently. After less than
10 minutes, of being connected to an isolated switch, connmand crashes with
these errors:
Mar 19 14:15:04 justin-rn314 connmand[8345]: connman_inet_set_address:
Too many open files
Mar 19 14:15:04 justin-rn314 connmand[8345]:
connman_inet_clear_address: Too many open files
Mar 19 14:15:04 justin-rn314 connmand[8345]:
connman_inet_clear_address: Invalid argument
Mar 19 14:15:04 justin-rn314 connmand[8345]:
connman_inet_clear_ipv6_address: Invalid argument
Mar 19 14:15:04 justin-rn314 connmand[8345]: Aborting (signal 11)
[/usr/sbin/connmand]
I spent a little time today working with the previous patch, and
unfortunately it looks like the changes will need to be quite a bit
more invasive than that.
So, for the first issue, I believe the DHCP request flooding is due to
the DHCP retry timer getting set to 5 seconds, but it takes ~30
seconds to complete an unsuccessful DHCP request. If I change the
g_timeout_add_seconds() value to 45 instead of 5, it doesn't look as
crazy. Also, there does appear to be some recursion going on.
dhcp_request() ends up in ipv4ll_available_cb(), which indirectly
calls dhcp_request() again... and so on.
I also noticed that IPv4LL address discovery will be attempted every
time there is a failed DHCP request.
gdhcp/client.c:2384 - g_dhcp_client_start()
if (dhcp_client->retry_times == DISCOVER_RETRIES) {
ipv4ll_start(dhcp_client);
return 0;
}
So we'd probably need some sort of flag that tells
g_dhcp_client_start() that we already did IPv4LL, and we don't need to
do it again.
Thanks for the feedback. Yep, some more work is needed to get this
working nicely. Maybe you want to add your findings to the bug report:
https://bugs.meego.com/show_bug.cgi?id=25986
thanks,
daniel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
