I file this as a pretty long standing bug. I already did in the forum (https://forum.ipfire.org/viewtopic.php?f=22&t=20609) My system consists of a physical green NIC (192.168.2.1) and a blue interface (10.0.0.1) using VLAN 10. The WLAN-AP is connected to green and has a VLAN 10 tagged WLAN. Problem: In the current DHCP leases are always WLAN devices with IPs of the green DHCP pool. See this log: Apr 12 10:55:23 ipfire dhcpd: DHCPDISCOVER from cc:fd:17:f2:24:43 via blue0 Apr 12 10:55:23 ipfire dhcpd: DHCPDISCOVER from cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via green0 Apr 12 10:55:24 ipfire dhcpd: DHCPOFFER on 10.0.0.100 to cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via blue0 Apr 12 10:55:24 ipfire dhcpd: DHCPOFFER on 192.168.2.10 to cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via green0 Apr 12 10:55:28 ipfire dhcpd: DHCPDISCOVER from cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via blue0 Apr 12 10:55:28 ipfire dhcpd: DHCPOFFER on 10.0.0.100 to cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via blue0 Apr 12 10:55:28 ipfire dhcpd: DHCPDISCOVER from cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via green0 Apr 12 10:55:28 ipfire dhcpd: DHCPOFFER on 192.168.2.10 to cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via green0 Apr 12 10:55:28 ipfire dhcpd: DHCPREQUEST for 10.0.0.100 (10.0.0.1) from cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via blue0 Apr 12 10:55:28 ipfire dhcpd: DHCPACK on 10.0.0.100 to cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via blue0 Apr 12 10:55:28 ipfire dhcpd: DHCPREQUEST for 10.0.0.100 (10.0.0.1) from cc:fd:17:f2:24:43 (android-6eabf82f99d55700) via green0: wrong network. Apr 12 10:55:28 ipfire dhcpd: DHCPNAK on 10.0.0.100 to cc:fd:17:f2:24:43 via green0 IP 192.168.2.10 is shown in the "Current dynamic leases" as lease for the "android-6eabf82f99d55700" device. That's wrong. IP 10.0.0.100 is shown as well. That's okay. I haven't traced this by Wireshark if an according WLAN device gets the offer (192.168.2.x) but normally, it should not. Anyway, just the existing DHCPOFFER above triggers an entry in /var/state/dhcp/dhcp.leases - which is IMHO a bug. Question is also, why a blue WLAN device causes a DHCPDISCOVER via green0 (line 2)...
This is a problem in the ISC dhcpd. It tries to capture the packets in a funny way so that it will read the packets that belong to a VLAN on the untagged (in this case green) device as well. So far I have always considered it that the DHCPOFFER packet does not make it to the client since it is being sent back into the wrong (in this case green) network and the client should not receive it from there. That suggests that you have a problem in your VLAN wiring. Ubuntu's bug tracker says this should have been fixed in 4.3.2 (https://bugs.lau nchpad.net/ubuntu/+source/isc-dhcp/+bug/1167614). We are on 4.3.1. @Matthias: Since you have been submitting the last update, would you update DHCP again?
Michael, thanx for your feedback. Yes, 4.3.1 seems to be a little old and it looks like it's fixed in 4.3.2. I update the ics-dhcp on a test system and report the result here.
Hi, Ok, I'm second. ;-) I jsut have a few questions: 1. Current version is 4.4.1 - should I try to upgrade to this version while Marco tries 4.3.2? 2. 4.3.1 contains a lot of patches, I doubt they apply to 4.4.1. I would try to build 4.4.1 without them and see how far I can get. Would this be ok? Best, Matthias
There is no reason to not go directly to the latest version.
As the 4.3.x line is EOL in July '18 I would/wanted to go with the latest version 4.4.1 as well. Like Michael, I don't see a reason against it.
Hi! Latest news on this: Prior to pushing the new version I'll will do a few tests - as far as I can with my environment. First I made a clean build under Core 119. At the moment, 4.4.1 is up and running on my production machine. Right now I'm building with 'next' - just to be sure. Changes so far: - None of the old '4.3.x'-patches applied - I had to remove them all. If someone knows better, please let me now. For me it looks as if they are not needed anymore. - I had to add '--with-srv-conf-file=/etc/dhcp/dhcpd.conf' to 'configure'-options, otherwise 'dhcp' couldn't find it (it always searched in '/etc'). - Had to remove '$(MAKETUNING)' (LFS: "This package does not support parallel build."). Made me some headaches... ;-) - Some minor changes to 'dhcp'-rootfile. Best, Matthias
Hi Matthias, thanks for sharing your status so far. Last week I struggled exactly at the same things like you: - Had to remove '$(MAKETUNING)' (LFS: "This package does not support parallel build."). Made me some headaches... ;-) Right, I found out as well and removed it, too. I haven't investigated the cause any further. - I had to add '--with-srv-conf-file=/etc/dhcp/dhcpd.conf' to 'configure'-options, otherwise 'dhcp' couldn't find it (it always searched in '/etc'). Right, first I used a symlink as quickfix but later recompiled it with that option which fixed it. Perhaps the default /etc/dhcpd.conf might be a better config place in the future anyway... I haven't applied ANY of the old patches as well. After a short look in the patches I think they are deprecated with 4.4.1 RESULT and TEST: The new dhcp server (4.4.1) is running very stable on my production system (Core 119) for 4 days now. I can CONFIRM, that the original problem (blue devices getting green IPs) is FIXED. No more wrong IPs of the green DHCP pool. The dhcpd logs are very clean now and DHCP is running exactly as it should. So, this update should be part of the next core update.
Hi, => https://patchwork.ipfire.org/patch/1736/ => https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=af82bfde5c844927f20b068479e61bab12bd7eb5 Best, Matthias
Just to give some feedback: I've tested 4.4.1 "vanilla" for one month now on 3 prod machines, there are no problems, blue VLAN IPs and green IPs are handled fine. I don't see any impact due to dropping all the patches, as long as they doesn't enhance security. I haven't checked further, if theses patches are included in the latest version already, but the changelog is rather long.
Thanks for testing. @Matthias: Would you prepare this patch then for being submitted to the list?
Hi, Done. Sent in as: https://patchwork.ipfire.org/patch/1790/ And: https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=8441d469b0067e5fd126ceb4833bd3158537716d Best, Matthias
As this is in the latest version (Core122) and working fine, this issue is fixed and closed.