networkmanager and hostapd - wireless managed as wired
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to build a gateway/AP with two SSID managed by hostapd without completely disabling NetworkManager. Base is CentOS7 My current setup looks like this and works. +++-++ || enp5s6 - public IP by DHCP || || || || managed by NM|| || || || || |+-^^---+| | ||| | +--MASQ-++MASQ-+ | | | | | +--+---+--+ +-+---+--+ || br0 - 192.168.1.0/24 +<-+ | br1 - 192.168.50.0/24 || || created by network | XXX | created by network|| || managed by NM, | +->+ managed by NM || ||| | || |---+-- --+--| || enp7s0 | wlp6s0| wlp6s0.1 || || joined to br0| | || || by network | | created and managed by hostapd|| || | | joined to br1 on creation || || | +| || | managed by hostapd|| || | joined to br0 by hostapd || +---+-- -+ - br0 is interal network comprised of wired enp7s0 and wireless wlp6s0 (wireless managed by WPA2 Enterpise), - br1 is public guest wifi network with WPA2 Consumer. There is no routing between the two. - Both are MASQeraded to external interface (enp5s6). - Firewall and masquerading is managed by firewalld. All config is kept in /etc/sysconfig/ifcfg-* files, so during bootup networking could be assembled by old networking initscript (it is not disabled). I'd like to let NetworkManager manage all interfaces, unfotunately as for now it does not allow me to manage only III layer and up without touching II Iayer of wifi interface (or I was not able to find appropriate setting). Thus I had to create br1 to separate IP configuration (managed by NM) and let hostapd manage AP functionality on virtual wlp6s0.1. This seem to be unnecessary, but I could not make it work any other way. My questions: 1. Is is it possible to make NetworkManager manage a wifi interface just as an ordinary wired ethernet (no fooling around wireless settings)? Wired interfaces can be with or without 802.1X so here situation potentially can be no different. 2. Is it possible to let NM take over management of virtual wireless interface (here wlp6s0.1) once it is created? Now when the interfece is defined as NM-managed, "hotplug" to "yes" and "type" is set to "wifi", network manager does not react to its creation by hostapd and whet I try to bring the connection manually, NM complains it canot find a device to manage. Should it be possible I could get rid of br1. - -- Mith Elen sila lumenn omentielvo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQGcBAEBAgAGBQJcZa4eAAoJEHsdvut2jC9BX80L/03+JsFCdtk3VCDABFOrsZiy IJRzwYx7bAHoabXYWQSCBjq6f2VFIyj9aXg+IJ10Oo+db4DUX+qV5HbHK8uAmT1c ZzA9hQgh75blrD1rFnsnHwlklCnNPJ8fWphVHEoJuCW9fO+WPyMVngmbBSG7cFHO OcxsmdUnojB+wHbZ4i4pFB70uTejqoXx/DlopV7cWfO8WI/H98tWJqamhyuWZi3g N7NgooNYcHXeSP1q/39o6HVYI3UFUcgHNUw6AFUdNXYzXmbdZz/FM5GZAbWmpDZj KFz8GlUArvKLBpdOcvFdnepzYDN4qQ2QGyCkKnhNQPp5CvFDxbQO6kpdDc+Xq+NH wYj6hVSwG5gafKn0HD8pDtUpyCEeCT16FU3P8BJ/e3nT1498bkoikFUspXdln+OG n8NcUVCKOHFGkNHF1uejPXQCFUd+xgY4xjF9meWKgQUrhvkQVQM/lhVdVu4bskn9 TfiIGqofPqCt1rTngx51N9DS8aJRYFwOmuTaYXnywg== =k5Dc -END PGP SIGNATURE- ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: automatic APN selection
>> Also, I'd like to emphasize that IMHO this should not be the default in NM. >> Automatically selecting what APN to use should be explicitly enabled by the >> user somehow. Companies doing custom setups with MM+NM can enable this >> feature, even providing a "controlled" subset of the >> mobile-broadband-providers-info database, and that specific use case makes >> total sense. > > Why so? I’d see such a thing as a lovely features, and you pretty much loose > the benefit of it being default if you have to find out you need to activate. > On the other hand it would be so neat to put a sim card in a computer that > happens to have a free-software supported wwan card and get stuff just > working! > > I mean, it’s what most mobile phones do, right? > I believe there's always the fear of wrongly using the APN you're not supposed to use and getting automatically charged money for that. I'm not sure if this fear is based on known real usecases or it should really be obsoleted by now, though, especially since all LTE devices have "some sort of active connection" as soon as they're registered to the network. Otherwise, the worst thing that could happen if using a wrong APN is that the modem doesn't connect with the automatic settings, which, well, that shouldn't be a big issue. Users that require special APN settings will anyway need to insert them manually. I really have mixed feelings, so I've always suggested that automagic APN setup to be optional. But hey, I may be totally wrong, this is just my opinion :) -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 15:16 +0100, Thomas Haller via networkmanager- list wrote: > > Hi, Hi. > From the logs it looks like to me the IPv6 address of the sender is > indeed the instance managed by NetworkManager. Oh yes, I am sure it's the NM machine that is sending the RSes. > Is the issue hard to reproduce? Not hard to reproduce but I don't have a "lab" to reproduce it in and so have to do it on my production network and doing so brings the router/switch that everything is connected to to it's knees so it's pretty catastrophic to reproduce. I'm also concerned with the disk load that disabling the rate limiting of journald is going to cause on the NM machine given that it's suppressing thousands of messages at a time. But I will give it another go. Just so that I only have to do this once and as briefly as possible, what level of debugging do I need to set to get the messages logged by: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n711 > Your efforts are appreciated!! :) Happy to help as much as I can. :-) Cheers, b. signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 08:25 -0500, Brian J. Murrell wrote: > On Thu, 2019-02-14 at 13:46 +0100, Thomas Haller wrote: > > Hi, > > Hi, > > > In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager > > should either log > > > > "router solicitation sent" > > > > or > > > > "failure sending router solicitation: ... > > > > for every RS that gets send. > > > > > > Possibly the logging message was suppressed by journald's > > ratelimiting > > Most likely. > > > (as the journal would tell you, if that's the case). Make sure to > > disable rate-limiting, see [1]. > > > > > > [1] > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 > > Is it really necessary to actually see the messages in the journal at > this point? Doesn't the packet trace and CPU load of NM from my > previous message sufficiently prove that NM is storming RSes? > Hi, well, NetworkManager uses libndp for IPv6 neighbor discovery. From the logs it looks like to me the IPv6 address of the sender is indeed the instance managed by NetworkManager. However, 1) libndp never sends RS without being told to do so (I think). 2) NetworkManager sends RS (via libndp) only at one place. It's not clear to me how that code could be wrong so that it might result in a flood of RS. The logfile should show whether this code is culprit or not. Is the issue hard to reproduce? Your efforts are appreciated!! :) best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 13:46 +0100, Thomas Haller wrote: > Hi, Hi, > In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager > should either log > > "router solicitation sent" > > or > > "failure sending router solicitation: ... > > for every RS that gets send. > > > Possibly the logging message was suppressed by journald's > ratelimiting Most likely. > (as the journal would tell you, if that's the case). Make sure to > disable rate-limiting, see [1]. > > > [1] > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 Is it really necessary to actually see the messages in the journal at this point? Doesn't the packet trace and CPU load of NM from my previous message sufficiently prove that NM is storming RSes? Cheers, b. signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
Hi, On Thu, 2019-02-14 at 07:01 -0500, Brian J. Murrell wrote: > On Thu, 2019-02-14 at 07:49 +0100, Thomas Haller via networkmanager- > > > It's not clear to me what you mean. > > > > Do you mean, that the many RA received at NetworkManager cause > > NetworkManager to send too frequent RS (in turn, repeating a > > vicious > > cycle)? > > That's exactly how I understand the description from the author of > the > software on the router that is sending the RAs, yes: > > https://github.com/openwrt/odhcpd/issues/122#issuecomment-459263681 OK, makes sense. > > Also, NM only sends RS based on timeouts, not based on RAs that it > > receives [1]. > > Assuming no bugs, of course. Such as could the receiving of the > multiple RAs perhaps be causing the timeout to get reset, etc.? > > How/when does the logging in send_rs_timeout: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n711 > > supposed to get logged? In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager should either log "router solicitation sent" or "failure sending router solicitation: ... for every RS that gets send. Possibly the logging message was suppressed by journald's ratelimiting (as the journal would tell you, if that's the case). Make sure to disable rate-limiting, see [1]. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 07:49 +0100, Thomas Haller via networkmanager- list wrote: > > Hi Brian, Hi Thomas, > It's not clear to me what you mean. > > Do you mean, that the many RA received at NetworkManager cause > NetworkManager to send too frequent RS (in turn, repeating a vicious > cycle)? That's exactly how I understand the description from the author of the software on the router that is sending the RAs, yes: https://github.com/openwrt/odhcpd/issues/122#issuecomment-459263681 > Also, NM only sends RS based on timeouts, not based on RAs that it > receives [1]. Assuming no bugs, of course. Such as could the receiving of the multiple RAs perhaps be causing the timeout to get reset, etc.? How/when does the logging in send_rs_timeout: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n711 supposed to get logged? > can you clarify what you think is the harmful behavior? It causes an RA/RS storm on the network segment which drives the load up on the router as it tries to process all of the RSes. I also see other devices in my network go flakey when the storm starts. > Also, does > tcpdump/wireshark show that NM sends too many RS? Well, the log from the router: https://github.com/openwrt/odhcpd/files/2802914/logread.txt shows it according to the author of that software, but I can grab a packet trace if you like: 2266 8.103505030 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2267 8.110988364 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2268 8.111476269 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2269 8.116601719 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2270 8.116998692 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2271 8.122950355 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2272 8.125336593 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2273 8.133207122 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2274 8.133783515 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2275 8.141006274 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2276 8.144105304 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2277 8.148667072 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2278 8.154763444 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2279 8.154935042 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2280 8.157726075 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2281 8.160963459 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2282 8.163637161 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2283 8.183327416 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2284 8.183769855 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2285 8.189963026 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2286 8.190426487 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2287 8.195982154 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2288 8.196411883 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2289 8.201634132 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2290 8.202029638 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2291 8.207328153 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2292 8.207783792 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2293 8.213471947 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b0:ce:f5:1e:4a 2294 8.213864031 fe80::21f:c6ff:fec4:926a -> ff02::2 ICMPv6 70 Router Solicitation from 00:1f:c6:c4:92:6a 2295 8.219000726 fe80::6eb0:ceff:fef5:1e4a -> fe80::21f:c6ff:fec4:926a ICMPv6 174 Router Advertisement from 6c:b
