The reason that ndp_process() makes the incorrect verdict for
packets being forwarded is that it determines whether packets are
externally originated depending on mp->b_prev which is used to store
phyint_ifindex in ip_rput_data_v6(). But when the packet arrives
ndp_process(), the mblk has been prepended an
M_CTL type message by ndp_prepend_zone() to store zoneid. So in
ndp_process() it is mp->b_cont->b_prev which should be examined
instead of mp->b_prev.
What I am not sure about is the resolution.
1) Modifying ndp_process() to get rid of the prepended M_CTL mblk
is the most simple way to fix the
problem, making the packets going through the right path.
2) But since this prepended message and the zone id stored in it
will never be used for packets being forwarded(the zone id will not
be used when doing ire lookup or ip_newroute_v6, they use
"ALL_ZONES" in ip_rput_data_v6), it seems not calling
ndp_prepend_zone() in ndp_resolver() for forwarding packets is
a more reasonable resolution.
3) And one might expect a more complete change, to make the
forwarding packets also make use of the
zone id, just like the locally originated packets do.
Any suggestions?
Doing #2 sounds best as the short-term fix.
Isn't it slightly better to explicitly check for, and skip, M_CTL
(i.e., solution #1)? I believe IPv6 always prepends the M_CTL, and an
explicit check feels like it would be more straight-forward code in the
long term (see also CR 6391685).
IPv6 attaches zoneid very early
(ndp_resolver->ndp_prepend_zone->nce_solicit). But the zoneid
would be used only for locally originated packets in ip_wput_ire[_v6].
So I think it's better to call ndp_prepend_zone at the "locally
originated" section in ire_send_v6 instead. Actually the suggest fix
for CR 6391685 by David did the zoneid attaching for IPv4 at ire_send,
but it didn't move the location of attaching for IPv6.
But for fixing of this bug (CR 6446106), I think whether we are
removing ndp_prepend_zone action for locally originated packets or not,
explicitly check would be safe.
Longer term we want to apply what Surya did to IPv4 forwarding to IPv4
origination and and IPv6, which would mean that when the packet is
queued for ARP/NDP resolution, the rest of IP is done with everything we
need to do and all that remains is filling in the L2 header.
That way when resultion is complete we'd always go to ip_xmit_v* and the
code will be much simpler.
That would really make life easier. In pfhook project, these kinds of
packet enter ip_input/ip_rput_v6 twice, as well as the inbound firewall
hooks. We had to set some flags in the mblk to avoid the re-entering.
Yifan
|
_______________________________________________
networking-discuss mailing list
[email protected]
