Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe 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: connman 1.33 yocto pyro and 'online' state (Daniel Wagner)
   2. Re: Disconnect with unspecified reason leads to network being blocked
      (Daniel Wagner)
   3. [PATCH 1/2] vpn: Annotate fallthrough correctly (Daniel Wagner)
   4. [PATCH 2/2] wifi: Do no disconnect when disconnect code is unspecified 
reason
      (Daniel Wagner)
   5. Re: [PATCH 2/2] wifi: Do no disconnect when disconnect code is 
unspecified reason
      (Daniel Wagner)


----------------------------------------------------------------------

Date: Fri, 30 Oct 2020 08:49:59 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: connman 1.33 yocto pyro and 'online' state
To: Mauro Ziliani <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1

Hi Mauro,

On Mon, Oct 26, 2020 at 08:02:48AM +0100, Mauro Ziliani wrote:
> Hi all
> 
> I put connman in my bsp (yocto pyro on imx6dl)
> 
> Connman receive the setup from dhcp on eth0, with all informations on dns,
> gateway and so on.
> 
> The state of connman and eth0 stay 'ready'.
> 
> If I setupĀ  the nameservers by hands from connmanctl with
> 
> 
> config ethernet_XXXX --nameservers 8.8.4.4

This sounds like ConnMan doesn't get the nameserver from the DHCP
reply and you need to specify it by hand. I assuming your DHCP server
setup correctly, the DHCP reply is not decoded correctly. One quick test
would be to try an newer version of ConnMan. Maybe we have fixed it
already and if that is not the case enable the debug output with
something like

  CONNMAN_DHCP_DEBUG=1 CONNMAN_DHCPV6_DEBUG=1 connmand -n -d  
src/dhcp.c:src/dhcp6.c

Thanks,
Daniel

------------------------------

Date: Fri, 30 Oct 2020 09:00:00 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Disconnect with unspecified reason leads to network being
        blocked
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Christopher,

On Thu, Oct 29, 2020 at 07:11:44PM -0000, [email protected] wrote:
> On a Cisco wireless controller, in the case of a session timeout my
> devices sometimes get deathenticated with reason code 1 (unspecified
> reason) - in this case it seems connman assumes that the client was
> blocked, when that's not necessarily the case (code from
> plugins/wifi.c below).

Sounds familiar, IIRC we had a discussion maybe a year ago on this topic
but no resolution.

The only safe thing to do is not to reconnect as we don't know why we
got disconnected. If the reason is that the password has changed with a
reconnect attempt ConnMan might get permanently blocked.

> Is this the correct behavior?

I think yes and Cisco wireless controller could send proper disconnect
codes. Anyway, that is nice in theory, the real world needs real
solutions. The original bug report was only for the '6' case, so I am
going to drop the '1' case.

> Is there any way to unblock the network without re-starting connman?

Yes, just connect the service again.

Thanks,
Daniel

------------------------------

Date: Fri, 30 Oct 2020 09:10:57 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 1/2] vpn: Annotate fallthrough correctly
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>

gcc is complaining as it doesn't reconnize the comment. Update
the comment so that gcc is happy.
---
 vpn/vpn-util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/vpn/vpn-util.c b/vpn/vpn-util.c
index abd2cd34b85c..9ef14d38c235 100644
--- a/vpn/vpn-util.c
+++ b/vpn/vpn-util.c
@@ -175,7 +175,8 @@ int vpn_util_create_path(const char *path, uid_t uid, gid_t 
grp, int mode)
                if (!g_file_test(dir_p, G_FILE_TEST_IS_DIR))
                        goto out;
 
-               /* Fall through to chmod as the dir exists */
+               /* Do a chmod as the dir exists */
+               /* fallthrough */
        case -EISDIR:
                /* Exists as dir, just chmod and change owner */
                err = g_chmod(dir_p, mode);
-- 
2.29.0

------------------------------

Date: Fri, 30 Oct 2020 09:10:58 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 2/2] wifi: Do no disconnect when disconnect code is
        unspecified reason
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>

Cisco wireless controllers seem to send the disconnect code 1
sometimes. It could be a very dirty way to get the client moving to a
different AP.

Anyway, the '1' case was added as precaution and doesn't have any real
bug report behind it. So let's drop it as we had two independent
reports that ConnMan is not doing the right thing.
---
 plugins/wifi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 74b773bc7cb1..be05dd268e4b 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2547,9 +2547,6 @@ static void interface_state(GSupplicantInterface 
*interface)
 
                /* See table 8-36 Reason codes in IEEE Std 802.11 */
                switch (wifi->disconnect_code) {
-               case 1: /* Unspecified reason */
-                       /* Let's assume it's because we got blocked */
-
                case 6: /* Class 2 frame received from nonauthenticated STA */
                        connman_network_set_error(network,
                                                CONNMAN_NETWORK_ERROR_BLOCKED);
-- 
2.29.0

------------------------------

Date: Fri, 30 Oct 2020 09:12:59 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 2/2] wifi: Do no disconnect when disconnect code
        is unspecified reason
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

On Fri, Oct 30, 2020 at 09:10:58AM +0100, Daniel Wagner wrote:
> Cisco wireless controllers seem to send the disconnect code 1
> sometimes. It could be a very dirty way to get the client moving to a
> different AP.
> 
> Anyway, the '1' case was added as precaution and doesn't have any real
> bug report behind it. So let's drop it as we had two independent
> reports that ConnMan is not doing the right thing.

Both patches applied.

------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]


------------------------------

End of connman Digest, Vol 60, Issue 29
***************************************

Reply via email to