pancho wrote in message news:...

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

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

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

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

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

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