lkml.org 
[lkml]   [2000]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: network encryption
From
Date
>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.983 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site