[EMAIL PROTECTED] wrote:
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).
You are using a different meaning of "long term" than I am.
We do need to refactor the IP datapaths to make them simpler and get rid
of a few thousands of lines of duplicate code.
I'm well aware of CR 6391685 (I need to get a short-term fix for it into
Nevada ASAP) but to me that doesn't factor into how to handle ndp_resolver.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
