Odhcp6c often not reading the ADVERTISE response

For Developers
#1

the odhcp6c is suffering from instabiliy in reading the ADVERTISE response from SOLICIT requests.
It is probably the cause of another issue reported here in Apr 2022
I have detected by tcpdump that in spite of the upstream server immediately sending the ADVERTISE response odhcp6c does not read it. Typically after a restart the ADVERTISE is not read until 2-3 SOLICITS have been sent (and been responded to by the server).
It is also occurring after quite a number of SOLICITs or never.
In the mean time Router Advertisements are received and processed without problems
Below is a log displaying the behaviour. I have only modified the odhcp6c by inserting som better logging, not changing the internal logic at all.
I have failed in detecting any reason e.g. other programs listening on the same port.
The platform used is Linux Fedora 36 kernel 5.18.13
"Resource temporary available" means no data received before timeout.

Jul 31 01:31:21 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:31:21 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 14801534 < re=14927546
Jul 31 01:33:31 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=126,12000 err=11,Resource temporarily unavailable
Jul 31 01:33:31 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:33:31 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 14931070 < re=15055066
Jul 31 01:35:38 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=123,996000 err=11,Resource temporarily unavailable
Jul 31 01:35:38 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:35:38 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 15058046 < re=15178262
Jul 31 01:37:13 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=120,216000 err=4,Interrupted system call
Jul 31 01:37:13 ns4 odhcp6c[704]: ra_pr: Receive RA sock=5 len=64 err=0,Success
Jul 31 01:37:13 ns4 odhcp6c[704]: ra_pr: Receive RA sock=5 len=-1 err=11,Resource temporarily unavailable
Jul 31 01:37:14 ns4 odhcp6c[135392]: SCRIPT call /usr/sbin/odhcp6c-update eth0 ra-updated 2
Jul 31 01:37:14 ns4 odhcp6c[135392]: ENTER /usr/sbin/odhcp6c-update eth0 ra-updated 2
Jul 31 01:37:14 ns4 odhcp6c[135392]: DONE /usr/sbin/odhcp6c-update eth0 ra-updated 2 rc=0
Jul 31 01:37:14 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=24,831000 err=4,Interrupted system call
Jul 31 01:37:38 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=23,720000 err=11,Resource temporarily unavailable
Jul 31 01:37:38 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:37:38 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 15178366 < re=15296806
Jul 31 01:39:40 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=118,440000 err=11,Resource temporarily unavailable
Jul 31 01:39:40 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:39:40 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 15299710 < re=15429430
Jul 31 01:41:51 ns4 odhcp6c[704]: Receive cycle sock=4 len=-1  tv=129,720000 err=11,Resource temporarily unavailable
Jul 31 01:41:51 ns4 odhcp6c[704]: Sent SOLICIT message to ff02::1:2 err=0, Success)
Jul 31 01:41:51 ns4 odhcp6c[704]: Receive rounds len=-1 <0, rs= 15430782 < re=15552666
#2

platform for what ?

#3

Check the firewall, I had similar issue with banIP blocking the responses.

dhcp6 server hopefully :smile:

#4

As I described: the ADVERTISE response is not blocked by the firewall as it is eventually read by odhcp6c

No, where odhcp6c is running as the ISP has some requirements not fulfilled by most other DHCP6 clients.

#5

Yes, mine was working from time to time.

And where is OpenWrt in all this equation?

#6

FYI. I checked the firewall and it is allowing the traffic

  <port protocol="udp" port="546"/>
  <destination ipv6="fe80::/64"/>

Another (working) client is always accepting basically identical ADVERTISE packets with source and destination adresses identical in the fe80::/64 prefix

#7

Nowhere. This is about odhcp6c running as a client on a Linux server acting as a router.
I don't see odhcp6c depending on anything else in the OpenWrt project.
I believe it to be an independent program, which happen to be usable also in the OpenWrt project.

#8

then you're in the wrong forum ....
might get lucky at https://bugzilla.redhat.com/

#9

I don't think so.
[https://git.openwrt.org/?p=project/odhcp6c.git]

https: //github.com/search?q=odhcp6c
This repository is a mirror of https://git.openwrt.org/?p=project/odhcp6c.git
Everything about odhcp6c is pointing towards OpenWrt

#10

You have obviously already compared the srpm content with the source available at github, so you know there are no RedHat/Fedora specific patches involved, and they use the latest version of the source ?

#11

There is no substantial difference between the Redhat version and the latest version I am working on.
They use the April 2021 version and the most recent version has a couple of changes in no way related to the problem described here.

#12

Good and bad news.
I tested some more and in the /etc/firewalld/firewalld-server.conf I changed 'no' to 'all' in
LogDenied=all
This caused some
kernel: rpfilter_DROP: lines
to be displayed in /var/log/messages.
After disabling rpfilter by
IPv6_rpfilter=no
the missing ADVERTISE packets problem appears to be solved.

However, I know too little about rpfilter to explain this and the intermittent nature of the problem.
Maybe some timing in the routing setup.

#13

Fancy that, my guess was right. :slight_smile:

1 Like
#14

just rub it in :slight_smile: