Hello,
after upgrading to 19.1 the OPNsense has no IPv6 on the WAN interface anymore. On the WAN side the OPNsense is connected to a FritzBox.
There is no dhcp6c running. Also changing the configuration in the web interface don't cause changes to the file /var/etc/dhcp6c_wan.conf.
Has someone else observed something similar?
Cheers,
iam
Check the system & dhcpd log for any dhcp6c entries, is there anything there?
The last entry in /var/log/dhcpd.log was written before the upgrade.
Here are the maybe relevant entries in system.log:
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: no IPv6 default gateway set, assuming wan
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.XY.1
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: removing /tmp/re0_defaultgw
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: creating /tmp/re0_defaultgw using '192.168.XY.1'
Feb 3 14:18:50 opnsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 3 14:18:51 opnsense opnsense: /usr/local/etc/rc.dyndns: Aborted IPv6 detection: no address for re0
No, we are looking to see if there are any entries from dhcp6c. If it's not starting ( or exiting ) there should be a log entry.
Maybe this is more helpful:
Feb 1 07:46:41 opnsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/ifconfig re0 inet6 $ipv6address delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
EDIT: Of course not. That was before the upgrade
I can start the dhcp6c manually:
/usr/local/sbin/dhcp6c -f -d -D -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_re0.pid re0
It's no crashing and binds an IPv6 address to the interface. But the routing table seems not to be correct afterwards.
Is there a config file like /etc/network/interfaces in Debian?
Have you tried enabling Direct!y send solicit in dhcp6c settings?
Yes I've enabled this option in the web interface. But I'm not sure that is synced to the configuration files. Changing the prefix size doesn't change /var/etc/dhcp6c_wan.conf. It's still:
interface re0 {
send ia-na 0; # request stateful address
send ia-pd 0; # request prefix delegation
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
prefix ::/60 infinity;
};
Even so, dhcp6c should be starting, you will see that in the logs. Have you set dhcp6c debug on and the rebooted. Then take a look at the dhcpd logs and filter on dhcp6c.
As expected, there is still no log entries regarding DHCPv6 (only after starting dhcpv6 manually).
By the way, it's also a RealtekChip, but with static IPv4. The MTU is 1500.
Something is very wrong here. Can you scp into opnsense and copy the system, configd and dhcpd logs. zip them up and attache them your reply.
I've just tried my test unit with a static v4 and dhcp6 on the wan, works perfectly.
Here are the requested logs.
Your ISP is not responding in the expected way. There's loads of entries from dhcp6, here's just a sample.
Can you turn on the debugging option in dhcp6c settings on the WAN page. Save and reboot, let it run for an hour then send me the dhcpd log again.
You mean this entries?
Feb 2 09:16:45 opnsense dhcp6c[30652]: Received REPLY for RENEW
Feb 2 09:46:45 opnsense dhcp6c[30652]: Sending Renew
Feb 2 09:46:45 opnsense dhcp6c[30652]: unknown or unexpected DHCP6 option opt_86, len 16
Feb 2 09:46:45 opnsense dhcp6c[30652]: Received REPLY for RENEW
There were written before the upgrade. By the way, the ISP is a FritzBox.
O.K. I see now.
The last four entries are actually created by dhcp6c*.script, but I know you said you manually ran it, so it might be from those. That being the case then dhcp6c is not being started but can run manually which rules out a corrupt dhcp6c client itself. It may be something as simple as a stuck pid. So we'll check that first.
Go and have a look in /var/run and and see if there is a dhcp6*.pid file there, if there is delete it and reboot.
There isn't such file.
Hmm, begins to sound like something is missing or corrupted. Have a look in System:Routes:Log Files, you should see entries for rtsold, do you see them?
It's looking like something has gone wrong with the update, and I would now consider a clean install. Note there are a couple of issues that are being corrected in 19.1.1 which is due in a couple of days. There's also likely to be a new installation archive at the same time if you wait, otherwise it would be clean install 19.1 then update to 19.1.1.
I cannot think of anything else that would stop dhcp6 from running, especially when directly send solicit is used as that forces dhcp6c to launch and once it runs it stays running unless the interface is taken down.
Quote from: marjohn56 on February 04, 2019, 09:54:54 PM
Hmm, begins to sound like something is missing or corrupted. Have a look in System:Routes:Log Files, you should see entries for rtsold, do you see them?
Yes, but the last entry is dated to July.
I'm surprised it's been working at all then.
I'll test it again with the next releases.
By the way, do you have configured static IPv4 and OpenVPN servers? This is maybe relevant for finding the error cause.
Hi,
do you have some more hints? At which point the dhcpv6 should be started normally?
Reinstalling might be a solution, but I prefer understanding and solving the problem instead of applying the sledgehammer method only.
Best,
iam
Ok I see. /var/etc/rtsold_re0_script.sh should call the dhcpv6. This works if I run the script without parameters manually:
#!/bin/sh
# this file was auto-generated, do not edit
if [ -n "${2}" ]; then
echo ${2} > /tmp/re0_routerv6
echo ${2} > /tmp/re0_defaultgwv6
fi
if [ -f /var/run/dhcp6c_re0.pid ]; then
/usr/bin/logger -t dhcpd "RTSOLD script - Sending SIGHUP to dhcp6c for interface wan(re0)"
/bin/pkill -HUP -F /var/run/dhcp6c_re0.pid
else
/usr/bin/logger -t dhcpd "RTSOLD script - Starting dhcp6 client for interface wan(re0)"
/usr/local/sbin/dhcp6c '-d' -c '/var/etc/dhcp6c_wan.conf' -p '/var/run/dhcp6c_re0.pid' 're0'
fi
But where should be called this script?
That script is called by RTSOLD when it receives an RA in response to its RS solicit.
An RS is generally the start of all IPv6 communications, the routers automatically find neighbours and create routes, this is why routing in IPv6 can be handled automatically.
If RTSOLD does not receive an RA then it will not run the script and dhcp6c will not run. However, if you have ticked 'Directly send solicit' ithen dhcp6c gets launched irrespective of whether or not an RA has been received. This is done because some ISPs deliberately require that a dhcp6 request is sent as well as the RS before they send an RA response.
What happens in the interfaces.inc script is shown below in a code snippet from interfaces.inc
mwexecf(
'/usr/sbin/rtsold -p %s -O %s -R %s %s %s',
array(
"/var/run/rtsold_{$wanif}.pid",
"/var/etc/rtsold_{$wanif}_script.sh",
'/usr/bin/true', /* XXX missing proper script to refresh resolv.conf */
empty($wancfg['adv_dhcp6_debug']) ? '-d' : '-D',
$wanif
)
);
if (isset($wancfg['dhcp6sendsolicit'])) {
mwexec("/var/etc/rtsold_{$wanif}_script.sh");
}
What you see above is the launch of rtsold, which will wait for the RA response to its solicit - then it will launch the rtsold script.
The second part says if 'Directly send solicit' is set ( dhcp6sendsolicit ) then run the rtsold script anyway.
In the RTSOLD script itself are two parts, you can ignore the first 'if' statement, that is setting up routes automatically, it's important, but not for what I am about to say. The second 'if / else' looks at whether dhcp6c is running or not, if it is then it sends it a SIGHUP to re-initialise it, if it is not running, and that's detected by looking for the pid file then it will start it up.
Make sense?
Hi,
many thanks for your explanations.
Running rtsold manually with
/usr/sbin/rtsold -p /var/run/rtsold_re0.pid -O /var/etc/rtsold_re0_script.sh -R /usr/bin/true -D re0
causes an working IPv6 connection. But this don't seems repeatable at least without a reboot.
So I guess that rtsold isn't starting automatically for some reason. Where I can found interfaces.inc on the file system?
Best,
iam
EDIT: I've found out the path myself: /usr/local/etc/inc/interfaces.inc
if you go to the shell:
> ps -auxw | grep rtsold
You should get something like what is shown below... do you?
root@OPNsense:~ # ps -auxw | grep rtsold
root 10626 0.0 0.0 1057660 2616 - Ss 12:01 0:00.03 /usr/sbin/rtsold -p /var/run/rtsold_igb0.pid -O /var/etc/rtsold_igb0_script.sh -R /usr/bin/true -D igb0
root 65097 0.0 0.0 1058012 2840 0 S+ 12:57 0:00.00 grep rtsold
Only if I start rtsold it manually.
Finally I've solved this issue. Many thanks for your help :)
I've checked the code and found this part:
if (!is_array($wancfg)) {
return;
}
Then I've read the description of the property "Use IPv4 connectivity": "Request the IPv6 information through the IPv4 PPP connectivity link."
There is no PPP connection controlled by OPNsense, so it don't make sense to activate it. So I've deactivated it and voilà, IPv6 is working.
Well that bit of code checks to see if there is a valid wan configuration array, the one the caused the bailout was this:
if (isset($wancfg['ipaddrv6'])) {
switch ($wancfg['ipaddrv6']) {
case 'slaac':
case 'dhcp6':
/* XXX why not tell the function... */
if (isset($wancfg['dhcp6usev4iface'])) {
break;
}
interface_dhcpv6_prepare($interface, $wancfg);
interface_dhcpv6_configure($interface, $wancfg);
break;
Anyway, glad its fixed. Marked it [SOLVED] ..