RTSOLD <sendpacket> sendmsg on igb0: Can't assign requested address
I'm getting this message on my pfsense. As result I'm unable to get an IPv6 address.
My igb0 is the WAN and is set to DHCPv6 only get the prefix.
I'm running version 2.4.5
I have set IPv6 to none and restart the pfsense without luck
Any ideas ?
Try doing a packet capture on WAN, filtering on dhcpv6, and post it here.
This is what I got.
The error appeared at 15:57:48 at the log.
15:57:36.075286 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::1272:23ff:febb:2a0 > ff02::1: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener query v2 [max resp delay=0] [gaddr :: robustness=2 qqi=10] 15:57:46.085988 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::1272:23ff:febb:2a0 > ff02::1: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener query v2 [max resp delay=0] [gaddr :: robustness=2 qqi=10] 15:57:50.728173 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 128) fe80::1272:23ff:febb:2a0 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 128 hop limit 64, Flags [other stateful], pref high, router lifetime 180s, reachable time 0ms, retrans timer 0ms prefix info option (3), length 32 (4): 2804:431:c7d4:56d0::/64, Flags [onlink, auto], valid time 259200s, pref. time 172800s 0x0000: 40c0 0003 f480 0002 a300 0000 0000 2804 0x0010: 0431 c7d4 56d0 0000 0000 0000 0000 route info option (24), length 24 (3): 2804:431:c7d4:56d0::/64, pref=high, lifetime=259200s 0x0000: 4008 0003 f480 2804 0431 c7d4 56d0 0000 0x0010: 0000 0000 0000 rdnss option (25), length 24 (3): lifetime 1200s, addr: fe80::1272:23ff:febb:2a0 0x0000: 0000 0000 04b0 fe80 0000 0000 0000 1272 0x0010: 23ff febb 02a0 dnssl option (31), length 16 (2): lifetime 1200s, domain(s): br. 0x0000: 0000 0000 04b0 0262 7200 0000 0000 mtu option (5), length 8 (1): 1500 0x0000: 0000 0000 05dc source link-address option (1), length 8 (1): 10:72:23:bb:02:a0 0x0000: 1072 23bb 02a0 15:57:56.095668 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::1272:23ff:febb:2a0 > ff02::1: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener query v2 [max resp delay=0] [gaddr :: robustness=2 qqi=10]
Can you provide the capture file? It's a lot easier to read this sort of thing in Wireshark.
Also, that's an icmp6 packet you showed, not dhcpv6.
Here it is
That's still icmp6, not dhcp6. Since you seem to have a dhcp6 problem, you need the dhcp6 packets. To capture dhcp6, you filter on port 546 or 547, doesn't matter which.
So, I selected only IPv6 without filters on the capture above.
If I select IPv6 and filter by port, the result is empty.
Should I pick IPv4 too ?
Since dhcp only runs occasionally, depending on lease time, it might be a long wait. You can trigger it by disconnecting/reconnecting the WAN cable. However, that will only produce half of the dhcp sequence, though that might be enough. To get the entire sequence, you have to reboot pfSense. I have done that with a managed switch, configured for port mirroring and Wireshark, rather than with Packet Capture. You might be able to do the same by booting pfSense, with the WAN cable disconnected and then connecting it, but I haven't tried that. Just try disconnecting and reconnecting and see what that turns up.
BTW, you'd run into the same capture issues with dhcp on IPv4, as it goes through similar steps.
Sorry, I should have mentioned that it was what I did. I save the configuration again and I could see the error logged in the log with the time stamp that showed it just happened.
Weirdly, it didn't show on the capture.
I have restore the pfsense to factory default and I have restored only the DHCPv4 so I didn't have to retype all the static addresses. I guess something is funky.
I'm thinking of reset it and type the addresses again. Let's see if it solve the matter
That packet capture might tell what the issue is. Last year I had an IPv6 problem with my ISP. With the method I mentioned, using a managed switch and Wireshark, I was able to determine not only the problem, but also the failing system, by host name.
Here's part of the capture that showed the problem:
Option: Status code (13)
Status Code: NoPrefixAvail (6)
Status Message: No prefix available on Link
A capture of your dhcpv6 might show something useful.
Ok, I was able to reset to factory and reboot.
After that I was able to get IPv6 at the wan side. The Wan is set to DHCP6 and it's getting the assigned IP from the ADSL provider.
At the LAN side it's not working. I tried to set it to track interface WAN, no IPv6. Tried SLAAC no IPV6. Tried DHCP6, the same.
I checked in the ADSL Modem and it is delegating a /64 prefix. I don't know what is happening with the LAN interface.
At a point yesterday, I set the WAN to none and even after it the WAN kept showing an IPV6 address. There was no gateway to IPv6 but the address was still there. I had to restart the pfsense to make it go away.
I keep wondering if there is something wrong with the installation, or if this is a bug known.
First off, what does your ISP provide, such as prefix size? How do they provide IPv6? Usually they use DHCPv6-PD, but they may do something different. As I mentioned a packet capture of the DHCPv6 sequence may provide some info. Also, you could mention your ISP. Someone else here might have experience with them.
Try this, disconnect the WAN side and reboot the firewall. Start up Packet Capture to capture DHCPv6 and then connect the WAN. Hopefully, that will provide the full DHCPv6 sequence.
I haven't used pfsense with ADSL, so I don't know the details of that.
I'm on a cable modem. With it, my WAN address is a /128 and link local addresses are used for routing.
I don’t have a managed switch now. So I can’t get a sniffer to see what’s going on there. I bought one and I’ll do it as soon as it arrives.
My ISP is called Vivo. I live in Brazil.
It provides a / 64 prefix this is the IADP 2804:431:c7d4:788e::/64
The modem has a DHCP6 PD stateless enable and also RADVD enable with ULA prefix disable.
Do they only provide a single /64, as some do? Or do they also provide a larger prefix for the LAN side. With my ISP, I get a /56, but if I used their modem in gateway mode, I'd only get a single /64. Also, when they first started providing native IPv6, they only provided a single /64, even in bridge mode. So, what does your ISP provide?
Also, you can try the instructions I provided to see if you can get the DHCPv6 capture with Packet Capture.
Here the information I have on the ISP MODEM
Then it has a delegated LAN IPv6 info 2804:431:c7d5:120c:1272:23ff:XXXX:XXXX/64
These are the captures from the WAN and LAN interface.
I only see one DHCPv6 packet on the WAN side and it appears to be a solicit. What I'd like to see is the response. Also, what size prefix are you requesting in pfSense?
I don't know why just one. I'll leave it capturing for a longer period let's see if something shows up.
I have WAN set up as showed below
The LAN is Tracking WAN.
Should I use something smaller than 64 ?
This is a capture of 10 minutes.
Only soliciting, no replies.
There are IPV6 blocked by the FW at the LAN side
It seems a DNS query, not sure if it relates or not to the problem
Some other info from the logs
Start Packet Capture, filtering on DHCPv6 on WAN. Then pull the WAN cable and plug it back in. That should cause DHCP to kick in. As I mentioned last week, DHCP only occurs at long intervals, depending on the lease time.
Ok. Just did it. I didn't see replies
maybe I'm wrong
Here's another one. I started the capture, disabled DHCP6 on the wan interface. Applied the change, went back to the dashboard and could see that there was not IPv6. Went back to the interface and enabled DHCP6, applied the change. At the dashboard it has an IPv6.
This is the capture of it
In your WAN captures, I'm only seeing the Solicits from pfSense, but nothing coming back. The ISP should be responding.
Here's what a normal 4 step DHCPv6 process looks like. It has solicit, advertise, request and reply steps. You only have the solicit. You should be getting an advertise next.
It's driving me crazy. I tried again to disable DHCP6.When I went on the dashboard the IPv6 of the WAN continued there.
I disabled the interface, enabled it again without enabling DHCP6 and it stayed with an IPv6.
The only way to get rid of it was to reboot the pfsense.
Any new idea ?
I have another problem that this HW is not working as PPOE. I read something about an issue with APIC that causes the PPOE not to work. I'm thinking if there is something related to it too on the IPv6 side.
Not really. All I can suggest is to try reconfiguring pfSense from scratch. After so much, it's hard to say what you might have done. Does your ISP provide any info or support?
Tks for your support