FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN

SirSilentBob

@luckman212 Ok. Sorry, I misunderstood! I thought there was just the one.

betapc

Nice work. I follow all the instructions and I have when a run the command assign_gua_from_iapd.sh, there are 2 error the first one "specify an interface", so then run the command specifying the interface assign_gua_from_iapd.sh igb0 then I had the follow out put "waiting a few seconds for IA_PD no IA_PD detected in logs". I am on Verizon FiOS and I have access to IPv6. So what I am doing wrong?

Thanks

luckman212

@betapc What prefix are you requesting in your FIOS WAN Interface config? I just checked because it's been a while since I looked at this script tbh. The script is hardcoded to look for a prefix delegation of /56 (if you request a /64 for example, it won't work).

How does your config look? For example, here's mine

Can you run this command from your firewall console and post the output?

grep 'IA_PD prefix' /var/log/dhcpd.log

betapc

@luckman212 Thank you for replied. I run the command in the console and the output is nothing, just a blank line.

I am using FiOS and have same setting requesting /56 prefix delegation like in your screen shot.

The only thing is for my LANS show like this "SubnetPrefix Delegation (2600:xxxx:xxxx:xxxx::/64)". I don't have any control about that part.

Screenshot 2023-01-26 055624.png

Thanks again for your help.

luckman212

@betapc Something seems to be missing from your dhcpd.log. Mine looks like this

ae0c5151-960a-4b46-be8a-354acbc188a5-screenshot_jJHk9EoW.png

Are you doing something unique with your logging setup? What does tail -n50 /var/log/dhcpd.log show?

betapc

@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.**

luckman212

@betapc Which interface is your FIOS attached to? igb0? What does ifconfig -m igb0 say?

betapc

@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

luckman212

@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?

betapc

@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.

luckman212

@betapc I'm running out of ideas. What does the command below output?

sh -c '/sbin/rtsol -DF igb0 2>&1'

betapc

@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:

luckman212

@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)

betapc

@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?

luckman212

@betapc I'm not sure. Do you have debug enabled for dhcp6?

betapc

@luckman212 Yes I have that option check.

luckman212

@betapc I'm sorry but I'm really not sure where to point you next. Maybe someone else has an idea...

betapc

@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.

betapc

@luckman212

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.

Screenshot 2023-02-13 190517.jpg

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.

Screenshot 2023-02-13 190805.jpg

Screenshot 2023-02-13 191238.jpg

So this is normal behavior? or I need to do something else?

Thanks @luckman212

MikeV7896

@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.