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.
-Justin
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
