Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: HA: Problem with reconnect to WiFi (Tomasz Bursztyka)
2. Re: Waiting time to restart DHCP after receiving DHCPNAK
(Patrik Flykt)
3. Re: Problem with reconnect to WiFi (Tomasz Bursztyka)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Feb 2016 13:29:30 +0100
From: Tomasz Bursztyka <[email protected]>
To: Pushkin Andrei <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: HA: Problem with reconnect to WiFi
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Andrei,
> But why it does not reconnect after reboot my device or after I reboot my AP.
> GetServices show me that AutoConnect is true.
Bad timing? Restart your AP, wait a minute, restart your device. Does it
work that way?
Connman does not try and retry in a loop to reconnect.
Tomasz
------------------------------
Message: 2
Date: Fri, 05 Feb 2016 15:37:27 +0200
From: Patrik Flykt <[email protected]>
To: Saurav Babu <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Waiting time to restart DHCP after receiving DHCPNAK
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-02-04 at 18:58 +0530, Saurav Babu wrote:
> Hi All,
> When connman's gdhcp client receives DHCPNAK message then it restarts DHCP
> after 3sec. Is there any specific reason for this delay of 3sec?
The reasoning seems to have been that some delay is needed before
retrying. Apparently 3s seemed like a good option at the time.
> In RFC 2131 "If the client receives a DHCPNAK message, it cannot
> reuse its remembered network address. It must instead request a new
> address by restarting the configuration process, this time using the
> (non-abbreviated) procedure described in section 3.1. This action also
> corresponds to the client moving to the INIT state in the DHCP state diagram."
>
> I didn't find any specific waiting time after receiving DHCPNAK messages in
> RFC.
> Is it fine to reduce this waiting time?
As it so happens, systemd-networkd has seen the same kind of issue. But
here it was noted that systemd-networkd was then flooding the server
with too many requests, so it implemented a strategy to avoid that. See
systemd commit 1d1a3e0afb85478cda43670b8ed92a6db6c83f3e. From the above
it shows that the time cannot be reduced, rather that one wants to retry
by gracefully lengthen the intervals instead. So something similar
should be implemented in ConnMan if this problem is to be tackled.
Cheers,
Patrik
------------------------------
Message: 3
Date: Fri, 5 Feb 2016 15:14:26 +0100
From: Tomasz Bursztyka <[email protected]>
To: Pushkin Andrei <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Problem with reconnect to WiFi
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Ok, it's been a while since I read connman logs, but it seems you have
ethernet cable plugged
in (and it autoconnects at boot time), right?
That would explain why connman does not connect wifi: it's already
connected through ethernet.
Tomasz
> My connman logs here (from linux start) http://pastebin.com/barFFp6a
> wpa_supplicant version 2.0. wpa_supplicant logs I paste soon.
>
>
> Andrei Pushkin
>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 7
*************************************
