ipv6 broken: radvd: can't join ipv6-allrouters on <interface>
-
@kiokoman
Have seen this on the previous week, but it does not look promising. No answers from developer, no code changes, nothing. -
Wait a minute....
We all rely on 1 person alone? -
@maverick_slo what do you mean?
-
@maverick_slo
Generally not quite like that
https://github.com/reubenhwk/radvd/graphs/contributors -
Not quite that but still bad.
Really bad. -
@maverick_slo
May be, but may be not, since we are not sure that it is not some configuration issue or not radvd issue at all.I am testing now latest snapshot with radvd workaround disabled, may be we have some improvements, also I've enabled this patch. 24H already tested, no problem, IPv6 works, previous ended ~6hours with IPv6 fail.
-
Failed again. Same can't join ipv6-allrouters on ix1
-
yeah, you were too optimistic
-
What mode do everyone use as router mode with HE?
Should it be "Assisted" for use with DHCPv6? -
Having squashed a regression to 6RD a few days ago (See #9649). At least for the first day, I thought my IPv6 problems were solved. No such luck, looks like I have joined this party now.
I first eliminated the log spamming "IPv6 forwarding" message. In the pfSense version "check_ipv6_iface_forwarding" is stubbed out, forcing the log spam. I removed the call and log message in interface.c (could have easily been changed to a dlog call instead on retrospect).
I begin to receive the "can't join ipv6-routers" message after about 24 hours. Hoping to capture the cause, I restarted radvd with debug level 4. When the "can't join" message begins to appear, a debug message that my interface, em0 in my case, "em0 is ready" stops. That suggests to me that radvd is failing in the call to "setup_allrouters_membership" code patch of device-bsd44.c in the calls to setsockopt. Not sure why this is occurring after 24 hours yet. will have to modify the patch code to get more debugging information.
-
welcome to the party ! i was unable to say hello earlier due to force majeure ...
-
@rschell
I see only one user-defined setting that is exactly 24H, it's
AdvValidLifetime 86400;
I don't think it's related, but... -
this still not fixed.
-
@yon-0
To be fixed, there must be someone who will fix. I see only @rschell going deeper so far. -
@w0w I don't understand this technology, so I can only feedback the problem.
-
@w0w
not exactly as you can see here https://forum.netgate.com/post/847189
the test that rschell is doing as already been made by me at that time, there was nothing usefull to share, i found out the same.. you can prevent the log to appear but that would not solve the problem. -
@kiokoman said in ipv6 broken: radvd: can't join ipv6-allrouters on <interface>:
@w0w
not exactly as you can see here https://forum.netgate.com/post/847189
the test that rschell is doing as already been made by me at that time, there was nothing usefull to share, i found out the same.. you can prevent the log to appear but that would not solve the problem.So you think that debugging
@rschell said in ipv6 broken: radvd: can't join ipv6-allrouters on <interface>:
Not sure why this is occurring after 24 hours yet. will have to modify the patch code to get more debugging information.*does not get us closer to the solution? You already did that with no luck?
-
yes, i already did that with no luck but i'm no expert so maybe he have more luck/knowledge than me
-
I improved the logging in "setup_allrouters_membership" routine with:
/* XXX: See pfSense ticket #2878 */ if (setsockopt(sock, IPPROTO_IPV6, IPV6_LEAVE_GROUP, &mreq, sizeof(mreq)) < 0) { dlog(LOG_ERR, 4, "can't leave ipv6-allrouters on %s, failed: %s(%d)", iface->props.name, strerror(errno), errno); } if (setsockopt(sock, IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq)) < 0) { flog(LOG_ERR, "can't join ipv6-allrouters on %s, failed: %s(%d)", iface->props.name, strerror(errno), errno); return (-1); }
This code has been running for about 15 hours so far. The result of the first setdockopt call every radvd cycle is:
"can't leave ipv6-allrouters on em0, failed: Can't assign requested address(49)"
so I'm not sure what that call is trying to accomplish in Ticket #2878, but it doesn't appear to do/result in anything in version 12 of FreeBSD. Have to dig deeper in the kernel I'm afraid.
The second setsockopt call hasn't produced an error yet, still 9 hours or so to go.
-
yeah i don't remember well but i think that the "address" in question was ff02::1 or something,
you can easily find out if you readtruss -p pidofradvd