News items for tag wifi - Koos van den Hout

I recently bought new wifi access points to upgrade the wifi at home. The main reason was the fact that the TP-Link TL-WDR4300 bought 9 years ago was sometimes 'hanging' which was solved by rebooting it. This was starting to get annoying, and the family wants stable wifi which doesn't need instructions which button to press for reboot.

The upgrade path was going somewhat 'prosumer': support for multiple wireless SSIDs with a main and a guest network, and I wanted an extra access point in the shed for working in the back garden, as tested in april Using the network switch in the shed as remote powerswitch.

The choice was to go with the Mikrotik access points. For the shed and garden I bought the wAP.ac and for the main access point in the house the hAP.ax3. The latter has support for the latest and greatest wifi standards, including wifi 6 and WPA3.

It took me a while to configure them, the Mikrotik routerOS userinterface exposes all the options networking in Linux has, but it takes knowledge of bridging, routing and firewalling to get it all correct and doing what I want.

One of the wishes we have for the home network is good wifi coverage in the back garden so we can sit outside on nice days to work without running UTP cables. The access-point in the central place in the house doesn't cover the back garden. Ideally I would also like a separate 'guest' wireless network at home.

These wishes was taken into consideration when upgrading the fiber to the shed network with a Netgear GS310TP switch. This switch has Power over Ethernet (PoE) support so it can power an acccess-point. The next step was to find an access-point supporting VLANs and multiple SSIDs.

Recently I borrowed a Mikrotik Wap.AC to test the options. It took me a bit to get used to the RouterOS userinterface but I managed to get it all working in an ideal configuration: Management via one VLAN, a 2.4 GHz wireless network bridged to the trusted wireless network, a 2.4 GHz wireless network bridged to the guest wireless, a 5 GHz wireless network bridged to the trusted wireless network and a 5 GHz wireless network bridged to the guest wireless.

The final test was with the Mikrotik Wap.AC in the shed with power over the network cable. This worked!

Ideally the wireless network in the backyard is 'on demand' because we only use it when working from home or sitting in the backyard and we can save the power at other times. So the idea of a button 'wifi in backyard' and an automatic shutdown in the evening is nice. I searched and it is indeed possible to control the Power over Ethernet in the Netgear GS310TP switch with snmp. Based on GS110TP deactivate PoE over SNMP for specific Ports I soon had working snmpset commands to disable/enable power to a specific port, and the Mikrotik followed nicely. Value '1' is PoE on and value '2' is PoE off:

$ # switch PoE on for port 8
$ snmpset -v2c -c ******** ******* 1.3.6.1.2.1.105.1.1.1.3.1.8 integer 1
iso.3.6.1.2.1.105.1.1.1.3.1.8 = INTEGER: 1

$ # switch PoE off for port 8
$ snmpset -v2c -c ******** ******* 1.3.6.1.2.1.105.1.1.1.3.1.8 integer 2
iso.3.6.1.2.1.105.1.1.1.3.1.8 = INTEGER: 2

Ideally there would be a button (zigbee?) near the backdoor to request "On" and a scheduled task every day to switch it off in the evening.

I was doing some testing with freeradius and suddenly nothing worked with the following error in debug mode:

(7) eap_peap: ERROR: TLS Alert read:fatal:certificate expired
(7) eap_peap: TLS_accept: Need to read more data: error
(7) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired

I checked the certificate and renewed it. The normal autorenewal processes had not run since the previous tests with radius and 802.1x authentication on wifi so that wasn't unexpected but this still didn't solve it: I kept getting the error message.

After some deep searching why it worked before I saw I had requested that certificate in a different way where I had the chain with only ISRG Root X1 because sendmail gave me SSL verification failures after the DST Root CA expired. So I did the same as I did before: I configured dehydrated (my preferred ACME client) on the radius testmachine to use the LetsEncrypt issuer chain without the DST Root CA cross signature, with the following in /etc/dehydrated/config :

# Preferred issuer chain (default: <unset> -> uses default chain)
PREFERRED_CHAIN="ISRG Root X1"

After digging into setting up radius and WPA Enterprise with an Asus WL300g accesspoint the next step was to peek into the traffic on a client.

For that part I used a linux machine with a wired and wireless interface and used tcpdump to try to capture the wireless authentication packets. I configured /etc/network/interfaces for wpa enterprise, based on the eduroam examples.

And this worked, starting the capture:

root@ritchie:~# ifconfig wlan0 up
root@ritchie:~# tcpdump -ni wlan0 -w wlanstart.pcap -s 0 -u -v

And I typed in another window 'ifup wlan0'. This resulted in a capture with the right Extensible Authentication Protocol (EAP) packets included:

