Embedded server error when Slow ppp (GPRS) connection

[chocolate]

Hi,

I have a project related with embedded linux server system via GPRS.

There is no error when a client requests a page (index.htm) from
embedded board.

Client(OK) -> Internet(OK) -> GSM Network(OK) -> GPRS Modem(OK) ->
Embedded Board(OK)

Also embedded board try to sending a page (index.htm) to the client.
But Client can not get the page.

Embedded Board(TCP output1) -> GPRS Modem -> GSM Network -> Internet ->
Client(TCP output2)


TCP output1
------------
(OK, requested index.htm page from 195.87.247.5)
IP dsl.dynamic859919066.ttnet.net.tr.1152 > 195.87.247.5.www: F
3094563404:3094563404(0) ack 4008285051 win 5840 <nop,nop,timestamp
776382 382406>

(OK)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1152: . ack 1
win 6432 <nop,nop,timestamp 392607 776382>

(OK)
IP dsl.dynamic859919066.ttnet.net.tr.1153 > 195.87.247.5.www: S
3187455610:3187455610(0) win 5840 <mss 1432,sackOK,timestamp
776400[|tcp]>

(OK)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: S
4103029585:4103029585(0) ack 3187455611 win 5792 <mss
1460,sackOK,timestamp 392614[|tcp]>

(OK)
IP dsl.dynamic859919066.ttnet.net.tr.1153 > 195.87.247.5.www: . ack 1
win 5840 <nop,nop,timestamp 776695 392614>

(OK)
IP dsl.dynamic859919066.ttnet.net.tr.1153 > 195.87.247.5.www: P
1:465(464) ack 1 win 5840 <nop,nop,timestamp 776695 392614>

(OK)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: . ack 465
win 6432 <nop,nop,timestamp 392835 776695>

(LOST PAGE PACKAGE 1)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: .
1:1421(1420) ack 465 win 6432 <nop,nop,timestamp 392835 776695>

(LOST PAGE PACKAGE 2)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: .
1421:2841(1420) ack 465 win 6432 <nop,nop,timestamp 392835 776695>

TCP output2
------------
(OK)
10.0.0.3.1152 > 195.87.247.5.www: F 3094563404:3094563404(0) ack
4008285051 win 5840 <nop,nop,timestamp 776382 382406> (DF)

(OK)
10.0.0.3.1028 > 10.0.0.2.domain: 14217+ PTR?
5.247.87.195.in-addr.arpa. (43) (DF)

(OK)
10.0.0.3.1153 > 195.87.247.5.www: S 3187455610:3187455610(0) win 5840
<mss 1460,sackOK,timestamp 776400 0,nop,wscale 0> (DF)

(OK)
195.87.247.5.www > 10.0.0.3.1152: . ack 1 win 6432 <nop,nop,timestamp
392607 776382> (DF) [tos 0x88]

(OK)
195.87.247.5.www > 10.0.0.3.1153: S 4103029585:4103029585(0) ack
3187455611 win 5792 <mss 1000,sackOK,timestamp 392614 776400,nop,wscale
0> (DF) [tos 0x88]

(OK)
10.0.0.3.1153 > 195.87.247.5.www: . ack 1 win 5840 <nop,nop,timestamp
776695 392614> (DF)

(OK)
10.0.0.3.1153 > 195.87.247.5.www: P 1:465(464) ack 1 win 5840
<nop,nop,timestamp 776695 392614> (DF)

(OK)
195.87.247.5.www > 10.0.0.3.1153: . ack 465 win 6432 <nop,nop,timestamp
392835 776695> (DF) [tos 0x88]

(NO PAGE PACKAGE 1)

(NO PAGE PACKAGE 2)



So client can not see the page because of lost page package 1 and 2
Although it should be sended according to TCP output1.

In my opinion this problem occures from slow ppp(gprs) connection.
Although at report output1 seems sended, there is an uplink bottleneck
problem at embedded board.

Could you please assist me for getting rid of this problem?

Best Regards,
MK

[James Carlson]

Post by chocolate
(LOST PAGE PACKAGE 1)
IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: .
1:1421(1420) ack 465 win 6432 <nop,nop,timestamp 392835 776695>

The first packet lost is also the largest packet you're sending. That
implies either serial flow control misconfiguration (or bugs), or an
MTU problem somewhere in the path.

If it's possible to get debug information out of that GPRS device,
then do so. You should look to see whether it's seeing CRC/FCS
errors. If it is, then the problem is probably flow control.
Otherwise, it's probably an undiagnosed MTU problem in the path.

Most likely, given the nature of such devices, you won't be able to
get usable debug information. In that case, you'll just have to guess
(and perhaps remember this episode the next time you go to choose a
communications device :-/).

The simplest thing to try would be to drop the MTU downwards. Go down
to 1000 or even 500 octets. Really, low MTUs have little effect on
performance, despite the marketing hype to the contrary. (Going from
1500 all the way down to 500 changes the PPP overhead from about 0.93%
to 1.4%, assuming standard options. Even if you don't have VJ
compression, the worst-case TCP/IP overhead increase is around 5.8%.
It's a pittance. The interrupt load on packet oriented devices -- not
async PPP, but Ethernets -- may be high at very high speeds -- i.e.,
gigabit, not async -- but the overhead on the wire isn't.)

If that doesn't work (or even if it does!), you should look at the
flow control configuration on both ends of the serial link to make
sure it's actually correct, and that the devices you're using
implement flow control properly. You may need an external serial
analyzer to do this.