Weird PPP trouble

[Omar Loggiodice]

Joe Knapka Writes :
:
:Hi, everone.
:
:Maybe someone can shed light on the strange behavior I am
:experiencing with PPP. 

Hi Joe,

   Like David said, make sure that the "modem" option is set in your
/etc/ppp/options file or in the command line. This will make sure that
pppd uses the proper hardware lines to control modem behaviour. BTW, this
is the default option (make sure "local" is not in your options file).

However, the cause of your problem could be your modem init string and
configuration. Let me explain the semantics of open() for a serial line,
hopefully it will explain why what you are observing is not that 
"strange".

Before going into this, there are two modem (hardware) lines that have 
special meaning: DTR and DCD (Carrier Detect and Data terminal ready).

DTR, when lowered, is expected (by pppd and the kernel) to hang-up your modem.
DCD, indicates that a carrier signal is present.

Now to the semantics of open() for serial devices:

Blocking open(): When the open() function is called _without_ "O_NDELAY" or
                 "O_NONBLOCK" as part of the flags argument. 
		 The function opens the device and does the work that a regular
		 open() call would do, but it BLOCKS until:
		 - DCD is detected 
		 - The line is freed (in case it is also being used by 
		   a callout device, this is not your case)

                 Note that you get a carrier _only_ after a successful
		 connection with another modem, which means that something
		 like: 

                 int main(int argc, char **argv) 
		 { 
		 open("/dev/ttyS1", O_RDWR); 
		 ... ... 
		 }

                 will NOT work (ie. the open() call will block) until you dial
		 another modem and a connection is established.


Non-Blocking open(): open() called _with_ "O_NDELAY" or "O_NONBLOCK" in the 
                     flags. Opens the device but does _not_ wait for a DCD and
		     returns EBUSY if a callout device is using the line.

:The symptom is that sometimes
:after pppd is killed, nothing can subsequently open the
:serial port it used -- unless the open call is
:non-blocking, in which case everything works fine.
:
:Specifically, this means that pppd (or more likely chat)
:cannot open the serial port again after it dies, which is
:fantastically aggravating to me, as I have cause to bring
:the link up and down fairly frequently.
:

Actually this sounds like your line is not being hung up properly
after pppd is killed. Hence chat can't dial becuase it is expecting
the modem to be in "command" mode. (chat is not smart enough to send
+++ ATH sequences that will hang up the modem).

:blocks forever. I also discovered that if I just start
:Minicom up and let it open the port, which it does
:successfully, and close it again, then everything's
:cool, and pppd and chat work fine again. 

OK, after so much talk about open() it looks like your problem is not
directly related to blocking or non-blocking issues <grin>. It seems as if
pppd is not properly hanging up your modem and minicom is solving that by
hanging up and resetting the modem. (minicom is a little bit more smart
about hanging-up the modem, since it knows about the +++ ATH sequence).

Configure your modem so it hangs up properly after killing pppd. To assure
this you have to make sure that the modem responds by hanging up when the
DTR line is dropped (Use AT&D0 or something like that in the init string,
check your modem manual, also check register S25 for timing info)

:But then I discovered another bizarre thing: the above
:symptoms only occur when I dialup my company's terminal
:server (a BitRunner, I think). When I dialup Mindspring,
:everything is fine after the link comes down. 

Actually, given the cause of your problem, this doesn't seem that 
strange. My guess would be that Mindspring's terminal server is 
properly configured to hang-up the line when the ppp connection is 
dropped, while the terminal server at work is expecting your modem
to hang-up the line as soon as the ppp connection is finished. 


Best regards,
   Omar
   
PS. Sorry for so much talk just to say: "use AT&D0 or something like that" 
;-)

-- 
____________________________________________________________________
            /   __  __  __  - __  __ / - _  __  ologgio at vrainn.com
  Omar R.  /__ /_/ /_/ /_/ / /_/ /_/ / /_  /-_  CIS: 74040,1543
                  __/ __/                         
___C++/6_yrs____Virtual Reality/4_yrs____Vorl_____Linux(free)_______
There's no "best" language...look at your needs