root@ritchie:~# tcpdump -nr wlanstart.pcap -v
reading from file wlanstart.pcap, link-type EN10MB (Ethernet)
16:47:39.658963 EAP packet (0) v2, len 5, Request (1), id 0, len 5
                 Type Identity (1)
16:47:39.660863 EAP packet (0) v1, len 25, Response (2), id 0, len 25
                 Type Identity (1), Identity: anonymous@idefix.net
16:47:39.662840 IP6 (hlim 1, next-header Options (0) payload length: 56) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr ff02::1:ff23:123 to_in, 0 source(s)] [gaddr ff02::1:ff84:afe0 to_ex, 0 source(s)]
16:47:39.668736 EAP packet (0) v2, len 6, Request (1), id 1, len 6
                 Type TTLS (21) TTLSv0 flags [Start bit] 0x20,
16:47:39.670420 EAP packet (0) v1, len 6, Response (2), id 1, len 6
                 Type Nak (3) unknown (25),
16:47:39.682125 EAP packet (0) v2, len 6, Request (1), id 2, len 6
                 Type unknown (25)
16:47:39.741150 EAP packet (0) v1, len 203, Response (2), id 2, len 203
                 Type unknown (25)
16:47:39.756343 EAP packet (0) v2, len 1004, Request (1), id 3, len 1004
                 Type unknown (25)
16:47:39.756598 EAP packet (0) v1, len 6, Response (2), id 3, len 6
                 Type unknown (25)
16:47:39.834920 EAP packet (0) v2, len 1000, Request (1), id 4, len 1000
                 Type unknown (25)
16:47:39.835159 EAP packet (0) v1, len 6, Response (2), id 4, len 6
                 Type unknown (25)
16:47:39.842070 EAP packet (0) v2, len 1000, Request (1), id 5, len 1000
                 Type unknown (25)
16:47:39.842318 EAP packet (0) v1, len 6, Response (2), id 5, len 6
                 Type unknown (25)
16:47:39.866174 EAP packet (0) v2, len 79, Request (1), id 6, len 79
                 Type unknown (25)
16:47:40.006260 EAP packet (0) v1, len 144, Response (2), id 6, len 144
                 Type unknown (25)
16:47:40.014338 EAP packet (0) v2, len 65, Request (1), id 7, len 65
                 Type unknown (25)
16:47:40.016467 EAP packet (0) v1, len 6, Response (2), id 7, len 6
                 Type unknown (25)
16:47:40.028765 EAP packet (0) v2, len 43, Request (1), id 8, len 43
                 Type unknown (25)
16:47:40.029290 EAP packet (0) v1, len 96, Response (2), id 8, len 96
                 Type unknown (25)
16:47:40.036381 EAP packet (0) v2, len 75, Request (1), id 9, len 75
                 Type unknown (25)
16:47:40.043383 EAP packet (0) v1, len 144, Response (2), id 9, len 144
                 Type unknown (25)
16:47:40.057720 EAP packet (0) v2, len 91, Request (1), id 10, len 91
                 Type unknown (25)
16:47:40.058739 EAP packet (0) v1, len 80, Response (2), id 10, len 80
                 Type unknown (25)
16:47:40.071176 EAP packet (0) v2, len 43, Request (1), id 11, len 43
                 Type unknown (25)
16:47:40.072087 EAP packet (0) v1, len 80, Response (2), id 11, len 80
                 Type unknown (25)
16:47:40.082689 EAP packet (0) v2, len 4, Success (3), id 11, len 4
16:47:40.082865 EAPOL key (3) v2, len 117
16:47:40.091607 EAPOL key (3) v1, len 117
16:47:40.107041 EAPOL key (3) v2, len 175
16:47:40.107839 EAPOL key (3) v1, len 95

At the same time I captured the radius traffic. Now time to correlate those two traffic streams in wireshark.

For work I am looking into how Wi-Fi Protected Access (WPA) actually works down to the byte level, to be able to explain what actually happens and where the security strenghts and weaknesses are.

To set this up I need a separation between the access-point and the authentication server. I dug up an old Asus WL300g access-point and looked at FreeRADIUS as authentication, authorization and auditing (AAA) server. I followed the A very basic (but functional) eduroam configuration - FreeRADIUS wiki guide to get to a working setup, but with different passwords.

Getting the access-point to talk to a radius server took a bit of searching and trying: I assumed that "802.1x" which is extended to "Radius with 802.1x" was the right mode to use a radius server in the background, but it turned out this didn't do what I want. I saw no communication with the radius server and I didn't see the SSID advertised.

The right mode is "WPA" and things started to work that way. It still needs a few settings to talk to the radius server: IP address, port and shared secret.

