7:39 p.m.
Hello!
We are on version 1.37, we are using wpa_supplicant 2.9 with a kernel 4.19. When we are
trying to use the connmanctl to connect to a protected wifi network it works well without
a problem. However, if we make a mistake when we type the passphrase, it's impossible
to retry. It does that to any network that we have tried.
It is impossible to retry because for some reason when we are asked to retry
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...),
this gets "cancel" by the agent
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...)
and we lose the ability to retry forever for this network unless we delete the settings
for this particular network. I never get a chance to enter yes or no. It never enters the
callback
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...),
that was set at line 365 in client/agent.c
We looked at the d-bus-monitor and we get two types of error: `-3` and we do get a `16`,
from 80211 AssocCode status code. -3 from what I can understand is internal.
Now, since I have not seen this issue from others, I'm wondering if it's related
to our wifi chip misbehaving? I heard about a new thing called `iwd`, but I haven't
tested it, maybe I could give this a shot.
Thanks,
Max
8:40 a.m.
Hi Max,
On Thu, Jan 30, 2020 at 01:39:50AM -0000, maxime.roussinbelanger(a)gmail.com wrote:
We are on version 1.37, we are using wpa_supplicant 2.9 with a
kernel 4.19. When we are trying to use the connmanctl to connect to
a protected wifi network it works well without a problem. However,
if we make a mistake when we type the passphrase, it's impossible to
retry. It does that to any network that we have tried.
Just to make sure I understand you correctly. You enter a passphrase
which is incorrect and after that you can't enter a new pasphrase?
It is impossible to retry because for some reason when we are asked
to retry
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...),
this gets "cancel" by the agent
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...)
and we lose the ability to retry forever for this network unless we
delete the settings for this particular network. I never get a chance
to enter yes or no. It never enters the callback
(https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...),
that was set at line 365 in client/agent.c
I've tested the current head and version 1.37 on my system and there
was no problem with entering a wrong passhprase. If it's not correct I
get ask for a new pasphrase.
What do you mean by 'cancel'. Is the cancel from ConnMan?
We looked at the d-bus-monitor and we get two types of error: `-3`
and we do get a `16`, from 80211 AssocCode status code. -3 from what
I can understand is internal.
Which communication are you monitoring? ConnMan - wpa_supplicant? You
can also turn up the debug level on ConnMan side by setting the
environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
connman log 'connmand -n -d'
Accoring the WiFi spec, 16 means group key handshake timeout.
I've tried to simulate the timeout by not entering a passphrase but
again, it's still working for me.
Now, since I have not seen this issue from others, I'm wondering
if
it's related to our wifi chip misbehaving? I heard about a new thing
called `iwd`, but I haven't tested it, maybe I could give this a
shot.
I would give iwd a shot. Because debugging wpa_supplicant is no fun
(and I personally wont invest time in wpa_supplicant anymore) and the
iwd developers are helping to fix problems.
BTW, the iwd project has an excellent debugging tool (iwmon) for
looking at the kernel nl80211 interface. You can monitor all the
traffic between wpa_supplicant or iwd and kernel.
Thanks,
Daniel
12:51 p.m.
On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <wagi(a)monom.org> wrote:
Hi Max,
On Thu, Jan 30, 2020 at 01:39:50AM -0000, maxime.roussinbelanger(a)gmail.com
wrote:
> We are on version 1.37, we are using wpa_supplicant 2.9 with a
> kernel 4.19. When we are trying to use the connmanctl to connect to
> a protected wifi network it works well without a problem. However,
> if we make a mistake when we type the passphrase, it's impossible to
> retry. It does that to any network that we have tried.
Just to make sure I understand you correctly. You enter a passphrase
which is incorrect and after that you can't enter a new pasphrase?
I can't enter a new passphrase, correct.
> It is impossible to retry because for some reason when we are asked
> to retry
> (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...
),
> this gets "cancel" by the agent
> (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...
)
> and we lose the ability to retry forever for this network unless
we
> delete the settings for this particular network. I never get a chance
> to enter yes or no. It never enters the callback
> (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/ag...
),
> that was set at line 365 in client/agent.c
I've tested the current head and version 1.37 on my system and there
was no problem with entering a wrong passhprase. If it's not correct I
get ask for a new pasphrase.
What do you mean by 'cancel'. Is the cancel from ConnMan?
After the 'timeout', I get the output `Agent request cancelled by ConnMan`.
This cancel the retry prompt. Which I can see, but instead I'm shown the
`connmanctl>`
to enter a connmanctl command.
> We looked at the d-bus-monitor and we get two types of error: `-3`
> and we do get a `16`, from 80211 AssocCode status code. -3 from what
> I can understand is internal.
Which communication are you monitoring? ConnMan - wpa_supplicant? You
can also turn up the debug level on ConnMan side by setting the
environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
connman log 'connmand -n -d'
I monitored both.
Accoring the WiFi spec, 16 means group key handshake timeout.
I've tried to simulate the timeout by not entering a passphrase but
again, it's still working for me.
I don't really know how WiFi works at a lower level, but it seems that if
I send the wrong password to the AP, the AP doesn't answer back. This
seems to trigger the timeout, or maybe the AP sends back a response, but
my device driver fails to handle the situation? We use brcm80211.
> Now, since I have not seen this issue from others, I'm wondering if
> it's related to our wifi chip misbehaving? I heard about a new thing
> called `iwd`, but I haven't tested it, maybe I could give this a
> shot.
I would give iwd a shot. Because debugging wpa_supplicant is no fun
(and I personally wont invest time in wpa_supplicant anymore) and the
iwd developers are helping to fix problems.
BTW, the iwd project has an excellent debugging tool (iwmon) for
looking at the kernel nl80211 interface. You can monitor all the
traffic between wpa_supplicant or iwd and kernel.
We've been using lttng to aggregate the tracing logs from
connman, wpa_supplicant and the kernel to have a complete
picture. This as not been easy to figure out what is going on, but
so far it seems to always relate to our hardware integration... (We have
other WiFi problems)
I'm not sure iwd will be helpful if our hardware integration is at
fault here... but it will give us more hints to where the problem is.
Thanks,
Max
Thanks,
Daniel
12:59 a.m.
Hi Max,
On Sun, Feb 02, 2020 at 01:51:10PM -0500, Maxime Roussin-Bélanger wrote:
On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <wagi(a)monom.org>
wrote:
After the 'timeout', I get the output `Agent request cancelled by ConnMan`.
Okay, I'm not sure if I saw this message when trying to provoke the
timeout.
This cancel the retry prompt. Which I can see, but instead I'm
shown the
`connmanctl>`
to enter a connmanctl command.
>
> > We looked at the d-bus-monitor and we get two types of error: `-3`
> > and we do get a `16`, from 80211 AssocCode status code. -3 from what
> > I can understand is internal.
>
> Which communication are you monitoring? ConnMan - wpa_supplicant? You
> can also turn up the debug level on ConnMan side by setting the
> environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
> connman log 'connmand -n -d'
I monitored both.
Can you upload the ConnMan log somehwere? I'd like to understand how
we end up canceling the request and then block any further
attempt.
> Accoring the WiFi spec, 16 means group key handshake timeout.
>
> I've tried to simulate the timeout by not entering a passphrase but
> again, it's still working for me.
I don't really know how WiFi works at a lower level, but it seems that if
I send the wrong password to the AP, the AP doesn't answer back. This
seems to trigger the timeout, or maybe the AP sends back a response, but
my device driver fails to handle the situation? We use brcm80211.
Okay, so there might be two problems. One is that ConnMan is gets
stuck in a state where you can't retry to connect with a new
password. The other sounds like a driver/firmware problem.
We've been using lttng to aggregate the tracing logs from
connman, wpa_supplicant and the kernel to have a complete
picture. This as not been easy to figure out what is going on, but
so far it seems to always relate to our hardware integration... (We have
other WiFi problems)
Nifty setup :)
I'm not sure iwd will be helpful if our hardware integration is
at
fault here... but it will give us more hints to where the problem is.
The nl80211 interface got a lot of bug fixes since iwd exists. Before
iwd there was only wpa_supplicant and the interface suffered from the
single user user problem. iwd exersices this API differently than
wpa_supplicant. This could paper over some of the problems or maybe
not.
If it is not to complicated to intergrate, give it a try. This gives
you at least some idea where the problem could be. And again iwmon is
an excellent tool for monitoring the interface. I don't know if lttng
is able to decode all the traces. Ususally, you can easily spot the
problems in the traces generated by iwmon.
Thanks,
Daniel
10:47 a.m.
Hi Daniel,
On Mon, Feb 3, 2020 at 1:59 AM Daniel Wagner <wagi(a)monom.org> wrote:
Hi Max,
On Sun, Feb 02, 2020 at 01:51:10PM -0500, Maxime Roussin-Bélanger wrote:
> On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <wagi(a)monom.org> wrote:
> After the 'timeout', I get the output `Agent request cancelled by
ConnMan`.
Okay, I'm not sure if I saw this message when trying to provoke the
timeout.
> This cancel the retry prompt. Which I can see, but instead I'm shown the
> `connmanctl>`
> to enter a connmanctl command.
>
> >
> > > We looked at the d-bus-monitor and we get two types of error: `-3`
> > > and we do get a `16`, from 80211 AssocCode status code. -3 from what
> > > I can understand is internal.
> >
> > Which communication are you monitoring? ConnMan - wpa_supplicant? You
> > can also turn up the debug level on ConnMan side by setting the
> > environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
> > connman log 'connmand -n -d'
>
> I monitored both.
Can you upload the ConnMan log somehwere? I'd like to understand how
we end up canceling the request and then block any further
attempt.
I tried to connect to
the wifi_b072bfc0a090_4f6d65676120506f696e74_managed_psk network.
The connect starts at line 567, and we get an error not long after at line
576.
https://drive.google.com/open?id=1TESYkngpIRK-QtyRxdaCXZN-5sdReFzO
I have uploaded a picture to show what kind of output I get.
> > Accoring the WiFi spec, 16 means group key handshake timeout.
> >
> > I've tried to simulate the timeout by not entering a passphrase but
> > again, it's still working for me.
>
> I don't really know how WiFi works at a lower level, but it seems that
if
> I send the wrong password to the AP, the AP doesn't answer
back. This
> seems to trigger the timeout, or maybe the AP sends back a response, but
> my device driver fails to handle the situation? We use brcm80211.
Okay, so there might be two problems. One is that ConnMan is gets
stuck in a state where you can't retry to connect with a new
password. The other sounds like a driver/firmware problem.
> We've been using lttng to aggregate the tracing logs from
> connman, wpa_supplicant and the kernel to have a complete
> picture. This as not been easy to figure out what is going on, but
> so far it seems to always relate to our hardware integration... (We have
> other WiFi problems)
Nifty setup :)
> I'm not sure iwd will be helpful if our hardware integration is at
> fault here... but it will give us more hints to where the problem is.
The nl80211 interface got a lot of bug fixes since iwd exists. Before
iwd there was only wpa_supplicant and the interface suffered from the
single user user problem. iwd exersices this API differently than
wpa_supplicant. This could paper over some of the problems or maybe
not.
I'll start testing iwd and see what kind of log I get.
If it is not to complicated to intergrate, give it a try. This gives
you at least some idea where the problem could be. And again iwmon is
an excellent tool for monitoring the interface. I don't know if lttng
is able to decode all the traces. Ususally, you can easily spot the
problems in the traces generated by iwmon.
Well, working with yocto has some advantages :) Shouldn't be too hard.
Thanks,
Max.
Thanks,
Daniel
2:28 a.m.
On Mon, Feb 03, 2020 at 11:47:41AM -0500, Maxime Roussin-Bélanger wrote:
After sending out the 'ReportError' in
connman_agent_report_error_full(), we keep going the state machine:
../connman-1.37/src/agent.c:connman_agent_report_error_full() agent 0x55abc416f0 sender
:1.16 context 0x55abc355f0 path /net/connman/connmanctl1528
../connman-1.37/src/agent.c:connman_agent_queue_message() driver 0x557d20cc88
../connman-1.37/src/service.c:connman_service_ref_debug() 0x55abc355f0 ref 2 by
../connman-1.37/src/service.c:7438:agent_context_ref()
../connman-1.37/src/service.c:service_save() service 0x55abc355f0 new 1
../connman-1.37/src/connection.c:__connman_connection_update_gateway() default
0x55abc296b0
../connman-1.37/src/network.c:__connman_network_disconnect() network 0x55abc354c0
And then later the cancel request is send out (due to the state
machine entering disconnect state)
../connman-1.37/src/agent.c:connman_agent_cancel() context 0x55abc355f0
../connman-1.37/src/agent.c:connman_agent_cancel() cancel request 0x55abc349c0
../connman-1.37/src/agent.c:send_cancel_request() send cancel req to :1.16
/net/connman/connmanctl1528 iface net.connman.Agent
But there is nothing wierd about this. All looks good. I don't see
what's going wrong :(
5:06 p.m.
Hi Daniel! Tested iwd.
On Mon, Feb 3, 2020 at 1:59 AM Daniel Wagner <wagi(a)monom.org> wrote:
Hi Max,
On Sun, Feb 02, 2020 at 01:51:10PM -0500, Maxime Roussin-Bélanger wrote:
> On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <wagi(a)monom.org> wrote:
> After the 'timeout', I get the output `Agent request cancelled by
ConnMan`.
Okay, I'm not sure if I saw this message when trying to provoke the
timeout.
> This cancel the retry prompt. Which I can see, but instead I'm shown the
> `connmanctl>`
> to enter a connmanctl command.
>
> >
> > > We looked at the d-bus-monitor and we get two types of error: `-3`
> > > and we do get a `16`, from 80211 AssocCode status code. -3 from what
> > > I can understand is internal.
> >
> > Which communication are you monitoring? ConnMan - wpa_supplicant? You
> > can also turn up the debug level on ConnMan side by setting the
> > environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
> > connman log 'connmand -n -d'
>
> I monitored both.
Can you upload the ConnMan log somehwere? I'd like to understand how
we end up canceling the request and then block any further
attempt.
> > Accoring the WiFi spec, 16 means group key handshake timeout.
> >
> > I've tried to simulate the timeout by not entering a passphrase but
> > again, it's still working for me.
>
> I don't really know how WiFi works at a lower level, but it seems that
if
> I send the wrong password to the AP, the AP doesn't answer
back. This
> seems to trigger the timeout, or maybe the AP sends back a response, but
> my device driver fails to handle the situation? We use brcm80211.
Okay, so there might be two problems. One is that ConnMan is gets
stuck in a state where you can't retry to connect with a new
password. The other sounds like a driver/firmware problem.
> We've been using lttng to aggregate the tracing logs from
> connman, wpa_supplicant and the kernel to have a complete
> picture. This as not been easy to figure out what is going on, but
> so far it seems to always relate to our hardware integration... (We have
> other WiFi problems)
Nifty setup :)
> I'm not sure iwd will be helpful if our hardware integration is at
> fault here... but it will give us more hints to where the problem is.
The nl80211 interface got a lot of bug fixes since iwd exists. Before
iwd there was only wpa_supplicant and the interface suffered from the
single user user problem. iwd exersices this API differently than
wpa_supplicant. This could paper over some of the problems or maybe
not.
I started using iwd, and the first thing that happened was that I lost the
ability to
scan. Everytime I type `scan wifi`, from connmanctl, I get
`Error /net/connman/technology/wifi: Not Supported`. This error is -95.
The backtrace looks like:
manager.c:get_technologies()
technology.c:scan() technology 0x559d75d760 request from :1.19
connman_device_request_scan() device 0x559d7664d0 err -95
connman_device_request_scan() device 0x559d762ba0 err -95
technology.c:reply_scan_pending() technology 0x559d75f760 err -95
If it is not to complicated to intergrate, give it a try. This gives
you at least some idea where the problem could be. And again iwmon is
an excellent tool for monitoring the interface. I don't know if lttng
is able to decode all the traces. Ususally, you can easily spot the
problems in the traces generated by iwmon.
I had to add a bunch of cryptographic algorithm to the kernel to use iwd.
I analyzed the packets from iwmon with Wireshark and there was some
Malformed
packets error... We are using the 4.19 kernel, and iwd depends on a few
cryptographic
functions from 4.20. PKCS8 which is not in 4.19.
Thanks,
Max.
Thanks,
Daniel
1:52 a.m.
On Mon, Feb 03, 2020 at 06:06:08PM -0500, Maxime Roussin-Bélanger wrote:
Hi Daniel! Tested iwd.
Yay!
I started using iwd, and the first thing that happened was that I
lost the
ability to
scan. Everytime I type `scan wifi`, from connmanctl, I get
`Error /net/connman/technology/wifi: Not Supported`. This error is -95.
The backtrace looks like:
manager.c:get_technologies()
technology.c:scan() technology 0x559d75d760 request from :1.19
connman_device_request_scan() device 0x559d7664d0 err -95
connman_device_request_scan() device 0x559d762ba0 err -95
technology.c:reply_scan_pending() technology 0x559d75f760 err -95
Looks like you are using not the current head. I just recently updated
the iwd plugin. Before that the scan trigger was not implemented.
But that you can ignore this for the time being. You can also trigger
the scan by iwctl.
> If it is not to complicated to intergrate, give it a try. This
gives
> you at least some idea where the problem could be. And again iwmon is
> an excellent tool for monitoring the interface. I don't know if lttng
> is able to decode all the traces. Ususally, you can easily spot the
> problems in the traces generated by iwmon.
I had to add a bunch of cryptographic algorithm to the kernel to use iwd.
Yes, iwd uses the kernel cryptographic subsystem and doesn't ship it's own.
I analyzed the packets from iwmon with Wireshark and there was some
Malformed packets error...
That doesn't look too good. Are the malformed packets from the kernel
or from iwd? Either way I would reproduce this with a current kernel
and see if it's a problem. If yes, please report it upstream.
We are using the 4.19 kernel, and iwd depends on a few cryptographic
functions from 4.20. PKCS8 which is not in 4.19.
Ah, didn't think about this. Indeed the minimum vanilla kernel needed
is 4.20. Though I remember they iwd folks have maintained their
patches outside of the kernel for a while for all the different kernel
versions. Maybe you could pick those for the testing.
Thanks,
Daniel
11:19 a.m.
Hi Daniel! Same unfortunate problem with iwd 1.4 and connman master.
On Tue, Feb 4, 2020 at 2:52 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Mon, Feb 03, 2020 at 06:06:08PM -0500, Maxime Roussin-Bélanger wrote:
> Hi Daniel! Tested iwd.
Yay!
> I started using iwd, and the first thing that happened was that I lost
the
> ability to
> scan. Everytime I type `scan wifi`, from connmanctl, I get
> `Error /net/connman/technology/wifi: Not Supported`. This error is -95.
>
> The backtrace looks like:
>
> manager.c:get_technologies()
> technology.c:scan() technology 0x559d75d760 request from :1.19
> connman_device_request_scan() device 0x559d7664d0 err -95
> connman_device_request_scan() device 0x559d762ba0 err -95
> technology.c:reply_scan_pending() technology 0x559d75f760 err -95
Looks like you are using not the current head. I just recently updated
the iwd plugin. Before that the scan trigger was not implemented.
But that you can ignore this for the time being. You can also trigger
the scan by iwctl.
Updated to connman master and the error is now gone! Thanks.
> > If it is not to complicated to intergrate, give it a try. This gives
> > you at least some idea where the problem could be. And again iwmon is
> > an excellent tool for monitoring the interface. I don't know if lttng
> > is able to decode all the traces. Ususally, you can easily spot the
> > problems in the traces generated by iwmon.
>
> I had to add a bunch of cryptographic algorithm to the kernel to use
iwd.
Yes, iwd uses the kernel cryptographic subsystem and doesn't ship it's
own.
> I analyzed the packets from iwmon with Wireshark and there was some
> Malformed packets error...
That doesn't look too good. Are the malformed packets from the kernel
or from iwd? Either way I would reproduce this with a current kernel
and see if it's a problem. If yes, please report it upstream.
I started using iwd 1.4 and those malformed packets are gone.. So not an
issue anymore.
> We are using the 4.19 kernel, and iwd depends on a few cryptographic
> functions from 4.20. PKCS8 which is not in 4.19.
Ah, didn't think about this. Indeed the minimum vanilla kernel needed
is 4.20. Though I remember they iwd folks have maintained their
patches outside of the kernel for a while for all the different kernel
versions. Maybe you could pick those for the testing.
I don't know if you have seen my previous reply with the screenshot and the
log output, but I have the same problem with connman where the retry fails.
If I use `iwctl` I can retry the connection to an AP if I entered an
incorrect password.
Maybe connmanctl has an edge case (mine) where for my particular error it
doesn't
handle it well? I think that if you see the screenshot, you might have
better intuition.
I'll be in the #connman IRC if you want to talk in realtime.
Thanks,
Maxime.
Thanks,
Daniel
11:37 a.m.
Hi Max,
On Tue, Feb 04, 2020 at 12:19:10PM -0500, Maxime Roussin-Bélanger wrote:
Updated to connman master and the error is now gone! Thanks.
That is good news!
I started using iwd 1.4 and those malformed packets are gone.. So not
an
issue anymore.
Good to know.
I don't know if you have seen my previous reply with the
screenshot and the
log output, but I have the same problem with connman where the retry fails.
I did see it and tried to figure out what's going on. Though run out of time.
If I use `iwctl` I can retry the connection to an AP if I entered an
incorrect password.
That is a good test. That means if you just use iwd/iwctl there is no
problem. With this information it's clear ConnMan is doing something
wierd. It's propably the agent code in ConnMan which gets confused by
the error from the wpa_supplicant plugin but also with the iwd plugin.
Maybe connmanctl has an edge case (mine) where for my particular
error it
doesn't
handle it well? I think that if you see the screenshot, you might have
better intuition.
Indeed the screenshot was helping. One thing I see there is WPS. Maybe
this is the thing which makes thing go wrong. Could you try to disable
WPS and see if this makes a difference?
I'll be in the #connman IRC if you want to talk in realtime.
I'm also there. Though during office hours it's kind of difficult to
do hobby projects :)
Thanks,
Daniel
1:49 p.m.
Hello!
On Tue, Feb 4, 2020 at 12:37 PM Daniel Wagner <wagi(a)monom.org> wrote:
Hi Max,
On Tue, Feb 04, 2020 at 12:19:10PM -0500, Maxime Roussin-Bélanger wrote:
> Updated to connman master and the error is now gone! Thanks.
That is good news!
> I started using iwd 1.4 and those malformed packets are gone.. So not an
> issue anymore.
Good to know.
> I don't know if you have seen my previous reply with the screenshot and
the
> log output, but I have the same problem with connman where the
retry
fails.
I did see it and tried to figure out what's going on. Though run out of
time.
> If I use `iwctl` I can retry the connection to an AP if I entered an
> incorrect password.
That is a good test. That means if you just use iwd/iwctl there is no
problem. With this information it's clear ConnMan is doing something
wierd. It's propably the agent code in ConnMan which gets confused by
the error from the wpa_supplicant plugin but also with the iwd plugin.
> Maybe connmanctl has an edge case (mine) where for my particular error
it
> doesn't
> handle it well? I think that if you see the screenshot, you might have
> better intuition.
Indeed the screenshot was helping. One thing I see there is WPS. Maybe
this is the thing which makes thing go wrong. Could you try to disable
WPS and see if this makes a difference?
Actually, I was trying to connect to a random AP that was in the list, and
it has the wps
support, but if I try to connect to any other network I do have the same
problem.
Thanks,
Max.
> I'll be in the #connman IRC if you want to talk in realtime.
I'm also there. Though during office hours it's kind of difficult to
do hobby projects :)
Thanks,
Daniel
1:55 a.m.
On Tue, Feb 04, 2020 at 02:49:11PM -0500, Maxime Roussin-Bélanger wrote:
> Indeed the screenshot was helping. One thing I see there is WPS.
Maybe
> this is the thing which makes thing go wrong. Could you try to disable
> WPS and see if this makes a difference?
Actually, I was trying to connect to a random AP that was in the
list, and it has the wps support, but if I try to connect to any
other network I do have the same problem.
Okay, so it's something else.
8:57 a.m.
For anyone finding this thread from search engines, there is a workaround patch :
https://lists.01.org/hyperkitty/list/connman@lists.01.org/thread/HW72S2JI...
357
days inactive
364
days old
12 comments
3 participants
participants (3)
-
Daniel Wagner -
Maxime Roussin-Bélanger -
maxime.roussinbelanger＠gmail.com