As I understand the code, ciped only exists to keep the bring up/down &
configure the cipcbX interface. I had thought all traffic and encryption
handling happens in the kernel. I agree, if this can happen in userland,
all the better; but I know know if it will be possible.
What do you mean by "...we can have a bit in P..." below? I've not heard
On Fri, 30 Nov 2001, Josef Drexler wrote:
> On Fri, 30 Nov 2001 ewheeler,AT,kaico,DOT,com wrote:
> > Josef --
> > I would help with this porject! I have part of this implemented
> > already, and zlib working within the kernel (i know, zlib is kinda
> > bloated). See this: http://xeon.eboch.com/cipe/output.c
> Yeah, just after sending my message I noticed yours in the archives.
> > I've added a cipe_compress function which only compresses outgoing
> > packets, but I can't figure out where to put the code to decompress the
> > incoming packet!
> I must admit that I'm still somewhat confused about how cipe works in
> between ciped and the module, but I think a cleaner way would be to hook
> into cipe_encrypt and cipe_decrypt in encaps.c, and decide there whether
> to compress based on the packet size. The advantage here is that both
> functions are already built with a change in length in mind, so that the
> change due to compression/decompression can hopefullt be handled in a very
> transparent way.
> I'll have to see whether that means compression would only occur if
> encryption is turned on though. Also if at all possible it would be
> better to do the compression in the user-space program and not the module.
> But I think before we really start with this we should have some input
> from Olaf Titz on whether we can have a bit in P and how to negotiate the
> use of compression among the two ends of the tunnel.
> [Oh and the last column of the statistics I posted is wrong, typo in my
> Perl code... should be zero everywhere except the last row.]
20417 SW 70th Ave.
Tualatin, OR 97062