WAN dhclient (DHCP) issues - bug in time intervals?
-
@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).
-
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it. -
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it.So, after following the renew attempt last night and analyzing the packetcapture of the process, two things seems obvious:
1: The pfSense DHCP Client renews does not use and follow the "vlan-pcp 6" modifier that I have configured on WAN. Only Lease releases and DHCP discovery is priority tagged properly. Renew attempts are tagged with 0 = best effort. So I'm now 99,9% sure that's why I'm unable to renew my DHCP release. Orange clearly states it is required, and the OPNsense forum also shows lots of people with the same issue, that fixed it by priority tagging the renew process with priority 6.
2: My attempt at having a floating rule match and set the vlan priority 6 tag on renews did not work. Regardless of what I tried, no packets where ever matched with my attempted floating rule. I might not fully understand how to create the rule properly, but it seems quite simple, yet it didn't work. Is there a "loophole" where packets originating from an actual daemon on pfsense itself is not passed through the firewall rules?
I first created a match IPv4 rule with source "firewall (self)" UDP 68 to destination any port 67, and direction out on both the RAW and my vlan 832 tagged WAN interface. I set the match rule to apply VLAN priority tag 6. Didn't work.
I then opened the rule up with source any port any - didn't work
lastly I enabled Quick even though that should not be needed as I understand it - Didn't work.
Nothing was ever matched by by floating rule.Any idea if I'm doing it wrong?
Any idea's on how to get the DHCP client to respect the configured VLAN priority tag on renews as well? This should probably be considered an actual bug, so I'll create a redmine on that later today.
-
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it.Hmm loking at /tmp/rules.debug I’m suspecting my VLAN priority set is newer applied because the built-in web-configurator rules has a quick pass rule for dhcp requests out of WAN that are higher up in the rules.debug file that probably invalidates my match rule?
-
Yes if it's a 'quick' rule it will override anything below it so the match won't happen.
Setting the tag on the VLAN should apply to all traffic leaving it though so I'd expect that to work. -
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Yes if it's a 'quick' rule it will override anything below it so the match won't happen.
Setting the tag on the VLAN should apply to all traffic leaving it though so I'd expect that to work.Yeah But not really a good solution as the ISP severely throttles the amount of COS6 traffic allowed compared to the fibers actual throughput.
-
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
How do i stop a cli driven tcpdump?
Ctrl+C -
@stephenw10 FYI: https://forum.netgate.com/topic/180212/how-to-hack-built-in-dhcp-client-pfrule
-
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
vlan.pcp
Ah, OK I see, it's because the renewals are unicast and don't use the bpf rule. So, yes something similar is required there. Set the tagging on the pf pass-out rule if they are enabled in the dhclient.
Let's see...
