Re: Issues with long connection time with 802.1x on cable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2017-01-15 at 01:14 +0100, dennis knorr wrote:
> Hi,
> i work for a city administration in the south of germany and we want
> to
> migrate to 802.1x for client authentication via cable and wireless
> LAN.
> Therefore we created a networkmanager profile with 802.1x with
> certificates to authenticate to the switch (we use a different
> profile
> for wirelesslan). so far so good.
> 
> Now we noticed that if the switch is not already set for 802.1x
> client
> authentication, wpasupplicant tries for over a minute establishing
> the
> connection (3 tries), after that, i stops and networkmanager falls
> back
> to a non-802.1x connection. (802.1x authentication and fallback to
> MacByPass with ACLs if there's no certificate, at least during the
> migration time). It is even worse, because of PXE-delay, because we
> provision clients via PXE.
> 
> This looks quite bad to Windows in comparison. First the retries
> occur
> much faster and it is less of them. Secondly, even with the
> eapol-request, there is already a dhcp-request to the network if
> there's
> a link with resulting in a quicker network connection, even if
> there's
> no valid 802.1x connection.
> 
> So i looked in networkmanager and wpa_supplicant if i could configure
> the timeout and retries and did not find anything, where i could
> configure eapol timeouts and retries. Is it possible that this would
> be
> implemented? Should i open a ticket? I will ask the networkmanager
> devs,
> too, but i thought asking would not hurt.
> 
> Any opinions or information on the matter? The Linuxclientguys from
> munich would be glad :-)

NM fires off the supplicant configuration and waits a specific period
of time for the connection to work.  That's about 15 seconds IIRC.  If
that fails, NM will try the connection a few more times (3?) before it
falls back to another connection.  Which probably accounts for the 1
minute delay.

NM 1.6 will introduce a per-connection "autoconnect retries" option
that would also help your issue.  You could reduce the autoconnect
retries for the 802.1X connection and then you'd get perhaps 15 seconds
or 30 seconds before NM fell back to the clear one.

If you ask the NM team might even backport it to 1.4; the branch
doesn't look that bad.  That should probably be done on the NM mailing
list though.

https://bugzilla.gnome.org/show_bug.cgi?id=763524

Dan

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux