After the update to 187, the wifi I had on the Blue Zone (basic router connected to the Ethernet on the server) stopped working. I didn’t change anything in the set-up and am not sure why it stopped. I have not seen anyone on here with similar issues. The update to the latest 188 has not changed anything. The mobile phone is getting the right IP from the Blue DHCP server, but adding this to the Blue allowed list, which previously would allow internet access, does nothing. No blue lines in the Connections section either.
If you already got to this stage, the MAC address filter should be out of the way - otherwise, obtaining a DHCP lease would not have been possible in the first place.
Is there anything in the firewall logs for the WiFi client in question?
Actually, the phones appear to be getting the wrong IP. In the firewall logs, for the Blue zone, there are lots of dropped blue packages and it has the IP, I think, of 0.0.0.0 and subnet 240.0.0.0 or something like that. I am not at work now and can only access it from work. I have 2 systems (basically 2 teaching rooms) that are more or less identical and both have gone the same way. They have been working flawlessly for months, but after 187, they are both gone, well, the blue zone. I have not changed anything at all. On Monday I will take a closer look.
All other services are fine and the wifi is not critical, but I would like to fix it if I can. I am trying to teach myself this stuff in the few pockets I have spare between a full teaching load, so apologies in advance for vagueness and slow responses.
The basic set-up I have is:
Red ethernet to ISP - dhcp
Green to LAN - 192.168.1.x
Blue attached to commercial home router - 172.16.4.x
Orange DMZ - 10.x.x.x
I never really noticed until recently, but the blue zone just stopped after 187.
looking at the Git commit history of Core Update 187, the update of iw is the only one that immediately sticks out to me as being potentially related to WiFi hiccups. However, I am currently not aware of that one causing any major issues.
That sounds like DHCP discovery traffic, which obviously should not have been dropped in the first place. Would you mind providing exact logs of these dropped packets, so we can investigate which firewall component is involved?
Noted, though could you please make sure the firewall rules and firewall options do not interfere with the traffic on BLUE, and are configured as you expect them to be?
Don’t worry. Everyone starts at some point…
What does that mean exactly? Does IPFire provide the WiFi network directly, or does the “commercial home router” do that?
Which logs would you like to see? Can you let me know specifically and I can grab them.
I haven’t changed any of the firewall settings, other than updating to the latest update code.
The red zone ethernet connects directly to a fibre box. The blue zone ethernet connects to a lan port on a TP-Link router. The way it was working was that my students and guests could find this on their phones and I could then add them to the Blue access list so they could use the internet. I didn’t really configure the router, it just worked that way. I have 2 identical setups in 2 buildings and both have stopped.
Prior to the 187 update, the DHCP logs were full of Blue traffic. Since the update, mobile phones were connecting with the green IP range and getting no further. I have them connecting again to the Blue IP, but no traffic at all.
There are no references at all to the Blue zone in the DHCP server logs now, unlike above…
I don’t remember, or certainly have no notes, of doing anything with the wifi router other than plugging it in to the Blue zone and it working. As a test, I have hooked it up to a spare PC and configured it with the same IP range as the Blue zone NIC, but no activity as such, other than getting an address.
Updated to 189, but still no change. The firewall log just shows Blue as being dropped and no IP being assigned. IT is showing on the logs and the phone is showing the right IP, but no pass-through. I might roll back to 185 when it was working fine.
I am no expert in this stuff so some of that I could possibly do. As I said at the outset to this post. I set it up with 185 and it all worked. I have not changed anything, but since 187, the wireless no longer works. The rest works fine so it is not critical, it is just would be nice to get back to where I was.
This sounds wrong.
I do not know your setup.
Ipfire 3 nic’s red blue green?
2 nic’s red green blue vlan on green?
Wifi is by a TP-link router used as AP?
Does it have AP mode or.
Did you configure it with no DHCP etc.
Some times thing don’t update correctly.
Try new install from ISO.
I have 2 identical systems, and both went the same way with updates. I think I will start again over half term as you suggested. I have red going to a fibre connection, green is just though to a switch (no vlan, or maybe the default vlan for the switch (old Netgear), orange DMZ to web server and the blue just went to a standard home router which provided wifi. Both were working, but stopped after 185. I don’t have a great deal of time to trouble-shoot as I have a full TT of lessons.
I had a similar experience. At first I didn’t even notice because I only had current measuring sockets connected to it, but then I saw that I had strange entries in the DHCP log.
I looked at the options for the wireless access point configuration and saw that the SSID was off. At the end I changed all settings to try out all :D.
After I activated it, the hostapd service kept stopping. After a bit of starting and stopping, I tried the strategy of starting hostapd in the service menu, going to WLAN Access Point Configuration, selecting the important channel 6 for me, starting the module there, then going to the DHCP server and saving the old configuration again (never changed it)
And lo and behold, hostapd is running stably and all my current measuring sockets have internet again.
now only the DHCP log now looks a bit different for blue:
08:27:19 dhcpd: DHCPACK on 172.16.1.18 to XX:XX:XX:XX:XX via blue0
08:27:19 dhcpd: DHCPACK on 172.16.1.18 to XX:XX:XX:XX:XX from XX:XX:XX:XX:XX via blue0
08:27:19 dhcpd: execute_statement argv[3] = NAME=
08:27:19 dhcpd: execute_statement argv[2] = ADDRESS=172.16.1.18
08:27:19 dhcpd: execute_statement argv[1] = commit
08:27:19 dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
Well, I tried lots of things, but nothing worked, so I reinstalled 185 and it all works fine again. I shall install that on the other system as well for now. I know there are improvements and security issues addressed with later versions, but 185 seems to like my setup.
Thanks. Yes, it is odd, but I have 2 identical systems and it is the same on both. At the next college holiday I might try and upgrade one and look more closely at the logs to see if there are any obvious issues.
Just for an update. I had rolled the software back to 185 as the wifi worked on that version. I updated it to 190 and it continued to work on one device, but not on another. I am still trying to figure out why as they are identical set-ups in different buildings.
