WAN dhclient (DHCP) issues - bug in time intervals?
-
@stephenw10 2023/5/16 at 16:37 local time (14:37 UTC)
-
What does it log as the renewal time in the dhcp log when it first pulls the lease?
-
@stephenw10 The same 92354 seconds as written i the lease file.
-
@stephenw10 About the double DHCP request at startup once there is two leases in the lease file:
At startup it logs this rather long error message - perhaps that is related to trying two times?:
/status_interfaces.php: The command '/usr/local/sbin/dhclient {$ipv} -d -r -lf '/var/db/dhclient.leases.mvneta0.832' -cf '/var/etc/dhclient_wan.conf' -sf '/usr/local/sbin/pfSense-dhclient-script'' returned exit code '1', the output was 'Internet Systems Consortium DHCP Client 4.4.3-P1 Copyright 2004-2022 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /var/etc/dhclient_wan.conf line 7: no option named dhcp-class-identifier in space dhcp \x09send dhcp-class-identifier "sagem" ^ /var/etc/dhclient_wan.conf line 8: semicolon expected. \x09send ^ /var/etc/dhclient_wan.conf line 10: no option named option-90 in space dhcp \x09send option-90 00: ^ /var/etc/dhclient_wan.conf line 11: semicolon expected. \x09request ^ /var/etc/dhclient_wan.conf line 12: semicolon expected. \x09vlan-pcp 6; ^ /var/etc/dhclient_wan.conf line 14: semicolon expected. \x09script ^ /var/db/dhclient.leases.mvneta0.832 line 22: expecting lease declaration. next-server ^ /var/db/dhclient.leases.mvneta0.832 line 23: expecting semicolon. option ^ /var/db/dhclient.leases.mvneta0.832 line 34: no option named option-90 in space dhcp option option-90 0: ^ /var/db/dhclient.leases.mvneta0.832 line 36: no option named option-125 in space dhcp option option-125 0: ^ Listening on BPF/mvneta0.832/48:29:52:25:2c:50 Sending on BPF/mvneta0.832/48:29:52:25:2c:50 Can't attach interface {} to bpf device /dev/bpf0: Device not configured If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting.'
-
@stephenw10 Perhaps my DHCP WAN settings are relevant as well:
The full text in Send Options:
dhcp-class-identifier "sagem",dhcp-client-identifier 01:48:29:52:xx:xx:xx,user-class "+FSVDSL_livebox.Internet.softathome.Livebox4",option-90 xxxxxxxxxxx:72:77:67:66:xxxxxxxxxxxxxxxx
The full text in Request Options:
subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search,routers,domain-name-servers,option-90,option-125
Some edits have been made to obscure identities (xxxx’s)
-
Hmm. So if the client doesn't send those request options it never gets a lease?
-
@stephenw10 No, they require all the options, and they require the client to respect the RFCs around them (even though their own server does not respect the RFC).
Obviously all a play to make it increasingly harder to use any equipment but their own livebox equipment (which they do not allow to be placed in bridgemode). So no public IP on your own equipment unless you go through all these hoops to get your own box to behave like theirs.
-
So what happens if you don't send all the request option?
What happens if you request a shorter lease?
-
@nollipfsense said in WAN dhclient (DHCP) issues - bug in time intervals?:
It would help a great deal to disclose the ....
ISP ? Orange ?
Fibre ? ADSL ? Box used ?Never mind : it's encoded : "Livebox4" so Orange and probably ADSL.
Fiber needs a version 5 box. Or the "6", I've one. ( but I'm not planning to remove ISP Orange Livebox, imo to much of a hassle )For more support, I would advice you to dig into https://lafibre.info/
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm. So if the client doesn't send those request options it never gets a lease?
Yep. DHCP is used to get the IPv4, DHCPv6 is used to get all the IPv6 info, and options are used to identify the 'box', and send authentication/identification.
Par example : https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/ to mention just one.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan Hi @Gertjan
Thanks for chiming in. Yes, the ISP is Orange and yes, I have read a million posts on lafibre.info (though that’s tough when google translate is your only option)
I have had it running for about a year and a half without issues, but this winter Orange started tightening up the DHCP RFC requirements on the DHCP exchange, and I stopped being able to renew my IP.
I’m on fibre, and I replaced a Livebox5 with my SG-2100 (and a 4100 for a while). I have a fs.com ONT SFP module inserted, and it works flawlessly (https://www.fs.com/de-en/products/133619.html)Love the no fuss of using the official appliances :-)
-
@gertjan Maybe I should mention I never had IPv6 working because the DHCPv6 client in pfSense does not support dhcp RAW options - at least in 22.05.
But I only need IPv4 at this stage as the site is tied into a v4 IPsec infrastructure in a country that has very limited/no v6 support/availability. -
@stephenw10 It takes a while to do fault finding because I have to wait about 24 hours for the problem to occur. Also I’m only first now on-site to do proper diagnosing.
Later today when it fails again I will have a packet capture of DHCP exchanges when the issue occurs.
From then on I can start testing workarounds and fixes. But mainly I’m interested in keeping as many of the settings they use in their own livebox as possible. I find it likely they will continue tightning the DHCP exchange to make it more and more difficult to use equipment other than the supplied but crappy livebox.
For now it’s a major advantage for me if I can have the IPv4 public IP on my pfSense WAN instead of doing double NAT and miss the ability to remotely contact the box directly (IPsec/management) -
@gertjan About lafibe.info:
Seems there is a huge userbase in France that uses Mikrotik equipment for replacing the Livebox.
There used to be quite a pfSense gathering as well, but they have all migrated to OPNSense because the DHCPv6 client in OPNsense is much more flexible and supports RAW options. There are a few that stayed on pfSense but hacked it by replacing the DHCPv6 client with the OPNSense binary - but that is not without issues…. -
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
Orange started tightening up the DHCP RFC requirements on the DHCP exchange, and I stopped being able to renew my IP.
What I make of it ( I'm not French at all, but I can read 'french' very well ) : people still manage to connect, but the rules are more strict.
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
because the DHCPv6 client in pfSense does not support dhcp RAW options - at least in 22.05
Create you own /root/att-rg-dhcpv6-pd.conf file : the dhcpd6 config file, and you have full control ;) You only need to know how to create such a file : you have to look up the options yourself.
That worked for me to obtain more then one prefix from my Livebox 6 (but still, the second was not operational, not routed).@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
replacing the DHCPv6 client with the OPNSense binary - but that is not without issues
As long as the ABi or FreeBSD kernel version is the same, changes are create it works.
I'm not sure if it needs a "non standard" dhcpd6 client version.
You'll lose the full GUI control .... but we never had full GUI control anyway, just look at all the Ipv4 option for dhcp-client : if you need them, you have to implement them manually with options or go for the :
-
@gertjan & @stephenw10
Okay, I have learned i lot so far:- PfSense does respect the renewal timer and sends a request when the renewal interval expires.
But i accidentally created my packetcapture on WAN (which is mvneta0.832) instead of the RAW mvneta0 interface, so while the renewal requests were sent, I could not see if they were 802.1p priority 6 tagged as they should be.
I cannot find a way to manually attempt to renew the DHCP lease without releasing it first (which leads to a discover instead of a request).
The closest thing I found was “/sbin/dhclient -l /var/db/dhclient.lease.mvneta0.832 mvneta0.832”
That command does trigger a dhcprequest, but it is broadcast instead of unicasted to the DHCP server, and it is critically NOT 802.1p priority 6 tagged.So my main suspicion now is that while DHCP discover packets are 802.1p priority 6 tagged (because of “vlan.pcp 6” in modifiers), the lease renew packets are not. Which would explain why Orange ignores them.
This then leads me to a bug I discovered in the packet capture UI dialog of pfsense. I cannot create a capture with a protocol or port filter that captures VLAN tagged packets on the RAW interface. I can only capture VLAN tagged packets if I do not filter for anything.
That makes it “impossible” for me to capture the actual renewal attempt tomorrow and see if it is VLAN priority tagged. My only option is to calculate approximate renewal time and prevent any clients from talking in that period, and then manually capture everything, and hope the size is “workable”, so I get the actual renew attempt. -
Probably better running a pcap at the CLI for something like that. In 23.01 at least. 23.05 has a whole new interface to allow that.
Have you tried setting pcp 6 on the VLAN intself? That would send all traffic priority tagged but that probably doesn't matter.
Steve
-
@stephenw10 Okay, but how would the command line version of a tcpdump on mvneta0 look if it should filter so only UDP packets with ports 67/68 in use are captured (regardless of having VLAN tags on them)? My intial try shows the same behavior as the UI - standard filters ignores VLAN tagged frames.
-
I would try:
tcpdump -eni ix3 -c 1000 -U '((udp) and (port 67 or port 68)) or ((vlan and (udp) and (port 67 or port 68)))' -
@stephenw10 I’ll give it a spin. When done from the CLI, do I have to keep the SSH session open to avoid it being killed if I’m disconnected or my ssh client goes to sleep?
Or should I do at the console to allow it to run?
How do i stop a cli driven tcpdump?Love the no fuss of using the official appliances :-)
-
Okay - I’m still waiting for my first renew attempt after changing thing around, but it seems it’s VERY likely a missing COS6 tagging of DHCPv4 Renew frames that is the culprit.
I found this thread on OPNsense’s forum (i check there because OPNsense is used a lot more in france because they are quicker and more flexible with DHCP client issues and options):
https://forum.opnsense.org/index.php?topic=33376.0
Very clearly the same issue, and clearly a floating rule with a match to change the VLAN COS tagging on renew frames is the solution. I have just implemented my rule now, and tonight at renew time we will know if this is the same bug in the DHCP Client (which is now patched on OPNsense).
