divert and deadlock issues

[Julian Elischer]

Christian S.J. Peron wrote:
> On Tue, Jul 31, 2007 at 04:22:41PM -0700, Julian Elischer wrote:
> [..]
>> Originally we wanted a way to be able to inject any kind of 
>> ip packet that could be generated, because the aim was to 
>> allow a user agent to do arbitrary processing on packets. however
>> to be really correct, a divert injection should occur at teh position of 
>> the firewall
>> where diversion occurs but there is no way to do that and anyhow they need
>> to get some of the internal state added to them before they get there, so 
>> puting them in via ip_output seemed the way to go.
>>
>> I've never had much to do with multicast, so I'm not sure if it makes sense
>> to inject there, but if you wanted to divert multicast packets
>> and change them slightly, and then reinject them, it would be a blow 
>> to discover that you couldn't.
> 
> Well, it's still the intent to keep the ability to divert and re-inject
> multicast packets.  This change would basically say: "You cant specify
> multicast options via the divert socket". Which in practice doesn't
> happen anyway (where I looked).
> 
> I dont think we should be specifying multicast options on divert sockets.
> It's not the right place to be manipulating multicast parameters.  Multicast
> parameters should be set on the sockets that originally transmitted or
> received the packets.  I dont think divert falls into this category.
> 
ok

if you can divert out a multicast packet, fix something in it, 
and then reinject it, and have it DTRT then that's fine.