Re: Re: kppp reporting 'unable to open modem'

* Guerreiro da Luz <[email protected]> [2005 Dec 14 11:41 -0600]:
> On 12/14/05, Linuxant support (Jonathan) <[email protected]> wrote:
> > Hi,
> >
> > the source of the problem could be either kppp, the kernel of the HSF
> > modem driver. You are the first user which have reported this issue and
> > we will investigate if other users report it as well. If this is a bug
> > in the HSF modem driver, it will be fixed in a future release of the driver.
> >
> > Regards,
> 
> I just tried deleting 2.6.14 workaround in serial_cnxt.c and
> recompiling, but to no avail.

Okay, hopefully I can shed a bit more light based on experiments I did
today.

I followed Guerreiro's advice and was sure to exit minicom with the
Ctl-a q key sequence whereupon kppp worked wonderfully.  I might add
that the hsfmodem gives a far better throughput with compression than
the 56k PCMCIA modem I was using--good work!

Now to troubleshoot this further I rebooted in my KNOPPIX 4.0.2
partition and installed the hsfmodem binary package for its kernel
2.6.12 and kppp worked flawlessly and speedily with my license key
applied.  This confirms my assertion that this package worked about six
weeks back with a Debian 2.6.12 kernel.

Back to Sid with 2.6.14 and a bit more experimentation.  At first we
(co-worker and me) thought it might be an initialization string issue,
but it wasn't.  In kppp one can search for the modem and with the
default of hardware flow control, kppp reports modem not responding.  I
next tried the modem search with flow control set to None and it found
the hsfmodem devices.  I tried connecting to my ISP in this fashion and
it didn't work.  So, I went to the third option and set the flow
control to soft (XON/XOFF) and now the modem is found, configured, and
a connection to the ISP works well as in KNOPPIX.

Guerreiro, can you try setting your kppp's flow control to soft and see
if that works?  Make sure to reboot so the hsfmodem is in its default
state.

My assumption is that minicom is not using hardware (RTS/CTS) by
default and can thus talk to the hsfmodem device.  By default kppp is
using hardware flow control and for some reason cannot detect or see a
change of state of those lines from the modem device with kernel
2.6.14, but works in its default configuration with kernel 2.6.12. 
Running minicom and exiting without resetting the hsfmodem device
apparently leaves the device in a state where hardware flow control
works until the next hsfmodem reset, apparently.  

Incidentally, in my experimentation I found that hanging up from the
ISP meant that I had to fire up minicom again until I changed the
initialization string in kppp from ATZ to ATZ0 then kppp would
reconnect without the need to re-run minicom.   However, after a cold
system start, minicom would need to be run initially for kppp to work. 
Once kppp was set to software flow control, it worked reliably every
time from colld boot onward.

So, Jonathan, I'm guessing the hardware flow control emulation of the
hsfmodem may be a good place to look.

- Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          |  Successfully Microsoft
  Amateur radio exams; ham radio; Linux info @  | free since January 1998.
             http://www.qsl.net/n0nb/           |  "Debian, the choice of
             My Kawasaki KZ-650 SR @            |     a GNU generation!"
        http://www.networksplus.net/n0nb/       |   http://www.debian.org