netctl: unexpected authentication state: alg 57980 (expected 0) tra...

cfr · 2026-10-17 01:20:20

seth wrote:

Look in the journal?
Yes. NM is and makes wpa_supplicant very chatty - you'll see what AP is being used and whether there issues.

I looked at 2 journals involving 4 connections. NM does not seem to have any trouble. 3 of the 4 times it connected to the problematic *:89 node. However, on the other occasion it connected to *:81. That's weird b/c I'd expect it to always connect to *:89. That node is sitting almost next to the PC because the PC typically struggles to pick up signals and has problems if a node is in a different upstairs room. Here it is choosing to connect to a node downstairs and across the house. However, I could not see anything to suggest an attempt to connect to *:89 failed. It looked as if it did not try. Aside from that, the only problems seemed to be Fedora starting wpa_supplicant before NM, which caused some confusion at the beginning. But there were no failed connection attempts that I could see. Connection always succeeded on the 1 of 3 attempt. No `alg 57980` stuff or failed authentication at all.

seth wrote:

If there is a problem with them would that affect all the nodes? Or could one have a specific issue?
Either.
The specific node could just be buggy (though your original journal showed multiple failures after the initial disconnect) or it could be a matter of hop-count (ie. talking to a node that talks to another node that only then talks to the node attached to the modem - there seems a feature discrimination between the MW2/MW3/MW5/MW5s/MW6/MW12 models
You could try to connect the troublemaker to the modem and connect to it there - if it still acts up, it's likely that node.

OK. I will give this a shot.

seth wrote:

You said before that the network should maybe be configured in bridge mode.
This completely depends on whether thy're attached to a more or less dumb modem or whether that's actually an integrated device that also provides routing.
If it's a plain modem, the bridge mode won't work at all.
I also now suspect that this is a unary setting affecting how the entire mesh connects to the internet and doesn't at all control its communication between the nodes.

Yes, I am sure it configures how the mesh connects to the internet.

The modem can provide routing (I think?), dynamic IP etc. Before we got the mesh, it provided the wireless network. Right now it is (hopefully, anyway) not configured to do that. The main problem with doing it that way is that it provides poor coverage in the back of the house, which is where the PC (and generally the laptop) want to connect. (I'm worried I'm getting lost at this point, though.)

seth wrote:

UPnP *is* enabled, which it was by default.
I don't think that's relevant here but make sure to be aware of https://en.wikipedia.org/wiki/Universal … y#Problems (tl;dr it's a security nightmare and if you don't actually need it for sth. specific, the correct setting is "off")

I will disable it and see if anybody or anything complains .

seth wrote:

DNS is current configured to use the 'Automatic' 'obtaining method'. I've never been very happy about this, but have not been able to decide on an alternative.
If you get an automatic DNS from the https://en.wikipedia.org/wiki/Private_n … _addresses you can infer that your modem has a dns stub and most likely acts as router.
Other than that you only need to change the server if the current one (typically run by your ISP) is under-dimensioned (excessively slow response times compare to IP pings) or obeys to legal requirements you disagree with, specifically if they don't allow you to see https://images.thespinoff.co.nz/images/ … 60d1e5ae75 for stereotypical reasons

What I don't like is that 'automatic' seems to mean I get DNS from the manufacturer of the nodes and not the ISP.
I get a private one - from the mesh? I might just be completely wrong about what this means, though.

$ cat /etc/resolv.conf
# Generated by resolvconf
domain tendawifi.com
nameserver 192.168.5.1

seth · 2026-10-17 08:32:25

3 of the 4 times it connected to the problematic *:89 node … No `alg 57980` stuff or failed authentication at all.

Might be a problem w/ the notebooks chip/firmware/driver then - I suppose the PC uses a wifi dongle but you probably can't borrow that for a test?

The modem can provide routing (I think?), dynamic IP etc.

The mesh should™ then work in bridge mode, regardless of the current situation you want to make sure that there're not two dhcp servers in the LAN.
https://nmap.org/nsedoc/scripts/broadca … cover.html

192.168.5.1 is the mesh, not the modem/router?
Setting the mesh to operate in bridge mode should™ take care of this as well, but there's a good chance you're currently running a dnsmasq in the mesh that uses another dnsmasq in the modem as backend which is ultimately backed by the ISPs DNS.
Generally it's a very good idea to have a local DNS cache (in the mesh or modem or both or on top of that on the local system) because it will drastically speed up subsequent DNS queries (and since glibc and most programs don't cache DNS results internally, those can be many)

Arch Linux

#26 2026-10-17 01:20:20

Re: netctl: unexpected authentication state: alg 57980 (expected 0) tra...

#27 2026-10-17 08:32:25

Re: netctl: unexpected authentication state: alg 57980 (expected 0) tra...

Board footer