Re: new frame generation in user-defined target

>
>
>> Hi,
>
> >
> > I"m trying to create a new user-defined target for ebtables, which 
> would
> > process incoming frames and insert some management frames into a packet
> > flow, and I"d like to know if it would be possible to create a new 
> sk_buff
> > and append it to the current socket buffer list (using skb_append(), 
> e.g.)
> > in the same target code. Would the kernel handle it correctly?
>
> I think you can do this in a similar way as the ip defragmenting code 
> works. Your IP fragments will then be defragmented before sent out of 
> the bridge (if connection tracking is in the kernel).
>
> I don"t know all the details, but have a look at 
> net/ipv4/ip_fragment.c:ip_defrag() for clues.
>
The problem is that I'm not briding IP-only traffic. I'm trying to do a 
network layer independent encrypting target module, something similar to 
that proposed by Rene Bartsch 
(http://sourceforge.net/mailarchive/forum.php?thread_id=5646788&forum_id=8572), 
so that the incoming traffic is ciphered and bridged. I'm now dealing 
with the problem of the MTU limitation when adding new fields, and I 
think (please correct me if I'm wrong) that having the chance to insert 
new independent frames would allow both fragmentation and the insertion 
of management frames whenever it's needed. I've tried to do this by 
inserting a new sk_buff in the list by means of the skb_append() 
function, as well as updating the prev, next and list pointers directly, 
but the kernel always crashes. It seems that the code expects just one 
sk_buff to be sent where two of them are being sent. Did you refer to 
this fact when you said that the Ethernet protocol does not allow 
fragmentation?

Anyway, I'd like to avoid fragmentation by modifying the MTU of the 
network device drivers, so that the upper layers would only be allowed 
to send 14xx length frames and I'd have free space enough to insert 
those extra fields in the encrypting module code. However, I really 
don't know if this is possible, since the driver would probably drop 
these frames as well.

Any ideas?

> If you alter the packet, you need to check (skb_shared(*pskb) || 
> skb_cloned(*pskb)), see e.g. ebt_redirect.c.
>
I'll take it into account. Thanks a lot.

> cheers,
> Bart
>
>
Kind regards,

Aitor


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/