delayed proxy addresses needs special handling since
it can use linklocal ifa as their source address and different
link-layer data in their response.
Fixes: f37fbe30f559
Fixes: 75f1665f3346
Differential D55850
ndp: Fix delayed proxy address Authored by pouria on Fri, Mar 13, 11:26 PM.
Details delayed proxy addresses needs special handling since Fixes: f37fbe30f559 kyua debug -k /usr/tests/Kyuafile sys/netinet6/proxy_ndp
Diff Detail
Event TimelineComment Actions Hi @glebius, Please look at the panic below produced by this patch when you have time. panic: /usr/src/sys/netinet6/nd6_nbr.c:1665: nd6_queue_rel: Bad link elm 0xfffff80028a00900 prev->next != elm cpuid = 2 time = 1773444926 KDB: stack backtrace: #0 0xffffffff80bed6cd at kdb_backtrace+0x5d #1 0xffffffff80b9c2fe at vpanic+0x16e #2 0xffffffff80b9c183 at panic+0x43 #3 0xffffffff80df90cc at nd6_queue_rel+0xdc #4 0xffffffff80bb9e8b at softclock_call_cc+0x19b #5 0xffffffff80bbb51d at softclock_thread+0xed #6 0xffffffff80b4cce2 at fork_exit+0x82 #7 0xffffffff810acd7e at fork_trampoline+0xe KDB: enter: panic I already tried many ideas like getting the ifp reference and/or updating the ifp/in6_extra based on sdl->sdl_index value using ifnet_byindex.
Comment Actions I also tried to replace the TAILQ with STAILQ to avoid this line: panic: /usr/src/sys/netinet6/nd6_nbr.c:1665: nd6_queue_rel: Bad link elm 0xfffff80028a00900 prev->next != elm But the actual problem is the data is already freed and this is not just a consistency check failure from TAILQ (prev->next != elm). Comment Actions Rebase to D55905. sys/netinet6/proxy_ndp:pndp_add_gu_success -> passed [2.529s] sys/netinet6/proxy_ndp:pndp_del_gu_success -> passed [4.840s] sys/netinet6/proxy_ndp:pndp_ifdestroy_success -> passed [2.899s] sys/netinet6/proxy_ndp:pndp_neighbor_advert -> passed [5.192s] Comment Actions Code wise looks good to me. But I'm not protocol expert.
| ||||||||||||||||||||