lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] PPP bug related to VJ


From: tbutler
Subject: Re: [lwip-users] PPP bug related to VJ
Date: Mon, 2 Jan 2006 09:24:12 +0100




Jan,

I ran into this problem as well, and my solution was similar to yours. In
function pppifOutput() I make a copy of the first pbuf before calling
vj_compress_tcp(). This avoids changes to the compression code in vj.c.
Furthermore, to minimize the changes to pppifOutput(), I introduce a second
pbuf into the chain when compression occurs, in order skip the original
header in the original pbuf. The rest of the function then operates on this
chain without change. As the original pbuf chain held by TCP is not
changed, I don't bother restoring anything.

While I'm at it, I'll mention one other VJ problem I found. If you happen
to reutilize your PPP context across various connections, the VJ code does
correctly reset all of its context at the beginning each connection. For
some reason, the function vj_compress_init(), has an #ifdef MAX_SLOTS == 0
around the memset() which clears the context. In my view, this #ifdef is
unnecessary so I removed it, which solved a problem of sometimes
incorrectly compressing packets at the beginning of a new connection.

Regards,
Tim Butler






"Jan Ulvesten" <address@hidden>@nongnu.org con fecha 23/12/2005
18:51:55

Por favor, responda a Mailing list for lwIP users <address@hidden>

Enviado por:      address@hidden


Destinatarios:    <address@hidden>
CC:
Asunto:     [lwip-users] PPP bug related to VJ




Hi



It appears to be a problem related to VJ header compression in PPP?



The TCP unsent/unackedqueue is assumed to be uncompressed at the transport
layer, but vj_compress_tcp()  called from pppifOutput() works directly on
the TCP payload which includes the segments tcp-header (seg->tcp_hdr).
This isn’t a problem as long as the segment isn’t retransmitted.



A TCP retransmission causes undefined behavior, in my test setup I observed
that absolutely all TCP flags were set in a transmitted frame. The
connection was off course closed. In other tests I’ve seen that the TCP
checksum have been modified.



Another issue that I’ve seen is that the VJ compression does not implement
the alignment rules. The payload pointer of pbmay be odd after the call to
vj_compress_tcp()



Since VJ reduces the header size from 40 bytes (IP+TCP) to around 8 bytes I
would really like to use VJ, especially when using PPP on low bitrates.



I’m not sure how to solve this. For now I just make a copy of the first
pbufin the chain (assuming that this pbufcontains both TCP and IP header)
and then restoresthe original pbufafter the compressed buffer has been
used.



Anyone who has the same experience?



Jan Ulvesten



Senior Software Engineer
SICOM  AS
_______________________________________________
lwip-users mailing list
 address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

[Prev in Thread] Current Thread [Next in Thread]