gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2 - PPP

This is a discussion on gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2 - PPP ; I have an application for GPRS in linux that works with just about any phone Ive tried, except for the Ericsson T39 (and other Ericssons based on the T39, like the F251). The connection seems to succeed every time, but ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

  1. gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    I have an application for GPRS in linux that works with just about any
    phone Ive tried, except for the Ericsson T39 (and other Ericssons based
    on the T39, like the F251).

    The connection seems to succeed every time, but 8 out of 10 times, no
    data flows. (or, more accurately, I can send to the phone, but nothing
    flows from the phone to the network, from the network to the phone, or
    from the phone to the serial port.) Ive tried with a few different
    networks.

    If I use a 2.4 kernel I can solve the problem by adding
    options ppp_async flag_time=0
    to /etc/modules.conf, and it works every time. But this doesn't seem to
    work in 2.6 kernels (and I can't change the kernel -- this app is going
    on lots of existing machines!).

    Can anyone tell me if and how the flag_time in ppp_async can be set in
    2.6.9?

    Config files, and logs from successful and unsuccessful connections,
    follow.

    Thanks for your time,

    Julian


    # pppd file /etc/ppp.conf

    # cat /etc/ppp.conf
    /dev/ttyS0
    ipparam gprs
    57600
    crtscts #this doesn't seem to make a difference
    modem
    lock
    receive-all
    nopcomp
    noaccomp
    nomagic
    noccp
    novj
    novjccomp
    noipdefault
    ipcp-accept-local
    ipcp-accept-remote
    defaultroute
    usepeerdns
    user web
    connect '/usr/sbin/chat -e -S -f /etc/chat_connect -v'
    disconnect '/usr/sbin/chat -e -S -f /etc/chat_disconnect -v'

    # cat /etc/chat_connect
    ABORT 'BUSY'
    ABORT 'NO ANSWER'
    ABORT 'NO CARRIER'
    ABORT 'NO DIALTONE'
    ABORT 'NO DIAL TONE'
    ABORT 'VOICE'
    ABORT 'ERROR'
    '' AT
    TIMEOUT 10
    OK ATE0
    OK ATV1
    OK 'AT+CGDCONT=4,"IP","internet"'
    OK AT+CGQREQ=4,0,0,0,0,0
    OK AT+CGQMIN=4,0,0,0,0,0
    OK ATDT*99***4#
    TIMEOUT 22
    CONNECT ""

    # cat /etc/chat_disconnect
    "" "\K"
    "" "+++ATH"
    "" "+++ATH"
    "" "+++ATH"

    Here is a SUCCESSFUL connection
    ------------------------------
    May 29 11:19:51 [pppd] pppd 2.4.2 started by root, uid 0
    May 29 11:19:55 [pppd] Serial connection established.
    May 29 11:19:55 [pppd] using channel 3
    May 29 11:19:55 [pppd] Using interface ppp0
    May 29 11:19:55 [pppd] Connect: ppp0 <--> /dev/ttyS0
    May 29 11:19:56 [pppd] sent [LCP ConfReq id=0x1 ]
    May 29 11:19:56 [pppd] rcvd [LCP ConfReq id=0x1
    ]
    May 29 11:19:56 [pppd] sent [LCP ConfRej id=0x1 ]
    May 29 11:19:56 [pppd] rcvd [LCP ConfAck id=0x1 ]
    May 29 11:19:56 [pppd] rcvd [LCP ConfReq id=0x2 pap>]
    May 29 11:19:56 [pppd] sent [LCP ConfAck id=0x2 pap>]
    May 29 11:19:56 [pppd] sent [PAP AuthReq id=0x1 user="web"
    password=]
    May 29 11:19:59 [pppd] sent [PAP AuthReq id=0x2 user="web"
    password=]
    May 29 11:19:59 [pppd] rcvd [PAP AuthAck id=0x2 ""]
    May 29 11:19:59 [pppd] PAP authentication succeeded
    May 29 11:19:59 [pppd] sent [IPCP ConfReq id=0x1
    ]
    May 29 11:20:02 [pppd] sent [IPCP ConfReq id=0x1
    ]
    May 29 11:20:03 [pppd] rcvd [IPCP ConfReq id=0x1 ]
    May 29 11:20:03 [pppd] sent [IPCP ConfAck id=0x1 ]
    May 29 11:20:03 [pppd] rcvd [IPCP ConfNak id=0x1
    ]
    May 29 11:20:03 [pppd] sent [IPCP ConfReq id=0x2
    ]
    - Last output repeated twice -
    May 29 11:20:06 [pppd] rcvd [IPCP ConfAck id=0x2
    ]
    May 29 11:20:06 [pppd] not replacing existing default route to eth0
    [192.168.1.2]
    May 29 11:20:06 [pppd] local IP address 10.164.11.70
    May 29 11:20:06 [pppd] remote IP address 10.164.255.254
    May 29 11:20:06 [pppd] primary DNS address 172.29.129.11
    May 29 11:20:06 [pppd] secondary DNS address 172.29.129.11
    May 29 11:20:06 [pppd] Script /etc/ppp/ip-up started (pid 2681)
    May 29 11:20:06 [pppd] Script /etc/ppp/ip-up finished (pid 2681),
    status = 0x1
    May 29 11:21:21 [pppd] Terminating on signal 15.
    May 29 11:21:21 [pppd] Script /etc/ppp/ip-down started (pid 4164)
    May 29 11:21:21 [pppd] sent [LCP TermReq id=0x2 "User request"]
    May 29 11:21:21 [pppd] rcvd [LCP TermAck id=0x2]
    May 29 11:21:21 [pppd] Connection terminated.
    May 29 11:21:21 [pppd] Connect time 1.5 minutes.
    May 29 11:21:21 [pppd] Sent 15132 bytes, received 3557 bytes.
    May 29 11:21:21 [pppd] Serial link disconnected.
    May 29 11:21:22 [pppd] Waiting for 1 child processes...
    May 29 11:21:22 [pppd] script /etc/ppp/ip-down, pid 4164
    May 29 11:21:22 [pppd] Script /etc/ppp/ip-down finished (pid 4164),
    status = 0x1
    May 29 11:21:22 [pppd] Exit.



    and here is an UNSUCCESSFUL connection
    --------------------------------------
    May 29 11:22:20 [pppd] pppd 2.4.2 started by root, uid 0
    May 29 11:22:24 [pppd] Serial connection established.
    May 29 11:22:24 [pppd] using channel 4
    May 29 11:22:24 [pppd] Using interface ppp0
    May 29 11:22:24 [pppd] Connect: ppp0 <--> /dev/ttyS0
    May 29 11:22:25 [pppd] sent [LCP ConfReq id=0x1 ]
    May 29 11:22:25 [pppd] rcvd [LCP ConfReq id=0x1
    ]
    May 29 11:22:25 [pppd] sent [LCP ConfRej id=0x1 ]
    May 29 11:22:25 [pppd] rcvd [LCP ConfAck id=0x1 ]
    May 29 11:22:25 [pppd] rcvd [LCP ConfReq id=0x2 pap>]
    May 29 11:22:25 [pppd] sent [LCP ConfAck id=0x2 pap>]
    May 29 11:22:25 [pppd] sent [PAP AuthReq id=0x1 user="web"
    password=]
    May 29 11:22:28 [pppd] sent [PAP AuthReq id=0x2 user="web"
    password=]
    May 29 11:22:28 [pppd] rcvd [PAP AuthAck id=0x2 ""]
    May 29 11:22:28 [pppd] PAP authentication succeeded
    May 29 11:22:28 [pppd] sent [IPCP ConfReq id=0x1
    ]
    - Last output repeated twice -
    May 29 11:22:32 [pppd] rcvd [IPCP ConfReq id=0x1 ]
    May 29 11:22:32 [pppd] sent [IPCP ConfAck id=0x1 ]
    May 29 11:22:32 [pppd] rcvd [IPCP ConfNak id=0x1
    ]
    May 29 11:22:32 [pppd] sent [IPCP ConfReq id=0x2
    ]
    May 29 11:22:32 [pppd] rcvd [IPCP ConfAck id=0x2
    ]
    May 29 11:22:32 [pppd] local IP address 10.164.6.237
    May 29 11:22:32 [pppd] remote IP address 10.164.255.254
    May 29 11:22:32 [pppd] primary DNS address 172.29.129.11
    May 29 11:22:32 [pppd] secondary DNS address 172.29.129.11
    May 29 11:22:32 [pppd] Script /etc/ppp/ip-up started (pid 5527)
    May 29 11:22:32 [pppd] Script /etc/ppp/ip-up finished (pid 5527),
    status = 0x1
    May 29 11:24:07 [pppd] Terminating on signal 15.
    May 29 11:24:07 [pppd] Script /etc/ppp/ip-down started (pid 7463)
    May 29 11:24:07 [pppd] sent [LCP TermReq id=0x2 "User request"]
    May 29 11:24:07 [pppd] Script /etc/ppp/ip-down finished (pid 7463),
    status = 0x1
    May 29 11:24:07 [pppd] rcvd [LCP TermAck id=0x2]
    May 29 11:24:07 [pppd] Connection terminated.
    May 29 11:24:07 [pppd] Connect time 1.8 minutes.
    May 29 11:24:07 [pppd] Sent 12758 bytes, received 54 bytes.
    May 29 11:24:08 [pppd] Serial link disconnected.
    May 29 11:24:09 [pppd] Exit.


    # uname -a
    Linux tang 2.6.9 #2 SMP Tue Nov 16 14:01:25 GMT 2004 i686 VIA Samuel 2
    CentaurHauls GNU/Linux

    Motherboards are mostly EPIA-M rev B


  2. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    In article <1117559449.601972.173000@f14g2000cwb.googlegroups. com>,
    julian@bigpip.com wrote:
    > If I use a 2.4 kernel I can solve the problem by adding
    > options ppp_async flag_time=0
    > to /etc/modules.conf, and it works every time. But this doesn't seem to
    > work in 2.6 kernels (and I can't change the kernel -- this app is going
    > on lots of existing machines!).
    >
    > Can anyone tell me if and how the flag_time in ppp_async can be set in
    > 2.6.9?


    The code handling flag_time option has not changed between 2.4 and 2.6
    kernels:

    http://lxr.linux.no/diff/drivers/net...diffval=2.6.11

    modprobe on the other hand uses different configuration files with 2.6
    kernels. Perhaps putting the "options ppp_async flag_time=0" line to
    /etc/modprobe.conf could solve this, man modprobe for details.

    If I remember correctly, the serial link with t39 did not work at all
    without the flag_time option. It might not be the problem here, since
    the ppp negotiations seem successful.

    I think that t39 also required powercycling every now and then,
    especially with Bluetooth - hope you have a way of achieving that via
    some software controlled switch

    -Mikko

  3. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    Thanks for your helpful comments. Another barrage of questions:

    Mikko Rapeli wrote:
    > The code handling flag_time option has not changed between 2.4 and 2.6
    > kernels:
    >
    > http://lxr.linux.no/diff/drivers/net...diffval=2.6.11


    Im not a c programmer, but does this line in the 2.6.11 ppp_async.c
    module_param(flag_time, int, 0);
    which replaces this one in the 2.4 version
    MODULE_PARM(flag_time, "i");
    not set the flag_time to zero?

    But I think you might be right that this is a red herring in my
    particular case -- I made this change in ppp_async.c in my 2.6.9
    kernel, recompiled the modules, and tried it out, and it made no
    difference. I also tried the 2.6.11 kernel and modules, with the same
    (lack of) result.

    However, the fact that on another machine running 2.4.25 it works
    reliably (as reliably as gprs gets) only if I set the flag_time=0
    option does not seem consistent with the behaviour in 2.6. If I take
    out this option, the 2.4 machine behaves the same way the 2.6 machine
    behaves all the time: intermittent lack of data despite reported
    connection success.

    The phones work 100% in windows xp -- any idea why?

    > modprobe on the other hand uses different configuration files with 2.6
    > kernels. Perhaps putting the "options ppp_async flag_time=0" line to
    > /etc/modprobe.conf could solve this, man modprobe for details.

    understood. Do you know of a way to check whether this option is in
    fact in effect? Somewhere in /proc perhaps?

    > If I remember correctly, the serial link with t39 did not work at all
    > without the flag_time option. It might not be the problem here, since
    > the ppp negotiations seem successful.

    hmmm, more evidence that this is a red herring...

    > I think that t39 also required powercycling every now and then,
    > especially with Bluetooth - hope you have a way of achieving that via
    > some software controlled switch

    Very interesting. Can you remmeber what the problem was that was fixed
    by the power cycle? Link up but no data, perhaps? Unfortunately, most
    of our servers are connected to Ericsson F251M fixed cellular terminals
    (they are the most common cellular device on ships). It seems the F251
    series have inherited the T39 ppp bug(s). Power cycling means
    disrupting phone calls, and getting someone to re-input the PIN --
    sadly not an option.

    Thanks for your time,
    Julian


  4. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    In article <1117638801.893558.39430@g49g2000cwa.googlegroups.c om>,
    julian@bigpip.com wrote:
    >> http://lxr.linux.no/diff/drivers/net...diffval=2.6.11

    >
    > Im not a c programmer, but does this line in the 2.6.11 ppp_async.c
    > module_param(flag_time, int, 0);
    > which replaces this one in the 2.4 version
    > MODULE_PARM(flag_time, "i");
    > not set the flag_time to zero?


    Ok, I missed that one. Should have taken a real diff.

    > But I think you might be right that this is a red herring in my
    > particular case -- I made this change in ppp_async.c in my 2.6.9
    > kernel, recompiled the modules, and tried it out, and it made no
    > difference. I also tried the 2.6.11 kernel and modules, with the same
    > (lack of) result.
    >
    > However, the fact that on another machine running 2.4.25 it works
    > reliably (as reliably as gprs gets) only if I set the flag_time=0
    > option does not seem consistent with the behaviour in 2.6. If I take
    > out this option, the 2.4 machine behaves the same way the 2.6 machine
    > behaves all the time: intermittent lack of data despite reported
    > connection success.
    >
    > The phones work 100% in windows xp -- any idea why?


    Perhaps this is a performance issue, Linux 2.6 is too fast for the phone.
    When IrDA broke between 2.4.19 and 2.4.22 kernels, the IrDA stack in
    Linux was too fast and standard compliant for the Ericsson phones.
    Slowing it down with max_tx_window=1 and min_tx_turn_time=1000 solved
    it. Since GPRS is slow anyway, using 57600 bps or lower on the cable
    could be a good idea.

    >> modprobe on the other hand uses different configuration files with 2.6
    >> kernels. Perhaps putting the "options ppp_async flag_time=0" line to
    >> /etc/modprobe.conf could solve this, man modprobe for details.

    > understood. Do you know of a way to check whether this option is in
    > fact in effect? Somewhere in /proc perhaps?


    What little I know of this, the effect can only be seen on the RS232
    traffic where some (header?) bits are not optimized out after this
    option is set to zero.

    >> If I remember correctly, the serial link with t39 did not work at all
    >> without the flag_time option. It might not be the problem here, since
    >> the ppp negotiations seem successful.

    > hmmm, more evidence that this is a red herring...
    >
    >> I think that t39 also required powercycling every now and then,
    >> especially with Bluetooth - hope you have a way of achieving that via
    >> some software controlled switch

    > Very interesting. Can you remmeber what the problem was that was fixed
    > by the power cycle? Link up but no data, perhaps? Unfortunately, most


    Just general instability, GPRS dial command hanged for no good reason
    etc. But those could be fixed by now.

    > of our servers are connected to Ericsson F251M fixed cellular terminals
    > (they are the most common cellular device on ships). It seems the F251
    > series have inherited the T39 ppp bug(s). Power cycling means
    > disrupting phone calls, and getting someone to re-input the PIN --
    > sadly not an option.


    The PIN query can be disable with AT commands, perhaps just for a while
    if you need it for security reasons.

    -Mikko

  5. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com wrote:
    > I have an application for GPRS in linux that works with just about any
    > phone Ive tried, except for the Ericsson T39 (and other Ericssons based
    > on the T39, like the F251).


    > The connection seems to succeed every time, but 8 out of 10 times, no
    > data flows. (or, more accurately, I can send to the phone, but nothing
    > flows from the phone to the network, from the network to the phone, or
    > from the phone to the serial port.) Ive tried with a few different
    > networks.


    > If I use a 2.4 kernel I can solve the problem by adding
    > options ppp_async flag_time=0
    > to /etc/modules.conf, and it works every time. But this doesn't seem to
    > work in 2.6 kernels (and I can't change the kernel -- this app is going
    > on lots of existing machines!).


    > Can anyone tell me if and how the flag_time in ppp_async can be set in
    > 2.6.9?


    > Config files, and logs from successful and unsuccessful connections,
    > follow.


    > Thanks for your time,


    > Julian



    > # pppd file /etc/ppp.conf


    > # cat /etc/ppp.conf
    > /dev/ttyS0
    > ipparam gprs
    > 57600
    > crtscts #this doesn't seem to make a difference
    > modem
    > lock
    > receive-all
    > nopcomp
    > noaccomp
    > nomagic
    > noccp
    > novj
    > novjccomp
    > noipdefault
    > ipcp-accept-local
    > ipcp-accept-remote
    > defaultroute
    > usepeerdns
    > user web
    > connect '/usr/sbin/chat -e -S -f /etc/chat_connect -v'
    > disconnect '/usr/sbin/chat -e -S -f /etc/chat_disconnect -v'


    > # cat /etc/chat_connect
    > ABORT 'BUSY'
    > ABORT 'NO ANSWER'
    > ABORT 'NO CARRIER'
    > ABORT 'NO DIALTONE'
    > ABORT 'NO DIAL TONE'
    > ABORT 'VOICE'
    > ABORT 'ERROR'
    > '' AT
    > TIMEOUT 10
    > OK ATE0
    > OK ATV1
    > OK 'AT+CGDCONT=4,"IP","internet"'
    > OK AT+CGQREQ=4,0,0,0,0,0
    > OK AT+CGQMIN=4,0,0,0,0,0
    > OK ATDT*99***4#
    > TIMEOUT 22
    > CONNECT ""


    > # cat /etc/chat_disconnect
    > "" "\K"
    > "" "+++ATH"
    > "" "+++ATH"
    > "" "+++ATH"


    > Here is a SUCCESSFUL connection
    > ------------------------------
    > May 29 11:19:51 [pppd] pppd 2.4.2 started by root, uid 0
    > May 29 11:19:55 [pppd] Serial connection established.
    > May 29 11:19:55 [pppd] using channel 3
    > May 29 11:19:55 [pppd] Using interface ppp0
    > May 29 11:19:55 [pppd] Connect: ppp0 <--> /dev/ttyS0
    > May 29 11:19:56 [pppd] sent [LCP ConfReq id=0x1 ]
    > May 29 11:19:56 [pppd] rcvd [LCP ConfReq id=0x1
    > ]
    > May 29 11:19:56 [pppd] sent [LCP ConfRej id=0x1 ]
    > May 29 11:19:56 [pppd] rcvd [LCP ConfAck id=0x1 ]
    > May 29 11:19:56 [pppd] rcvd [LCP ConfReq id=0x2 > pap>]
    > May 29 11:19:56 [pppd] sent [LCP ConfAck id=0x2 > pap>]
    > May 29 11:19:56 [pppd] sent [PAP AuthReq id=0x1 user="web"
    > password=]
    > May 29 11:19:59 [pppd] sent [PAP AuthReq id=0x2 user="web"
    > password=]
    > May 29 11:19:59 [pppd] rcvd [PAP AuthAck id=0x2 ""]
    > May 29 11:19:59 [pppd] PAP authentication succeeded
    > May 29 11:19:59 [pppd] sent [IPCP ConfReq id=0x1
    > ]
    > May 29 11:20:02 [pppd] sent [IPCP ConfReq id=0x1
    > ]
    > May 29 11:20:03 [pppd] rcvd [IPCP ConfReq id=0x1 ]
    > May 29 11:20:03 [pppd] sent [IPCP ConfAck id=0x1 ]
    > May 29 11:20:03 [pppd] rcvd [IPCP ConfNak id=0x1
    > ]
    > May 29 11:20:03 [pppd] sent [IPCP ConfReq id=0x2
    > ]
    > - Last output repeated twice -
    > May 29 11:20:06 [pppd] rcvd [IPCP ConfAck id=0x2
    > ]


    > May 29 11:20:06 [pppd] not replacing existing default route to eth0
    > [192.168.1.2]


    This sticks out like a sore thumb; it was not present in the pppd log
    messages for the unsuccessful connection. Can someone explain how
    there can be successful connection to the Internet without a default
    route through the PPP interface?

    (I'm not very knowledgeable about Internet connections via a cell-phone
    but just curious. It seems really strange that a successful Internet
    connection doesn't have a default route through the PPP interface while
    an unsuccessful connection apparently does have one.)

    TIA

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  6. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2



    Mikko Rapeli wrote:
    > Perhaps this is a performance issue, Linux 2.6 is too fast for the phone.
    > When IrDA broke between 2.4.19 and 2.4.22 kernels, the IrDA stack in
    > Linux was too fast and standard compliant for the Ericsson phones.
    > Slowing it down with max_tx_window=1 and min_tx_turn_time=1000 solved
    > it. Since GPRS is slow anyway, using 57600 bps or lower on the cable
    > could be a good idea.


    It works better at 2400. I should have mentioned earlier it only talks
    to the phone at all at 57600, never at 115200. I tried 28800, 19200 and
    9600, but never went lower than that until now. Should have been more
    thorough! But still it still sometimes says it is connected but no data
    flows. But at least it works 7 times out of ten. Another change is that
    I sometimes now get responses in the chat script, eg

    OK
    AT
    OK
    ATV1
    OK
    AT+CGDCONT=4,"IP","internet"
    OK
    AT+CGQREQ=4,0,0,0,0,0
    OK
    AT+CGQMIN=4,0,0,0,0,0
    OK
    ATDT*99***4#
    CONNECT

    instead of the usual

    AT
    OK
    ATE0
    OK

    OK

    OK

    OK

    OK

    CONNECT

    but not every time, even at 2400.

    Is there a way to get ppp, or the serial driver, to pause and wait for
    a response from the phone, something along the lines of the
    "max_tx_window=1 and min_tx_turn_time=1000 " settings for IRDA?

    Thanks again,

    Julian


  7. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2



    Clifford Kite wrote:

    > This sticks out like a sore thumb; it was not present in the pppd log
    > messages for the unsuccessful connection. Can someone explain how
    > there can be successful connection to the Internet without a default
    > route through the PPP interface?
    >
    > (I'm not very knowledgeable about Internet connections via a cell-phone
    > but just curious. It seems really strange that a successful Internet
    > connection doesn't have a default route through the PPP interface while
    > an unsuccessful connection apparently does have one.)

    oops -- yes, it wouldn't work like that, you're right. For testing, I
    was bringing up the connection, making a static route out through ppp0
    to one server, and then fetching a page from there. So I wouldn't have
    to keep changing default routes.

    Phew, I would have felt an idiot if that had been the problem!

    Thanks for that,
    Julain


    >
    > TIA
    >
    > --
    > Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/



  8. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com wrote:
    > Mikko Rapeli wrote:
    > > Perhaps this is a performance issue, Linux 2.6 is too fast for the phone.
    > > When IrDA broke between 2.4.19 and 2.4.22 kernels, the IrDA stack in
    > > Linux was too fast and standard compliant for the Ericsson phones.
    > > Slowing it down with max_tx_window=1 and min_tx_turn_time=1000 solved
    > > it. Since GPRS is slow anyway, using 57600 bps or lower on the cable
    > > could be a good idea.

    >
    > It works better at 2400. I should have mentioned earlier it only talks
    > to the phone at all at 57600, never at 115200. I tried 28800, 19200 and
    > 9600, but never went lower than that until now. Should have been more
    > thorough! But still it still sometimes says it is connected but no data
    > flows. But at least it works 7 times out of ten.

    ....

    I have been looking further into this problem, trying to find out what
    it is about kernel 2.6.9 that stops it from working faster than 2400,
    and have drawn a blank.

    In fact, I am now further from understanding this than I was before: I
    previously thought that:
    > If I use a 2.4 kernel I can solve the problem by adding
    > options ppp_async flag_time=0
    > to /etc/modules.conf, and it works every time.

    but this was incorrect. It works even with this option missing in
    2.4.26. (ahh, the joys of troubleshooting GPRS -- you have to test
    everything 100 times as you never know what is network congestion and
    what is the bug!)

    So I guess this means that the problem is not flag_time in ppp_async.c

    Is it possible that this problem with serial comms is the same one that
    affects IRDA comms? If this is the case, I come back to my last
    question:
    > Is there a way to get ppp, or the serial driver, to pause and wait for
    > a response from the phone, something along the lines of the
    > "max_tx_window=1 and min_tx_turn_time=1000 " settings for IRDA?


    Thanks for your help (btw, we have a budget for solving this problem as
    it is holding up a project: please contact me offlist if you feel you
    can help in a more formal way.)

    Julian


  9. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    In article <1118060475.554431.59000@z14g2000cwz.googlegroups.c om>,
    julian@bigpip.com wrote:
    > So I guess this means that the problem is not flag_time in ppp_async.c
    >
    > Is it possible that this problem with serial comms is the same one that
    > affects IRDA comms? If this is the case, I come back to my last
    > question:
    >> Is there a way to get ppp, or the serial driver, to pause and wait for
    >> a response from the phone, something along the lines of the
    >> "max_tx_window=1 and min_tx_turn_time=1000 " settings for IRDA?


    As far as I know, only the bit rate can do this with RS232 on the wire.
    IrDA (like other wireless solutions) is a more complex protocol with
    lots of options to tweak at the lower layers.

    Now, this sounds a lot like a buggy phone to me. I'd try to find ways
    of reopening the connection if it drops or fails (pppd has options for
    these, specific scripts can be written etc), and after certain amount of
    trials I'd reboot the thing with PIN queries disabled.

    The reboot is not easy to trigger on normal phones, but I think the more
    embedded oriented ones could do it. Of course I'm assuming that the device
    will always have network coverage and it's not out on the sea for
    days/months/weeks.

    You could also contact your network operator if they know some issues
    with the phone models you're using or perhaps even some workarounds.

    -Mikko

  10. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com writes:

    >I have an application for GPRS in linux that works with just about any
    >phone Ive tried, except for the Ericsson T39 (and other Ericssons based
    >on the T39, like the F251).


    >The connection seems to succeed every time, but 8 out of 10 times, no
    >data flows. (or, more accurately, I can send to the phone, but nothing
    >flows from the phone to the network, from the network to the phone, or
    >from the phone to the serial port.) Ive tried with a few different
    >networks.


    >If I use a 2.4 kernel I can solve the problem by adding
    > options ppp_async flag_time=0
    >to /etc/modules.conf, and it works every time. But this doesn't seem to
    >work in 2.6 kernels (and I can't change the kernel -- this app is going
    >on lots of existing machines!).


    Did you forget that 2.6 kernels do not use modules.conf? They use
    modprobe.conf



  11. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com wrote:
    > I have an application for GPRS in linux that works with just about any
    > phone Ive tried, except for the Ericsson T39 (and other Ericssons based
    > on the T39, like the F251).


    > The connection seems to succeed every time, but 8 out of 10 times, no
    > data flows. (or, more accurately, I can send to the phone, but nothing
    > flows from the phone to the network, from the network to the phone, or
    > from the phone to the serial port.) Ive tried with a few different
    > networks.


    > If I use a 2.4 kernel I can solve the problem by adding
    > options ppp_async flag_time=0
    > to /etc/modules.conf, and it works every time. But this doesn't seem to
    > work in 2.6 kernels (and I can't change the kernel -- this app is going
    > on lots of existing machines!).


    > Can anyone tell me if and how the flag_time in ppp_async can be set in
    > 2.6.9?


    > Config files, and logs from successful and unsuccessful connections,
    > follow.


    > Thanks for your time,


    > Julian



    > # pppd file /etc/ppp.conf


    > # cat /etc/ppp.conf
    > /dev/ttyS0
    > ipparam gprs
    > 57600
    > crtscts #this doesn't seem to make a difference
    > modem


    Here's a wild guess: I'd try removing the modem option and replacing
    the crtscts option with nocrtscts. If that worked then I'd try
    replacing 57600 with 115200. Even if I'm wrong it shouldn't take
    long to find out.

    The guess takes into account all the information you've given us and
    the results of some google web searching (I have no experience with
    cell-phones).

    > lock
    > receive-all
    > nopcomp
    > noaccomp
    > nomagic
    > noccp
    > novj
    > novjccomp
    > noipdefault
    > ipcp-accept-local
    > ipcp-accept-remote
    > defaultroute
    > usepeerdns
    > user web
    > connect '/usr/sbin/chat -e -S -f /etc/chat_connect -v'
    > disconnect '/usr/sbin/chat -e -S -f /etc/chat_disconnect -v'


    > # cat /etc/chat_connect
    > ABORT 'BUSY'
    > ABORT 'NO ANSWER'
    > ABORT 'NO CARRIER'
    > ABORT 'NO DIALTONE'
    > ABORT 'NO DIAL TONE'
    > ABORT 'VOICE'
    > ABORT 'ERROR'
    > '' AT
    > TIMEOUT 10
    > OK ATE0
    > OK ATV1
    > OK 'AT+CGDCONT=4,"IP","internet"'
    > OK AT+CGQREQ=4,0,0,0,0,0
    > OK AT+CGQMIN=4,0,0,0,0,0
    > OK ATDT*99***4#
    > TIMEOUT 22
    > CONNECT ""


    > # cat /etc/chat_disconnect
    > "" "\K"
    > "" "+++ATH"
    > "" "+++ATH"
    > "" "+++ATH"


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* In my book, the first poster to resort to personal abuse in a Usenet
    debate loses by default. - Rod Smith */


  12. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2


    Clifford Kite wrote:
    > Here's a wild guess: I'd try removing the modem option and replacing
    > the crtscts option with nocrtscts. If that worked then I'd try
    > replacing 57600 with 115200. Even if I'm wrong it shouldn't take
    > long to find out.


    Unfortunately it doesn't work. Its one of the combinations I tried at
    every speed. Only works at 2400. Thanks for the help, though.

    My feeling is that to solve this one, we need to find out what has
    changed in the kernel to make it stop working between kernel 2.4 and
    2.6. Mikko suggests that
    > Perhaps this is a performance issue, Linux 2.6 is too fast for the

    phone.
    Unfortunately, I don't know where to start looking for this kernel
    change (or what questions to ask the people who do). Is the only
    control we have over the serial speed, the baud rate in ppp?

    Julian


  13. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com wrote:

    > Clifford Kite wrote:
    >> Here's a wild guess: I'd try removing the modem option and replacing
    >> the crtscts option with nocrtscts. If that worked then I'd try
    >> replacing 57600 with 115200. Even if I'm wrong it shouldn't take
    >> long to find out.


    > Unfortunately it doesn't work. Its one of the combinations I tried at
    > every speed. Only works at 2400. Thanks for the help, though.


    Okay. FWIW, I've also seen pppd configurations for cell-phone connection
    (via google) that use the "local" option instead of "modem" (crtscts
    does a lot that local doesn't).

    > My feeling is that to solve this one, we need to find out what has
    > changed in the kernel to make it stop working between kernel 2.4 and
    > 2.6. Mikko suggests that
    > > Perhaps this is a performance issue, Linux 2.6 is too fast for the

    > phone.
    > Unfortunately, I don't know where to start looking for this kernel
    > change (or what questions to ask the people who do). Is the only
    > control we have over the serial speed, the baud rate in ppp?


    I thought you said that 2.4 kernels didn't work with "ppp_async
    flag_time=0" in /etc/modules.conf as you had originally indicated.
    Anyway, be aware that things have changed in 2.6 and apparently
    modprobe.conf has replaced modules.conf, with a modified syntax.
    The newest module-init-tools (3.1 ?) package should have a program
    called generate-modules.conf which may make the change-over less
    painful.

    Another way speed can be limited is to set the serial device speed
    (as opposed to the serial device file speed, which is what pppd sets)
    with setserial (baud_base option). Limited to those speeds listed in
    /usr/src/linux/include/asm-i386/termbits.h - the ones under the section
    /* c_cflag bit meaning */ that begin with B.

    Another "FWIW," if the cell-phone "modem" accepts AT+MS= commands
    then you might be able to limit it's connection speed with, e.g.,
    "AT+MS=V42,,19200,,19200" or "AT+MS=V32,,14400,,14400" and use
    38400 for the pppd speed. My gut feel is that the +MS= commands
    won't be accepted but...

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The signal-to-noise ratio is too low in many [news] groups to make
    * them good candidates for archiving.
    * --- Mike Moraes, Answers to FAQs about Usenet */

  14. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    > Okay. FWIW, I've also seen pppd configurations for cell-phone connection
    > (via google) that use the "local" option instead of "modem" (crtscts
    > does a lot that local doesn't).

    nope, tried that!

    >
    > > My feeling is that to solve this one, we need to find out what has
    > > changed in the kernel to make it stop working between kernel 2.4 and
    > > 2.6. Mikko suggests that
    > > > Perhaps this is a performance issue, Linux 2.6 is too fast for the

    > > phone.
    > > Unfortunately, I don't know where to start looking for this kernel
    > > change (or what questions to ask the people who do). Is the only
    > > control we have over the serial speed, the baud rate in ppp?

    >
    > I thought you said that 2.4 kernels didn't work with "ppp_async
    > flag_time=0" in /etc/modules.conf as you had originally indicated.
    > Anyway, be aware that things have changed in 2.6 and apparently
    > modprobe.conf has replaced modules.conf, with a modified syntax.
    > The newest module-init-tools (3.1 ?) package should have a program
    > called generate-modules.conf which may make the change-over less
    > painful.


    sorry, that thing about flag_timke was a red herring -- I must have had
    network congestion or something on the day I did those tests. As I said
    the other day:

    > In fact, I am now further from understanding this than I was before: I
    > previously thought that:
    > > If I use a 2.4 kernel I can solve the problem by adding
    > > options ppp_async flag_time=0
    > > to /etc/modules.conf, and it works every time.


    > but this was incorrect. It works even with this option missing in
    > 2.4.26. (ahh, the joys of troubleshooting GPRS -- you have to test
    > everything 100 times as you never know what is network congestion and
    > what is the bug!)


    So it turns out that it works always in 2.4 (and windows) and not in
    2.6.

    > Another way speed can be limited is to set the serial device speed
    > (as opposed to the serial device file speed, which is what pppd sets)
    > with setserial (baud_base option). Limited to those speeds listed in
    > /usr/src/linux/include/asm-i386/termbits.h - the ones under the section
    > /* c_cflag bit meaning */ that begin with B.

    Still no joy -- I could slow it down as low as 9600 with setserial;
    speeds lower than that, although listed in termbits.h, don't work

    tmp # setserial /dev/ttyS0 baud_base 4800
    Cannot set serial info: Invalid argument

    The higher speeds gave the same results as I got from setting the rate
    in ppp options.

    >
    > Another "FWIW," if the cell-phone "modem" accepts AT+MS= commands
    > then you might be able to limit it's connection speed with, e.g.,
    > "AT+MS=V42,,19200,,19200" or "AT+MS=V32,,14400,,14400" and use
    > 38400 for the pppd speed. My gut feel is that the +MS= commands
    > won't be accepted but...


    nope, none of the phones I have here know about AT+MS.

    Thanks again for your time

    Julian


  15. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    julian@bigpip.com wrote:

    >> I thought you said that 2.4 kernels didn't work with "ppp_async
    >> flag_time=0" in /etc/modules.conf as you had originally indicated.
    >> Anyway, be aware that things have changed in 2.6 and apparently
    >> modprobe.conf has replaced modules.conf, with a modified syntax.
    >> The newest module-init-tools (3.1 ?) package should have a program
    >> called generate-modules.conf which may make the change-over less
    >> painful.


    > sorry, that thing about flag_timke was a red herring -- I must have had
    > network congestion or something on the day I did those tests. As I said
    > the other day:


    >> In fact, I am now further from understanding this than I was before: I
    >> previously thought that:
    >> > If I use a 2.4 kernel I can solve the problem by adding
    >> > options ppp_async flag_time=0
    >> > to /etc/modules.conf, and it works every time.


    >> but this was incorrect. It works even with this option missing in
    >> 2.4.26. (ahh, the joys of troubleshooting GPRS -- you have to test
    >> everything 100 times as you never know what is network congestion and
    >> what is the bug!)


    > So it turns out that it works always in 2.4 (and windows) and not in
    > 2.6.


    Okay, I don't know whether I missed "It even works with this option
    missing..." or the `didn't work with "ppp_async..."' was really a bad
    screw-up in wording on my part. I don't recall, take your choice. :-)

    >> Another way speed can be limited is to set the serial device speed
    >> (as opposed to the serial device file speed, which is what pppd sets)
    >> with setserial (baud_base option). Limited to those speeds listed in
    >> /usr/src/linux/include/asm-i386/termbits.h - the ones under the section
    >> /* c_cflag bit meaning */ that begin with B.

    > Still no joy -- I could slow it down as low as 9600 with setserial;
    > speeds lower than that, although listed in termbits.h, don't work


    > tmp # setserial /dev/ttyS0 baud_base 4800
    > Cannot set serial info: Invalid argument


    Right you are. I'd never tried a base baud rate that low. The baud
    rates permitted may well depend on the particular serial device.

    > The higher speeds gave the same results as I got from setting the rate
    > in ppp options.


    Not really unexpected.

    Good Luck (both here and on the linux-ppp mailing list)! I too would
    like to know what is causing your problem.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* In my book, the first poster to resort to personal abuse in a Usenet
    debate loses by default. - Rod Smith */


  16. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    At last, I came across this:
    http://turtiainen.dna.fi/ppp-2.4.0-patch-t39m

    I patched ppp-2.4.0 with it, and it connects GPRS on the Ericsson F200
    series and the T39m. Every time. On kernel 2.6.9. At 57600. Fantastic.

    But of course I don't want to use 2.4.0 (I need mppe support, etc). Im
    no programmer, but might be able to manually patch 2.4.3. Is it
    advisable to try? Might there be a better way?

    Thanks, Julian


    turtiainen.dna.fi seems to be offline now, so here is the patch:


    diff -Naur ppp-2.4.0/pppd/fsm.c ppp-2.4.0-t39m/pppd/fsm.c
    --- ppp-2.4.0/pppd/fsm.c Fri Aug 13 06:46:12 1999
    +++ ppp-2.4.0-t39m/pppd/fsm.c Fri Oct 12 18:30:59 2001
    @@ -32,6 +32,14 @@
    #include "pppd.h"
    #include "fsm.h"

    +/*
    + * We have to slow down PPP negotiation so that IPCP can negotiate
    + * IP addresses with Ericsson T39m mobile phone. After IPCP is done,
    + * we speed up again. /Tommi.Linnakangas@iki.fi
    + */
    +extern int wait_for_t39m;
    +extern void usleep(unsigned long usec);
    +
    static const char rcsid[] = RCSID;

    static void fsm_timeout __P((void *));
    @@ -746,6 +754,13 @@
    {
    u_char *outp;
    int outlen;
    +
    + /*
    + * Slow down for Ericsson T39m mobile phone.
    /Tommi.Linnakangas@iki.fi
    + */
    + if (wait_for_t39m) {
    + usleep(wait_for_t39m);
    + }

    /* Adjust length to be smaller than MTU */
    outp = outpacket_buf;
    diff -Naur ppp-2.4.0/pppd/ipcp.c ppp-2.4.0-t39m/pppd/ipcp.c
    --- ppp-2.4.0/pppd/ipcp.c Fri Jun 30 04:54:20 2000
    +++ ppp-2.4.0-t39m/pppd/ipcp.c Fri Oct 12 18:32:40 2001
    @@ -37,6 +37,13 @@
    #include "ipcp.h"
    #include "pathnames.h"

    +/*
    + * We have to slow down PPP negotiation so that IPCP can negotiate
    + * IP addresses with Ericsson T39m mobile phone. After IPCP is done,
    + * we speed up again. /Tommi.Linnakangas@iki.fi
    + */
    +extern int wait_for_t39m;
    +
    static const char rcsid[] = RCSID;

    /* global vars */
    @@ -1635,7 +1642,6 @@
    }
    }

    -
    /*
    * ipcp_script - Execute a script with arguments
    * interface-name tty-name speed local-IP remote-IP.
    @@ -1646,6 +1652,11 @@
    {
    char strspeed[32], strlocal[32], strremote[32];
    char *argv[8];
    +
    + /*
    + * IPCP is done. Let's speed up again. /Tommi.Linnakangas@iki.fi
    + */
    + wait_for_t39m = 0;

    slprintf(strspeed, sizeof(strspeed), "%d", baud_rate);
    slprintf(strlocal, sizeof(strlocal), "%I",
    ipcp_gotoptions[0].ouraddr);
    diff -Naur ppp-2.4.0/pppd/main.c ppp-2.4.0-t39m/pppd/main.c
    --- ppp-2.4.0/pppd/main.c Thu Jul 6 11:17:02 2000
    +++ ppp-2.4.0-t39m/pppd/main.c Fri Oct 12 18:31:48 2001
    @@ -68,6 +68,13 @@
    #include "atcp.h"
    #endif

    +/*
    + * We have to slow down PPP negotiation so that IPCP can negotiate
    + * IP addresses with Ericsson T39m mobile phone. After IPCP is done,
    + * we speed up again. /Tommi.Linnakangas@iki.fi
    + */
    +int wait_for_t39m = 200000;
    +
    static const char rcsid[] = RCSID;

    /* interface vars */
    @@ -927,6 +934,13 @@
    struct protent *protp;

    p = inpacket_buf; /* point to beginning of packet buffer */
    +
    + /*
    + * Slow down for Ericsson T39m mobile phone.
    /Tommi.Linnakangas@iki.fi
    + */
    + if (wait_for_t39m) {
    + usleep(wait_for_t39m);
    + }

    len = read_packet(inpacket_buf);
    if (len < 0)
    diff -Naur ppp-2.4.0/pppd/options.c ppp-2.4.0-t39m/pppd/options.c
    --- ppp-2.4.0/pppd/options.c Tue Aug 1 01:38:30 2000
    +++ ppp-2.4.0-t39m/pppd/options.c Fri Oct 12 18:33:26 2001
    @@ -258,7 +258,7 @@
    #endif

    static char *usage_string = "\
    -pppd version %s.%d%s\n\
    +pppd version %s.%d%s-t39m\n\
    Usage: %s [ options ], where options are:\n\
    Communicate over the named device\n\
    Set the baud rate to \n\
    @@ -805,7 +805,7 @@
    char **argv;
    {
    if (phase == PHASE_INITIALIZE) {
    - fprintf(stderr, "pppd version %s.%d%s\n",
    + fprintf(stderr, "pppd version %s.%d%s-t39m\n",
    VERSION, PATCHLEVEL, IMPLEMENTATION);
    exit(0);
    }


  17. Re: gprs, ericsson t39, kernel 2.6.9, ppp 2.4.2

    On 2005-06-16, julian@bigpip.com wrote:
    > At last, I came across this:
    > http://turtiainen.dna.fi/ppp-2.4.0-patch-t39m
    >
    > I patched ppp-2.4.0 with it, and it connects GPRS on the Ericsson F200
    > series and the T39m. Every time. On kernel 2.6.9. At 57600. Fantastic.
    >
    > But of course I don't want to use 2.4.0 (I need mppe support, etc). Im
    > no programmer, but might be able to manually patch 2.4.3. Is it
    > advisable to try? Might there be a better way?


    The patch applies to 2.4.3 (well, the 2.4.3 original in Debian Sarge at
    least) except for options.c which only updates the version string.
    Hopefully it fixes your problem for good.

    -Mikko

    ~/src/temp/ppp-2.4.3.orig/upstream/tarballs/ppp-2.4.3$
    patch -p1 < ../ppp-2.4.0-patch-t39m
    patching file pppd/fsm.c
    Hunk #1 succeeded at 55 (offset 23 lines).
    Hunk #2 succeeded at 809 (offset 55 lines).
    patching file pppd/ipcp.c
    Hunk #1 succeeded at 61 (offset 24 lines).
    Hunk #2 succeeded at 1969 (offset 327 lines).
    Hunk #3 succeeded at 1979 (offset 327 lines).
    patching file pppd/main.c
    Hunk #1 succeeded at 121 (offset 53 lines).
    Hunk #2 succeeded at 964 (offset 30 lines).
    patching file pppd/options.c
    Hunk #1 FAILED at 258.
    Hunk #2 FAILED at 805.
    2 out of 2 hunks FAILED -- saving rejects to file pppd/options.c.rej
    ~/src/temp/ppp-2.4.3.orig/upstream/tarballs/ppp-2.4.3$ cd
    pppd
    ~/src/temp/ppp-2.4.3.orig/upstream/tarballs/ppp-2.4.3/pppd$
    less options.c.rej
    ***************
    *** 258,264 ****
    #endif

    static char *usage_string = "\
    - pppd version %s.%d%s\n\
    Usage: %s [ options ], where options are:\n\
    Communicate over the named device\n\
    Set the baud rate to \n\
    --- 258,264 ----
    #endif
    ***************
    *** 258,264 ****
    #endif

    static char *usage_string = "\
    - pppd version %s.%d%s\n\
    Usage: %s [ options ], where options are:\n\
    Communicate over the named device\n\
    Set the baud rate to \n\
    --- 258,264 ----
    #endif

    static char *usage_string = "\
    + pppd version %s.%d%s-t39m\n\
    Usage: %s [ options ], where options are:\n\
    Communicate over the named device\n\
    Set the baud rate to \n\
    ***************
    *** 805,811 ****
    char **argv;
    {
    if (phase == PHASE_INITIALIZE) {
    - fprintf(stderr, "pppd version %s.%d%s\n",



+ Reply to Thread