Dan McDonald wrote:
On Tue, Apr 11, 2006 at 10:21:09AM -0700, Sangeeta Misra wrote:
Dan McDonald wrote:
RESP: CLARIFY
Are you referring to the follwoing comment in
ip_rput_process_notdata():
/* Copy b_next - used in M_BREAK messages */
on parent ws's ip.c (L12996)?
No, but that *is* related.
Which line in specific were you commenting to
In the old code: Lines 13246 and 13262
In the new code: Lines 13509 and 13525 - You still do b_next, but don't
mention WHY!
I got the M_BREAK cleanup ( justification and the code cleanup) checked
out by THiru, but yet we will test this as you point out above.
You may be able to get rid of the b_next massaging too. If you can't, please
restate why you need to massage b_next in ip_rput().
Yes. We should get rid of the b_next assigmentas well.
Also you state:
--------
This part of the block comment:
* M_BREAK are also used to pass back in multicast packets
* that are encapsulated with a source route.
Bothers me *just* enough so that we should probably make sure we aren't
hitting this codepath. A simple test:
ping -g <Surya-router-1> -g <Surya-router-2> 224.0.0.1
Would check if you get an M_BREAK on your Surya box. Assuming that's
kosher,you're in good shape.
----------
Can you explain how the above ping command would trigger the M_BREAK
logic? Also I plan to run this with onnv first to see if it works there.
What should surya-router-1/Surya-router-2 config be? Should it be
running as multicast routers ( ie mrouted daemon). I hope this does not
require multicast tunnels, as that is already broken in onnv( I filed a
bug against this).
Sangeeta
_______________________________________________
networking-discuss mailing list
[email protected]
