FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN
-
@luckman212 said in FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN:
Are you doing something unique with your logging setup? What does tail -n50 /var/log/dhcpd.log show?
I don't think so. I have default setting for logging.
[22.05-RELEASE][admin@yyyyyy.com]/root: tail -n** /var/log/dhcpd.log
Jan 26 21:48:00 yyyy dhcpd[82179]: Copyright 2004-2021 Internet Systems Consortium.
Jan 26 21:48:00 yyyy dhcpd[82179]: All rights reserved.
Jan 26 21:48:00 yyyy dhcpd[82179]: For info, please visit https://www.isc.org/software/dhcp/
Jan 26 21:48:00 yyyy dhcpd[82179]: Config file: /etc/dhcpdv6.conf
Jan 26 21:48:00 yyyy dhcpd[82179]: Database file: /var/db/dhcpd6.leases
Jan 26 21:48:00 yyyy dhcpd[82179]: Internet Systems Consortium DHCP Server 4.4.2-P1
Jan 26 21:48:00 yyyy dhcpd[82179]: PID file: /var/run/dhcpdv6.pid
Jan 26 21:48:00 yyyy dhcpd[82179]: Copyright 2004-2021 Internet Systems Consortium.
Jan 26 21:48:00 yyyy dhcpd[82179]: All rights reserved.
Jan 26 21:48:00 yyyy dhcpd[82179]: For info, please visit https://www.isc.org/software/dhcp/
Jan 26 21:48:00 yyyy dhcpd[82179]: Wrote 1 NA, 0 TA, 0 PD leases to lease file.
Jan 26 21:48:00 yyyy dhcpd[82179]: Bound to :5*
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb2./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb2./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb2./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb2./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb1./20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Listening on Socket/7/igb1/20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Sending on Socket/7/igb1/20:xxxx:xxxx:xxxx::/64
Jan 26 21:48:00 yyyy dhcpd[82179]: Server starting service.
Jan 26 21:48:01 yyyy dhcpd[71932]: DHCPRELEASE of 192.168..106 from :::::** () via igb1.** (found)
Jan 26 21:48:01 yyyy dhcpleases[25523]: Sending HUP signal to dns daemon(54451)
Jan 26 21:48:14 yyyy dhcpd[71932]: DHCPDISCOVER from 2c:::::d via igb1.*
Jan 26 21:48:** yyyy dhcpd[71932]: DHCPDISCOVER from 7c:::::8 via igb1.*
Jan 26 21:48:** yyyy dhcpd[71932]: DHCPOFFER on 192.168.**.101 to 2:::**::d () via igb1.**
Jan 26 21:48:** yyyy dhcpd[71932]: DHCPREQUEST for 192.168..101 (192.168..1) from 2:::::4d () via igb1.
Jan 26 21:48:* yyyy dhcpd[71932]: DHCPACK on 192.168..101 to 2*:::::d (******) via igb1.
Jan 26 21:48:** yyyy dhcpleases[25523]: Sending HUP signal to dns daemon(54451)
Jan 26 21:48:** yyyy dhcpd[71932]: ICMP Echo Reply for 192.168..101 late or spurious.
Jan 26 21:48:16 yyyy dhcpd[71932]: DHCPOFFER on 192.168..106 to 7*:::::** () via igb1.
Jan 26 21:48:16 yyyy dhcpd[71932]: DHCPREQUEST for 192.168..106 (192.168..1) from 7*:::::8 (******) via igb1.
Jan 26 21:48:16 yyyy dhcpd[71932]: DHCPACK on 192.168..106 to 7*::::: () via igb1.
Jan 26 21:48:16 yyyy dhcpleases[25523]: Sending HUP signal to dns daemon(54451)
Jan 26 21:48:21 yyyy dhcpd[71932]: reuse_lease: lease age 1411 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168..135
Jan 26 21:48:21 yyyy dhcpd[71932]: DHCPDISCOVER from 2:::::* () via igb1.
Jan 26 21:48:21 yyyy dhcpd[71932]: DHCPOFFER on 192.168..135 to 2:::::5 () via igb1.
Jan 26 21:48:21 yyyy dhcpd[71932]: reuse_lease: lease age 1411 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168..135
Jan 26 21:48:21 yyyy dhcpd[71932]: DHCPREQUEST for 192.168..135 (192.168..1) from 2*:::::*** () via igb1.
Jan 26 21:48:21 yyyy dhcpd[71932]: DHCPACK on 192.168..135 to 2:::::* () via igb1.
Jan 26 21:52:08 yyyy dhcpd[71932]: DHCPDISCOVER from 7*:::::** via igb1.**
Jan 26 21:52:08 yyyy dhcpd[71932]: DHCPOFFER on 192.168.. to 7:::::** via igb1.**
Jan 26 21:52:08 yyyy dhcpd[71932]: DHCPREQUEST for 192.168.. (192.168..1) from :::::** via igb1.**
Jan 26 21:52:08 yyyy dhcpd[71932]: DHCPACK on 192.168.. to ::c::: via igb1.** -
@betapc Which interface is your FIOS attached to? igb0? What does
ifconfig -m igb0
say? -
@luckman212 said in FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN:
ifconfig -m igb0
I am connected to igb0 for WAN
[22.05-RELEASE][admin@xxx.xxxx.com]/root: ifconfig -m igb0
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=8120b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER>
capabilities=f53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>
ether xx:xx:xx:xx:xx:xx
inet6 fe80::2e0:67ff:fe2c:6828%igb0 prefixlen 64 scopeid 0x1
inet 1xx.xx.xx.xxx netmask 0xffffff00 broadcast 1xx.xx.xx.xxx
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
supported media:
media autoselect
media 1000baseT
media 1000baseT mediaopt full-duplex
media 100baseTX mediaopt full-duplex
media 100baseTX
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>Thanks
-
@betapc Hmm. I wonder if you're hitting this known bug affecting Alcatel ONTs + Intel PHYs by chance? Could you retry after disabling Hardware Checksum Offloading at System → Advanced → Networking?
-
@luckman212 I already have disable the checksum, I have all 4 checks as show in the picture above, when I run the ifconfig -m igb0 command.
-
@betapc I'm running out of ideas. What does the command below output?
sh -c '/sbin/rtsol -DF igb0 2>&1'
-
@luckman212 said in FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN:
sh -c '/sbin/rtsol -DF igb0 2>&1'
[22.05-RELEASE][admin@xxx.xxxx.com]/root: sh -c '/sbin/rtsol -DF igb0 2>&1'
rtsol: checking if igb0 is ready...
rtsol: igb0 is ready
rtsol: set timer for igb0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on igb0, state = 1
rtsol: set timer for igb0 to 4s
rtsol: New timer is 4s
rtsol: received RA from xxx::xxx:xxx:xxx:xxx on igb0, state is 2
rtsol: ManagedConfigFlag on igb0 is turned on
rtsol: Processing RA
rtsol: ndo = 0x7fffffffe2e0
rtsol: ndo->nd_opt_type = 1
rtsol: ndo->nd_opt_len = 1
rtsol: rsid = [igb0:slaac]
rtsol: stop timer for igb0
rtsol: there is no timer
[22.05-RELEASE][admin@xxx.xxxx.com]/root: -
@betapc Is that the full output? Doesn't seem like you're receiving a PD in those frames.
There should be lines like this
rtsol: ndo->nd_opt_type = 25 rtsol: ndo->nd_opt_len = 3 rtsol: nsbuf = 2600:4041:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx ... rtsol: write to child = 2600:4041:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx(39)
-
@luckman212 Yes that is the full output, I don't see those line. I have IPv6, all my LANs received IPv6 and I can connect to the internet with IPv6 only. I release all the IP address and renew same didn't change anything.
So, what do you think will be the problem here?
-
@betapc I'm not sure. Do you have debug enabled for dhcp6?
-
@luckman212 Yes I have that option check.
-
@betapc I'm sorry but I'm really not sure where to point you next. Maybe someone else has an idea...
-
@luckman212 Thank you very much. I will wait for pFsense version 23.01 to be release and see what happen when I do a clean installation.
Do you think ipv6/dpinger fixes from PR #4595 will be included on version 23.01? and maybe a fix to handle IPv6 to WAN for cases like this on Fios?
Thank you for your contribution to pFsense.
-
Finally I make it work, I upgrade to 23.01 RC, removed limiters and WAN firewall rules for Bufferbloat mitigation, then I change on your scrip the python version from 3.8 to 3.9 and works.
The only problem is the getaway still showing the local IPv6 and not the one from Verizon, and is unable to identify if the getaway is
online or not.So this is normal behavior? or I need to do something else?
Thanks @luckman212
-
@betapc Verizon doesn't provide a global address to the WAN interface. They only provide a prefix that the router can use.
Verizon's own router takes an address from the "ff" prefix ID and assigns it to the WAN interface. pfSense does not provide an automated way to do the same though. I had manually accomplished the same thing by setting a virtual IP on WAN... but if my prefix ever changed in the future, I would need to change the virtual IP to match the new prefix. So I gave up on that.
I think @luckman212 had created a script to do something similar, that you could run regularly to change the address if the prefix had changed... I never looked closer at it though. I'm happy without a global WAN address... things work, that's what matters.
Mine seems to be happy pinging Verizon's end of the link-local route... not sure why yours would have problems with that. If you had a monitoring destination manually set, you'll need to remove that since the only thing it'll be able to ping without a global address is Verizon's end of the link-local route.
-
-
-
Parts sound alike the problem described here
https://forum.netgate.com/topic/177981/no-ipv6-after-upgrade-to-23-01
-
Good evening, are there any plans to update the system patch or the script for pfsense 23.01+ and devd integration. I find this to be particularly useful with dynamic dns that I use for sending IPv6 traffic to my existing pfsense. It helps a lot having an IP from gua in a somewhat automated fashion. Thanks for writing this, I am still baffled by how this script works, I need to brush up on my bsd scripting.
I think this would be a good feature for the mainline pfsense releases.
-
I'm on CE 2.6 and just want to ask a question before I start trying to implement @luckman212 's workarounds to obtain a GUA for the WAN interface.
Would a GUA for the WAN interface allow me to use HAProxy to listen on that interface via a proxy front end definition? I want to use HAProxy to connect IPv6 clients to a backend Mastodon self-hosted server. I'm guessing that isn't working even though HAProxy's front end is set to listen to IPv6 on the WAN because that interface has no GUA.
Thanks.
-
For anyone who, like me, upgrades from CE 2.6 to CE 2.7, be sure to change @luckman212 's script to reflect the latest version of python. See my pull request here.
-
@yobyot this issue has been fixed in the latest 23.05.1 update