"yueyue papa" <[email protected]> wrote:
windows server: 192.168.8.94
GPRS module(TCP/IP): 117.136.8.162
The captured log is not using lwIP. It is GPRS module inner TCP/IP.
Please supply a capture when using LWIP, so we can see the problem.
Kieran - a little background may help to clarify matters.
The WaveCOM GPRS modem has an internal TCP/IP stack.. It can be configured
to use this with a simple serial data connection to the host (behaving
similarly to a dialup modem). In this mode of operation it can only support
a single TCP connection.
An alternative mode of operation involves the host running a TCP/IP stack
and communicating with the modem via PPP. This allows much greater
flexibility, e.g. you can have multiple TCP connections active at once.
The previous capture that yueyue papa supplied did not involve LWIP at all -
it was the modem's internal TCP/IP stack (which wasn't clear until now).
Therefore any speculation on LWIP configuration or timing was not relevant.
I think the observed strange timing can be almost entirely explained by GPRS
behaviour. GPRS typically operates at 19200 bps, so a 1500 byte packet will
take in the order of 750 ms to transmit. This accounts for some of the
observed delays in the capture.
GPRS can sometimes introduce random delays in the order of a few seconds.
I've observed five second delays and some cellular networks might be slower.
Packets are not lost during these delays - they are buffered and then
delivered later.
The previous capture appeared to have one or two of these long delays for
roughly 30 seconds after the SYN/ACK sequence, during which time the GPRS
modem sent several packets and timed out waiting for the first ACK, causing
it to retransmit. The GPRS network delay was cleared about the same time as
the retransmissions, and most of the subsequent traffic looks reasonably
normal.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
