> Indeed, and this previously worked. By design, mac_pdata_update()
> issues a MAC_NOTE_FASTPATH_FLUSH notification. The dld module's
> str_notify() callback receives this notification and calls
> str_notify_fastpath_flush(), which in turn issues a
> DL_NOTE_FASTPATH_FLUSH DL_NOTIFY_IND DLPI message to interested client
> streams, including IP streams. The ip module processes such DLPI
> notifications and re-initializes its fast-path headers on these streams.
>
> If this is no longer working this way, then something has perturbed this
> code path.
I was asked to look into this issue about a month ago; the preliminary
issues I found are below. I'm not sure if a bug got filed on this.
1. The mac_pdata_update() should eventually lead to a
DL_NOTE_FASTPATH_FLUSH message being sent to IP. This in turn causes
IP to remove its old fastpath headers. Crossbow (in build 106)
changed these codepaths extensively and it's possible this no longer
works in some cases. So please check if IP is getting the
DL_NOTE_FASTPATH_FLUSH in the problematic case.
2. The reason why doing the `down' works is that it cases IP to remove
its fastpath headers. Up until the integration of Clearview IPMP (in
build 107), doing a "ifconfig <if> dhcp release" will both send the
DHCP release *and* bring the address down, which would cover up any
problem with the DL_NOTE_FASTPATH_FLUSH mechanism mentioned above.
As of build 107, it just resets the IP address to 0.0.0.0 and does not
bring the address down. So even if the DL_NOTE_FASTPATH_FLUSH
mechanism was broken, we wouldn't have noticed until build 107.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
