>>>>> "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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:19 EST