doing AT commands while a pppd connection - PPP

This is a discussion on doing AT commands while a pppd connection - PPP ; Hello I hope this is the correct forum to ask this: I would like to know if there is a way of communicate with the modem through the serial port with AT commands while this modem is being used to ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: doing AT commands while a pppd connection

  1. doing AT commands while a pppd connection

    Hello

    I hope this is the correct forum to ask this:

    I would like to know if there is a way of communicate with the modem
    through the serial port with AT commands while this modem is being
    used to have a PPP connection with pppd (under linux).
    When I were connected through GSM without PPP I used to switch
    off data mode (+++), doing the AT commands, and return to data mode
    with AT command ATO. But now that I connect through PPP instead of
    a simple telephone call I cannot because pppd have the control of
    the tty!!

    (I need to do AT commands to write in the phone book of the SIM,
    which is the unique permanent writable place to store a few parameters.
    I hope I dont have to close PPP, write this and connect again.)

    Best regards and lots of thanks in advance!

    Jorge


  2. Re: doing AT commands while a pppd connection

    pancho wrote in message news:...

    Seems to be a very important/urgent issue as I just found this after
    posting my own message :-)

  3. Re: doing AT commands while a pppd connection

    El Sun, 25 Jul 2004 12:37:45 -0700, Dr. Nikolaus Schaller escribió:

    > pancho wrote in message news:...
    >
    > Seems to be a very important/urgent issue as I just found this

    after posting my own message :-)

    According to the responses to your message also seems to be much more
    complicated than I thought... I had the hope that just stopping the
    pppd program it would allow me to write and read from the tty, but
    I see this is not possible.

    I have seen that my modem supports the DSC bus, which would allow to
    use the modem and even responding calls while in GPRS, but I think I
    would need a lot of hardware to make this working.

    I will follow your thread to clarify myself about this...

    Thanks to all!

    Jorge

  4. Re: doing AT commands while a pppd connection

    pancho writes:
    > I have seen that my modem supports the DSC bus, which would allow to
    > use the modem and even responding calls while in GPRS, but I think I
    > would need a lot of hardware to make this working.


    Assuming "DSC bus" means "separate interface for management," then
    that's the best possible solution. Trying to manage a modem in-band
    typically leads to never-ending timing-related nightmares.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: doing AT commands while a pppd connection

    El Wed, 28 Jul 2004 12:15:42 -0400, James Carlson escribió:

    > pancho writes:
    >> I have seen that my modem supports the DSC bus, which would allow to
    >> use the modem and even responding calls while in GPRS, but I think I
    >> would need a lot of hardware to make this working.

    >
    > Assuming "DSC bus" means "separate interface for management," then
    > that's the best possible solution. Trying to manage a modem in-band
    > typically leads to never-ending timing-related nightmares.


    Completely agree. Sadly, the hardware guy says me that at this stage of
    the project we cannot add this to the device


    Best regards,

    Jorge

  6. Re: doing AT commands while a pppd connection

    pancho wrote in message news:...
    > > Trying to manage a modem in-band
    > > typically leads to never-ending timing-related nightmares.

    > Sadly, the hardware guy says me that at this stage of
    > the project we cannot add this to the device


    So, it should be done in software.

    I see two options:
    a) modify the ppp kernel module
    b) stop&restart pppd as you initially proposed

    For b) the sequence should be
    1. stop pppd
    2. wait that it is really stopped (e.g. poll for /dev/modem no longer
    being busy)
    3. send a "+++"
    4. wait a grace time period (I think that can be set in some S
    register)
    5. send the AT command
    6. get any response until either ERROR, OK or a timeout occurs
    8. restart pppd

    What would happen if the modem is not switched properly to command
    mode? It stays in data mode sending some +++ATabcdef to the PPP
    server. This is not understood - and ignored because the checksum does
    not fit. So, nothing harmful.

    For a) the operation should be similar except that
    1. stop ppp to generate packets - just queue them up
    6. catch responses and do not try to interpret as a PPP packet
    7. send ATO and reenable ppp to generate packets

    b) could result in problems with shutting down and restarting pppd too
    fast. This might end up in instable connections. I assume that it
    should not be done faster than every 10 seconds. An area for just
    experimenting. Here an idea:

    #!/bin/sh
    while true
    do
    kill -TERM `cat /var/run/ppp0.pid`
    sleep 1
    echo "+++" >/dev/modem
    sleep 1
    echo "AT ...."
    cat sleep 1
    pppd
    sleep 10 # let communication run
    done

    a) has to deeply go into the kernel module

    -- hns

  7. Re: doing AT commands while a pppd connection

    hns@computer.org (Dr. Nikolaus Schaller) writes:
    > For b) the sequence should be
    > 1. stop pppd


    What exactly do you mean by "stop pppd?"

    If you just send it SIGSTOP, the process will stop, but the kernel
    portion -- which passes user data -- will still be active.

    If you send it SIGHUP or SIGTERM, then the process will exit and you
    can talk to the modem yourself, but the action of terminating the
    process will also close the serial port (causing DTR to be deasserted
    and, normally, the modem to go back on-hook) and tear down the IP
    interface. None of that matches what the original poster wanted to do
    -- I believe he wants to talk to the modem while still on-line.

    > 2. wait that it is really stopped (e.g. poll for /dev/modem no longer
    > being busy)


    Perhaps just a nit, but pppd doesn't get exclusive access to the
    serial port. You can always open it if you like. Instead, a separate
    UUCP-compatible lock file is used. (How that's done varies by
    platform.)

    > 3. send a "+++"


    That's not going to help if the line has already been disconnected due
    to terminating pppd.

    You could possibly open the serial port yourself (to hold it open and
    avoid the closure) while pppd is active and then terminate pppd, but
    that still will have problems, as the kernel's input processing won't
    be reset from PPP decoding back to plain text.

    > For a) the operation should be similar except that
    > 1. stop ppp to generate packets - just queue them up


    What needs to be stopped here is the kernel.

    > 6. catch responses and do not try to interpret as a PPP packet
    > 7. send ATO and reenable ppp to generate packets


    Right.

    > kill -TERM `cat /var/run/ppp0.pid`
    > sleep 1


    Rather than sleeping -- and a sleep of one second is, although likely
    to work "much" of the time, almost certainly not enough to be stable
    -- consider using the 'disconnect' option to trigger the rest of the
    process. (Yes, there should be a link-down script.)

    > echo "+++" >/dev/modem
    > sleep 1
    > echo "AT ...."
    > cat

    That won't work. If the response comes in while you don't have the
    port open, the response will be discarded. Note that the shell opens
    and closes the port for each redirection ('<' or '>'). Writing a
    program (perhaps using Perl) or using a chat script would be better
    here.

    Bottom line, though, is that I don't think this plan is really viable.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  8. Re: doing AT commands while a pppd connection

    James Carlson wrote in message news:...
    > What exactly do you mean by "stop pppd?"


    send SIGHUP/SIGTERM

    > can talk to the modem yourself, but the action of terminating the
    > process will also close the serial port (causing DTR to be deasserted
    > and, normally, the modem to go back on-hook) and tear down the IP
    > interface. None of that matches what the original poster wanted to do
    > -- I believe he wants to talk to the modem while still on-line.


    I understood that he wants to get some (GPRS) modem parameters like
    SIM card, phone book etc. And of course the proposed procedured drops
    the PPP/IP connection to the server completely - and has to
    reestablish the link afterwards. I agree this is very awkward but
    depending on the application it might be acceptable...


    > > For a) the operation should be similar except that
    > > 1. stop ppp to generate packets - just queue them up

    >
    > What needs to be stopped here is the kernel.


    Yes, I mean the ppp kernel module that translates IP packets into PPP
    packets and sends them to the modem. A (new) ioctl could to that.

    > Bottom line, though, is that I don't think this plan is really viable.


    The plan was meant as an experiment what *can* be done without
    modifying the kernel (module).

    After all, I think that modifying the kernel module and introducing a
    new ioctl() for sending commands without dropping the PPP/IP
    connection is a much better (and more general) approach. It is still
    dangerous of course to modify arbitrary modem parameters in between...

    -- hns