[solved] PPPoE IA-PD woes
-
I would be sarcastic but I
ll leave that to you good ol
doc :)https://github.com/pfsense/pfsense/pull/3515
-
I would be sarcastic but I
ll leave that to you good ol
doc :)https://github.com/pfsense/pfsense/pull/3515
:D
Note that if you apply the lot you'll get REASONS working too, you should see some effects from dhcp6 renews no longer triggering wan updates, makes the logs much quieter.
-
I did not mean to be sarcastic, I wanted to make sure that there's a proper PR for this, otherwise you end up with half of the patches getting lost and things broken
-
J/K :)
About my IPv6 on pppoe iface issue, should I start new thread/redmine or is it somehow connected to this?
-
J/K :)
About my IPv6 on pppoe iface issue, should I start new thread/redmine or is it somehow connected to this?
It's ALL related in there somewhere, but gateway monitoring is not an area of pfsense I'm familiar with, so whether its related to locks and reasons, i'm summing the two, or something else thats always been there I have no idea… at the moment.
-
I'll snapshot my test system and do the patches, then I'll throw some curved balls at it and see if I can replicate the monitoring issue. On a side note, I'm changing ISP in a couple of weeks and my v6 will no longer be dhcp6 without RA ( that's a mismomer and we should change it! ) but similar to Mav*Slo, so I will be able to see exactly what's going on there.
-
No no, gateway monitoring is just consequence…
Look what I mean:
When things are 100% OK:
Status up PPPoE up Uptime 00:01:50 MAC Address 00:00:00:00:00:00 IPv4 Address 212.xx.xx.xxx Subnet mask IPv4 255.255.255.255 Gateway IPv4 212.xx.xx.xxx IPv6 Link Local fe80::xxx:xxx:xxxx:xxxx%pppoe0 IPv6 Address 2001:xxxx:xxx:x:xxx:xxx:xxxx:xxxx Subnet mask IPv6 64 Gateway IPv6 fe80::xxx:xxxx:xxxx:xxxx MTU 1492 In/out packets 1543787/651379 (1.61 GiB/46.27 MiB) In/out packets (pass) 1543787/651379 (1.61 GiB/46.27 MiB) In/out packets (block) 2393/0 (137 KiB/0 B) In/out errors 0/0 Collisions 0
And when there is no IPv6 on PPPoe:
Status up PPPoE up Uptime 00:00:23 MAC Address 00:00:00:00:00:00 IPv4 Address 212.xx.xx.xxx Subnet mask IPv4 255.255.255.255 Gateway IPv4 212.xx.xx.xxx IPv6 Link Local fe80::xxx:xxx:xxxx:xxxx%pppoe0 Gateway IPv6 fe80::xxx:xxxx:xxxx:xxxx MTU 1492 In/out packets 1545272/656932 (1.61 GiB/46.65 MiB) In/out packets (pass) 1545272/656932 (1.61 GiB/46.65 MiB) In/out packets (block) 2418/0 (137 KiB/0 B) In/out errors 0/0 Collisions 0
-
Can you do a test for me, go to the shell, and firstly check that dhcp6c is running, if it is, then can you send it a SIGHUP, SIGHUP being 'kill -1 PID', see if that makes it recover.
-
DHCP6c IS running.
root 39375 0.9 0.1 8348 2328 - Ss 10:04 0:00.00 /usr/local/sbin/dhcp6c -D -c /var/etc/dhcp6c_opt2.conf -p /var/run/dhcp6c_pppoe0.pid pppoe0
Killed it:
kill -1 39375
No change on pppoe :(
-
And quite a lot of:
Mar 12 10:14:33 php-fpm 80662 /rc.newwanip: ROUTING: setting IPv6 default route to fe80::xxx:xxx:xxxx:xxxx%pppoe0 Mar 12 10:14:33 php-fpm 60486 /rc.newwanipv6: rc.newwanipv6: No IPv6 address found for interface PPPOE [opt2]. Mar 12 10:14:33 php-fpm 60486 /rc.newwanipv6: rc.newwanipv6: Info: starting on pppoe0\. Mar 12 10:14:31 php-fpm 80662 /rc.newwanipv6: rc.newwanipv6: No IPv6 address found for interface PPPOE [opt2]. Mar 12 10:14:31 php-fpm 80662 /rc.newwanipv6: rc.newwanipv6: Info: starting on pppoe0. Mar 12 10:14:31 rtsold Starting dhcp6 client for interface opt2(pppoe0) Mar 12 10:14:31 rtsold Received RA specifying route fe80::xxx:xxx:xxxx:xxxx for interface opt2(pppoe0)
-
What do the dhcp logs show at that moment?
-
Actually same as when it works… I see nothing special there...
-
So it appears dhcp6c is working, and by the look of it so is RTSOLD. Hmm, pppoe thing. Not even sure if it's related or not.
Try this, see if it makes any difference. Just add it on the end of the others.
c3b55b8a0aee8fde7474738d08a993ed32ee3282
-
Parse error: syntax error, unexpected ')' in /etc/inc/interfaces.inc on line 3303 Call Stack: 0.0001 226808 1. {main}() /usr/local/www/system_patches.php:0 0.0002 227304 2. require('/usr/local/www/guiconfig.inc') /usr/local/www/system_patches.php:29 0.0005 248832 3. require_once('/etc/inc/authgui.inc') /usr/local/www/guiconfig.inc:47 0.0005 249416 4. include_once('/etc/inc/auth.inc') /etc/inc/authgui.inc:25 0.0005 249848 5. require_once('/etc/inc/config.gui.inc') /etc/inc/auth.inc:30 0.0015 270984 6. require_once('/etc/inc/notices.inc') /etc/inc/config.gui.inc:37 0.0016 271392 7. require_once('/etc/inc/functions.inc') /etc/inc/notices.inc:24
:(
-
Nuts… Didn't test it.. Give me ten minutes.
-
Fixed it myself…
Just removed extra ")"... testing now -
Not helped
-
Baffled. ???
So it works unless you pull the link for more than 'n' seconds though. So what's changing after that 'n' seconds that's preventing a recovery?
Do we need to send another RA and reset the whole sequence, we know that dhcp6c is running bit a kick up the bum with a SIGHUP did not fix it. Try running the RTSOLD script from the shell and see if that kicks anything into life. It should report lock in place etc but will send out an RS.
-
Yeah link flap for 10 seconds or less is ok… As soon as last lcp is missed and pppoe starts reconnecting if I then plug utp back in no ipv6 address on pppoe...
How do I run rtsold script from shell?
Will try it in hour or 2 when I come home... -
Yeah link flap for 10 seconds or less is ok… As soon as last lcp is missed and pppoe starts reconnecting if I then plug utp back in no ipv6 address on pppoe...
How do I run rtsold script from shell?
Will try it in hour or 2 when I come home...In /Var/etc you should see a script something like rtsold_{IFACE}_script.sh, where {IFACE} is the interface you are interested in.
To run it, just do ./ rtsold_{IFACE}_script.sh
I'll squash down those commits it's getting untidy.