I chose to go the 'eduroam' way because that is what I am used to from work. This does mean I had to set a home domain idefix.net for authentication. With eduroam I also get Extensible Authentication Protol (EAP) extensions to handle with the real user data. The result is an outer authentication layer visible to the first radius server in the path and an inner authentication layer only visible to the final radius server in the path. Although both the outer and the inner authentication servers run on the same freeradius server they are separate configurations with a trust relation between them.

The traffic to the inner authentication server is wrapped in TLS and needs a certificate. I used LetsEncrypt to generate a trusted certificate. I noticed I am at a point where generating a valid LetsEncrypt certificate was easier for me than fiddling with self-signed certificates. So I could set up my phone to require a valid certificate for radius.idefix.net.

All of this worked and I had a WPA Enterprise connection with the access-point and a lot of debug logging in freeradius.

My next plan is to find some computer with a network card where I can run wpa_supplicant while at the same time grabbing all the raw 802.11 frames and analyzing/understanding the traffic. I will also look at the radius traffic between access-point and outer radius server, and the radius traffic between outer and inner radius server.

I used the raspberry pi in the shed to do a wifi scan, to get an idea of the usage of the 2.4 GHz wifi band as seen in the shed.

This finds 18 to 22 networks, with our own network not as the strongest network. As you can imagine most channels have multiple networks on them. And the overlap in wifi channels makes this worse: the networks on channel 2 see interference from those on channel 1.

From the list of networks, with names and address information removed, just leaving signal strength and channel / frequency:

-93 dBm, ch   1, 2412 MHz
-91 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-72 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-88 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-91 dBm, ch   2, 2417 MHz
-80 dBm, ch   2, 2417 MHz
-90 dBm, ch   3, 2422 MHz
-94 dBm, ch   4, 2427 MHz
-93 dBm, ch   5, 2432 MHz
-94 dBm, ch   5, 2432 MHz
-80 dBm, ch   6, 2437 MHz
-94 dBm, ch   8, 2447 MHz
-95 dBm, ch   8, 2447 MHz
-94 dBm, ch   9, 2452 MHz
-95 dBm, ch   9, 2452 MHz
-77 dBm, ch  10, 2457 MHz
-84 dBm, ch  11, 2462 MHz
-93 dBm, ch  11, 2462 MHz

This is a right mess. If I ever want reliable wifi in the back garden/shed I will have to have an extra access-point there. This option of having wireless vlan(s) available in the shed has influenced the choice in switch for the shed.

In the project to upgrade the connectivity to our shed I ordered a switch with sfp slots: a netgear GS310TP. The choice is to have the same brand as in other places in the network so I can select compatible SFP modules easily. With this switch I also have vlan support so I can have a wifi access point in the shed if I want.

The current fiber to the shed network is working fine but only gives the Raspberry Pi based NTP server network at a speed of 100 mbit.

The link is working fine but the next device with network problems due to unreliable wifi is showing up: the solarpanel inverter in the shed is sometimes unreachable for my solar inverter monitoring using modbus/tcp and that means I 'miss' measurements. The propetairy monitoring that solaredge does can deal with interruptions in reachability and upload older data, but the modbus/tcp monitoring I use can only access real-time data.

My first plan was to look at industrial switches because of the extended temperature and humidity ranges in the shed. But having both 'industrial' and 'sfp slot' costs a lot of money.

My next thought is to put all the possibly sensitive electronics in one case and hope the temperature and humidity inside that case stay within a reasonable range. This thought is based on the fact that the Raspberry Pi based NTP server functions fine in a not very closed wooden box without being affected by temperature or humidity.

And yet another Raspberry Pi is showing up for my home network. This will become the GPS-based timeserver. I may add it to the NTP Pool when I'm satisfied enough with it.

It will probably also replace the 'shed' weather station computer in the long run, to save on power use.

I added an extra USB-based wifi adapter to the Pi. The shed has no wired network and my experience with the other computer there is that dual-band (2.4 GHz and 5 GHz) wifi support is the best way to have a chance to get working network.

I also ordered the Raspberry Pi GPS/RTC Expansion Board directly from uputronics.

Recently the wireless access-point decided that I should not have access to the management interface. I even tried both the IPv4 address I assigned and the default IPv4 address it gets. And the last days I noticed strange delays, which may have been caused by channel overlaps. So I wanted access to the management interface to check the channel settings. I noticed the management interface decided to respond again on the IPv4 address I assigned, and I saw new firmware available which should also help with some stability issues.

Firmware upgraded, and after the upgrade and automatic reboot my access was gone again. Time for the suggested factory reset to get everything back to normal. Done, and I was able to set it up again from scratch with the right configuration.

Maybe I should start running some kind of wiki or something to keep internal documentation of my home network. I had a hard time remembering several details of my own setup recently.