Re: Re: new frame generation in user-defined target

On Monday 13 December 2004 14:30, aitor wrote:
> 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=85
>72), 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?

No, I just meant that in the general case where the packet length already is 
the MTU, encryption in ebtables is impossible (unless you invent an 
encapsulating Ethernet protocol that implements an identification field and 
fragment offset, or something like that).

> 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.

You would then have to change the MTU of the network devices of every host on 
the network on one side of the bridge, that wants to pass the bridge. I did 
not think this is a viable option, which is why I gave the answer about 
fragmentation. The network on one side of your bridge would then be using 
encrypted data and the hosts on that side must have the default MTU, while 
the other side's hosts must use a smaller MTU size.
This all sounds somewhat complicated and I do not see why it's not possible 
and easier to just adjust the hosts on the network so they all send encrypted 
data.


What you can also do to add stuff to the skb is create a new skb and first 
copy the original one to the new skb, analogous to what ebt_redirect does 
(you'll need to use another function than skb_copy()). Of course kfree_skb 
the original skb. The POSTROUTING chain sounds like a nice place to do this.

cheers,
Bart



-------------------------------------------------------
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/