Re: [Pengfork-devel] ANNOUNCE: pengfork working

[Jean-Charles Salzeber]

On Thu, Sep 12, 2002 at 18:01, Nicolas Burrus wrote:
> On Thursday 12 September 2002 17:17, Jean-Charles Salzeber wrote:
> 
> > The problem seems located somewhere in the tun interface because some IP
> > packets are cut/broken and I don't see an easy mean to be sure we have a
> > good IP packet to send, I could explain a bit more if you wish.
> 
> Yes, I'd like to have more explanations :)
> 

OK

Normally the input buffer of the tun interface contains raw IP packets.
I take them packet by packet to transmit them into the tunnel.
So normally, the start of the buffer is always the start of an IP
packet.

What it seems to happen when the message "engine - an input buffer is
full" appears that the start of the buffer is not an IP packet. So
because I wait for the packet to be entire and the IP length field point
to arbitrary data that could be > MTU which is normally not possible.

This happens only when you explicitly flood the interface with packets
(like a 'ping -f www.microsoft.com' command) or when you send many
packets doing an upload (or CVS commit for example).

So I believe, that when the interface receive more data that the client
read, some data is lost and especially IP header. I could be wrong since
pengaol use the tun interface without such problem, but it use
synchronous read/write with a multi-threaded design, pengfork use
asynchronous read/write with a multiplexing design, so there may be a
difference.

It could also simply be some memory overwriten by something, but I don't
believe it.

I hope to be clear enough.

JC

PS: It seems that pengfork is also less CPU intensive than pengaol (it
have never overflowed 0.3%, pengaol can reach 10.0% on my Pentium 200
computer)

pgpyJAHhEg4WM.pgp
Description: PGP signature