Messages in this thread | | | Subject | Re: network encryption | From | Henner Eisen <> | Date | 11 Mar 2000 10:09:05 +0100 |
| |
>>>>> "Brian" == Brian 'brian' Medley <bmedley@engr.uark.edu> writes:
:
Brian> This encryption takes place in a modified hard_start_xmit. Brian> In our modified function the data field is encrypted and Brian> then the original hard_start_xmit is called. We have it Brian> working with a simple XOR encryption, but this is kind of Brian> silly.
Brian> We have run into a problem when the useful encryption Brian> routines increase the size of the data field in the sk_buff Brian> beyond the maximum allowed packet size. (BTW, what does sk Brian> stand for?) There are two methods we can think of to Brian> handle this: Brian> a) Limit the size of any sk_buffs created. Brian> b) Split the sk_buffs up.
Brian> We don't know which method would be the best choice or even Brian> where to start looking. How can we limit the sk_buff size? Brian> Any help would be appreciated. Also, any tips on splitting Brian> the sk_buffs up would be helpful.
If you do it inside the network device driver, you need to copy the sk_buffs anyway because network device drivers are not allowed to modify sk_buff contents beyond (and incuding) skb->nh.* (otherwise, you will break stuff like tcp retransmission). Just allocate the target skbuffs large enough or allocate several of them before copying. You can limit the size of the sk_buffs passed to your driver by resetting dev->mtu to a lower value.
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |