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