dhcpv6relay plugin: Make all sockets non-blocking. #572
Conversation
$ strace -p 3701
strace: Process 3701 attached
read(14^C^Cstrace: Process 3701 detached
$ ls -lah /proc/3701/fd/14
lrwx------ 1 root root 64 Oct 22 02:52 /proc/3701/fd/14 -> 'socket:[2478479691]'
$ grep 2478479691 /proc/net/{udp,tcp,raw}*
/proc/net/raw6: 118: 000002FF000000000000000002000100:003A 00000000000000000000000000000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2478479691 2 00000000c0af204a 0
So it's blocking trying to receive RS. This seems bogus, as the only
raw socket is dhcpv6relay_sock_rsra, and this only ever gets read from
dhcpv6relay_router_solicitation which should only ever be called if
event-handler determines there's data available.
All sockets are datagram (and by implication already deemed
"unreliable") based, so making them all non-blocking should have no
adverse effect, however, blocking pppd process most certainly has
undesired effects.
Signed-off-by: Jaco Kroon <[email protected]>
966d74e to
3c05589
Compare
|
@paulusmack perhaps you'd like to see if you can spot something else, I make explicit note there are other raw sockets used in pppd, but I can also confirm socket fds 12 and 13 are dhcpv6proxy based on udp6 sockets with dhcp port numbers, and the rsra socket is created directly after those in the code ... so I'm 99% sure this is the one. We only seem to get this on a specific remote brand router though ... which does make me wonder about a few things. Not yet in production, would prefer another eyeball on this before taking to production (which is based on the specific remote router and setup that is quite unique to the brand - not the one with the IA_NA problem - the only relevant place I can reliably test this). @enaess definitely a 2.5.3 problem in my opinion :). |
|
@paulusmack: Have you seen this @jkroonza PR? |
$ strace -p 3701
strace: Process 3701 attached
read(14^C^Cstrace: Process 3701 detached
$ ls -lah /proc/3701/fd/14
lrwx------ 1 root root 64 Oct 22 02:52 /proc/3701/fd/14 -> 'socket:[2478479691]'
$ grep 2478479691 /proc/net/{udp,tcp,raw}*
/proc/net/raw6: 118: 000002FF000000000000000002000100:003A 00000000000000000000000000000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2478479691 2 00000000c0af204a 0
So it's blocking trying to receive RS. This seems bogus, as the only raw socket is dhcpv6relay_sock_rsra, and this only ever gets read from dhcpv6relay_router_solicitation which should only ever be called if event-handler determines there's data available.
All sockets are datagram (and by implication already deemed "unreliable") based, so making them all non-blocking should have no adverse effect, however, blocking pppd process most certainly has undesired effects.