Embedded server error when Slow ppp (GPRS) connection - PPP

This is a discussion on Embedded server error when Slow ppp (GPRS) connection - PPP ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Embedded server error when Slow ppp (GPRS) connection

  1. Embedded server error when Slow ppp (GPRS) connection

    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 776382 382406>

    (OK)
    IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1152: . ack 1
    win 6432

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

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

    (OK)
    IP dsl.dynamic859919066.ttnet.net.tr.1153 > 195.87.247.5.www: . ack 1
    win 5840

    (OK)
    IP dsl.dynamic859919066.ttnet.net.tr.1153 > 195.87.247.5.www: P
    1:465(464) ack 1 win 5840

    (OK)
    IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: . ack 465
    win 6432

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

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

    TCP output2
    ------------
    (OK)
    10.0.0.3.1152 > 195.87.247.5.www: F 3094563404:3094563404(0) ack
    4008285051 win 5840 (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
    (DF)

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

    (OK)
    195.87.247.5.www > 10.0.0.3.1153: S 4103029585:4103029585(0) ack
    3187455611 win 5792 0> (DF) [tos 0x88]

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

    (OK)
    10.0.0.3.1153 > 195.87.247.5.www: P 1:465(464) ack 1 win 5840
    (DF)

    (OK)
    195.87.247.5.www > 10.0.0.3.1153: . ack 465 win 6432 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


  2. Re: Embedded server error when Slow ppp (GPRS) connection

    "chocolate" writes:
    > (LOST PAGE PACKAGE 1)
    > IP 195.87.247.5.www > dsl.dynamic859919066.ttnet.net.tr.1153: .
    > 1:1421(1420) ack 465 win 6432


    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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread