Core dump when HUP - Only happens when RAW options are in use. about dhcp6c HOT 24 CLOSED

Nice one - I'm in France in February so can give it a good old TEST

from dhcp6c.

Orange France required the following raw options to be issued with a dhcp6c request
raw-option 6, raw-option 11, raw-option 15, raw-option 16

On boot the dhcp6c request is sent with all options populated with the appropriate strings/values. Periodic renewals (Orange lease is 24 hours) of the IPv6 prefix also happen without issue

However in my case on a LAN unplug replug event the subsequent dhcp6c requests to the ORANGE servers are ignored. A Wireshark trace of the port showed that reason for this was that the dhcp6c request was being issued with all the required raw-options but that the contents of raw-option 15 had been corrupted. This results in no reply from the server and effectively no IPv6 prefix being returned.

I can confirm that with the changes Martin has made the issue is removed.

from dhcp6c.

TAILQ_REMOVE shouldn't free so it's either a race or another less obvious problem with it. Need a bit of time to check this but we'll target 19.1 for sure.

from dhcp6c.

I don't think it's a race condition. The other thing that I noticed is that when I compile it the size is much larger than the distributed version, maybe something going on there perhaps.

from dhcp6c.

Size is likely because of PIE being enabled?

The missing free creates a leak, which hides a double-free by trading it for another slightly less problematic bug.

from dhcp6c.

@fichtner - Think I MAY have found something else. I have re-instated the free() call, enabled all of the extra logging message for the RAW options and looked elsewhere. I was seeing multiple free calls in the logging, far more than should be seen,

In config.c in the configure_commit() function there is a call at 1340 to rawop_clear_list(), this is duplicated further down in the same function at line 1401. I have commented out the call at 1340 and all seems stable.

Thoughts.

from dhcp6c.

@fichtner Is this still planned for 19.1 ?

from dhcp6c.

This one then? 162461f

from dhcp6c.

Ok, just in time for 19.1 whew :)

from dhcp6c.

Yes, it was the second commit.

from dhcp6c.

Hello,
I'm also using the livebox config replacement.
Upgraded to 19.1
This operation will crashes dhcp6c.
It produces a big /dhcp6c.core file that I can't use

The question is no the legitimacy of the config but the crash resulting

I want to have a n IPV6 also on the interface dedicated to the livebox.
So basically my first try is 'do the same as the LAN interface'.
=>IPv6 config type : trackt
=>Track IPv6 interface : WAN

Save, Apply
=>coredump

Remove the config Save Apply
No way to restart DHCPv6 server with dashboard
Reboot server : still dead DHCPv6 (after 5 minutes)
Second reboot : now gets immediately the IPV6 for LAN

Franck

from dhcp6c.

We found an issue where the core was being dumped and I was able to replicate it at will. After the changes I made the issue did not appear again. I'm willing to take another look at it though.

The issue was triggered by WAN flap, the physical connection being intermittent. @nivek1612 is back in France shortly and its on his list to test this thoroughly.

from dhcp6c.

Hello Martin,
I have also another method to kill DHCPv6 (19.1) involving manipulation on the WAN port.
But I can't reproduce at will.
I was sending some 'ifconfig em0 down;ifconfig em0 up' a lot and bam !
But this em0 is only physical support for Vlans so....

Can't someone exploit the core dump with an opnsense+symbol+debugger ?

from dhcp6c.

Franck78 was this at 19.1 or 19.1.1 ?

from dhcp6c.

I cannot replicate this. Clean install of 19.1 and update. Set the options and all is working. Repeatedly physically interrupted the WAN interface and used the iface down/up method and no issues.

from dhcp6c.

Ok,
As I said, the 'second' method for killing DHCPv6 is far far from 'at will'. I have to find the path.

But setting IPv6 to track t for the LB_NIC interface sure does kill DHCPv6.
18.x, 19.1, 19.1.1

The xml config expurged from some passwords :
config-opnSense.nopw.xml.txt

It runs as a VM with 4 hardware NICs under libvirt/kvm/ubuntu server 18.04(LTS).

Just set "track t" for ipv6 on LB_Nic.

Franck

from dhcp6c.

So you have the OPNSense box configured with a second NIC set to provide the LB with IPV4 and IPV6 I assume this is for the telephone service ?

The LB as you know issues some unusual raw-options which I'm not sure the dhcp6s code on the OPNsense is set up to handle. I think martin only set up dhcp6c to send them to Orange.

The if you disable IPv6 on the LB but keep your settings on OPNsense the same does it still crash DHCPv6 ?

from dhcp6c.

Same with the Livebox unplugged
This eliminates any kind of errors with received answer from the livebox.
Just turn ON Track interface and DHCPV6 (client & server is dead with coredump).

from dhcp6c.

Can you give me the details /usr/local/sbin/dhcp6c please. Size and date etc.

from dhcp6c.

root@opnSense:~ # ls -l /usr/local/sbin/dhcp6c
-r-xr-xr-x 1 root wheel 256464 Jan 27 16:40 /usr/local/sbin/dhcp6c

from dhcp6c.

dhcp6c.zip

Try this one.

from dhcp6c.

I don't understand. This version is the one already installed on my system. DHCPv6 is not mentioned in the 19.1.1 changelog........??????
And I don't have the coredump anymore. Sure a reboot was necessary after installing the patch.
Strange strange...

I don't have an IPv6 either for the LB_NIC, but at least no more coredump.

from dhcp6c.

I sent it you because on my system I cannot make it crash, therefore it might be possible that you have a corrupt dhcp6c client. IF that's not the case then fine, but we have to start somewhere.

DHCPv6 means everything to do with dhcp on IPv6, whether that is dhcp6c or dhcpdv6 - and no, it had nothing to do with 19.1.1

from dhcp6c.

Then it is beyond my logic.... I only renamed the existing dhcp6c file and copied the one from the zip and no more coredump (and the files are identical).
Now I can put Track on both LAN_NIC & LB_NIC but only one got the IPv6 2A01xxxx

LAN_NIC <= Track , got the 2A01xxxx IP
LB_NIC <= No ipv6
And a reboot is still necessary if you do this
LAN_NIC <= No ipv6, save
LB_NIC <= Track, save, apply
The dhcpv6 server available in dashboard is dead until reboot and only then LB_NIC receives the 2A01xxxx ip

from dhcp6c.