From: James Ketrenos <jketreno@linux.jf.intel.com>
To: Netdev <netdev@oss.sgi.com>
Subject: Limiting frame re-encryption with TCP retries...
Date: Fri, 09 Jul 2004 16:44:14 -0500 [thread overview]
Message-ID: <40EF11AE.9020008@linux.jf.intel.com> (raw)
The recent 'pskb change in dst-output' thread reminded me that I've been meaning
to ask about this...
With wireless drivers TCP retransmission occur pretty frequently. With WEP,
etc. this means the driver has to re-encrypt the same frame with each retry.
In one of the snapshots for ipw2100 I was encrypting over the SKB provided from
the kernel via the xmit and putting new data at the head and tail (to hold the
IV and ICV). Anyway, that broke all sorts of tools (ip_conntrack, netfilter, etc.)
So now I allocate a new SKB on reception of an SKB from the networking stack and
encrypt the copy. The question I have -- is there a way to attach the new SKB
to the old one such that if the transmit is retried I can check that data and
don't have to re-encrypt it?
From the sk_buff.h description of the cb field, I only get to use that data
while I control the SKB. Even if this weren't the case it wouldn't quite do
what I need. Ideally I want to be able to attach the encrypted SKB to the
original SKB such that when the network stack gets the ACK it can nuke the
original SKB and the encrypted one and the driver doesn't have to know.
This gets complicated further when 802.11 level fragmentation is required -- and
one incoming SKB results in N outbound 802.11 fragments, each encrypted separately.
Any ideas? I'm not too familiar with the internals of the kernel's network
stack so if there is something obvious that I should have seen already, please
point it out to me :)
Thanks,
James
reply other threads:[~2004-07-09 21:44 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40EF11AE.9020008@linux.jf.intel.com \
--to=jketreno@linux.jf.intel.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).