m'gettying closer! (was Re: modem not responding to mgetty)

[Jay Quinby]

Getting the modem to answer and the logs to start rolling is progress
for sure. One thing to recall is that I wrote the doc for a FreeBSD
4.x, but I imagine this stuff is largely unchanged. I could be
totally wrong on that, though - I don't do as much with BSD at my
current gig. Commments inline below.


On Fri, 7 Jan 2005, Timothy Luoma wrote:

>
> Update on progress on project "ppp dialin".  I am following the
> instructions at
> http://node.to/freebsd/how-tos/how-to-freebsd-pppserver.html.
>
> On the advice of Charles Ulrich on FBSD-Questions, I bought a serial
> modem Creative Modem Blaster v.92 Model DE5621.  I shut off the
> machine, hooked up the modem (removed the old PCI modem) and rebooted.
>
> Here's the relevant configuration that I have (note: 5.3, standard
> kernel)
>
> I am unsure about several things
> 	-  should be using cuaa0 or ttyd0 (I am using mgetty)?

If I recall correctly, cuaa0 is the device name for Serial 0, or
the equivalent of /dev/ttyS0 on Linux. One way to test this would
be to fire up something like minicom, and try to connect to it. You
ought to be able to send some of the basic AT commands and get some
responses (good ones are ATDT 1234 and ATH, which will dial 1234
and hang up the line). Double-checking my own doc (since my memory
is hazy, you want to set the following, assuming your modem is at
serial 0:

/etc/ttys:
ttyd0 should point to mgetty, with a line similar to this, allowing
for the correct path to your mgetty:

ttyd0  "/usr/local/sbin/mgetty -s 115200" dialup on secure

Your mgetty.conf should point to the correct port (cuaa0 for serial 0)

port cuaa0
debug 4
fax-id 00 00 000000
speed 115200
direct NO
blocking NO

[...]

>
> 	- are the 'set ifaddr' lines right in ppp.conf? I'm using 192.168.1.x
> and have selected unused IP addresses in that range
>
> $ fgrep mgetty /etc/ttys|fgrep -v '#'
> ttyd0  "/usr/local/sbin/mgetty -s 115200" dialup on secure
>
> note: in ppp.conf, I'm not sure if I need ttyd0 or cuaa0.
>


Your ppp.conf is going to contain only references to cuaa0 - the
one in the doc is extra long, owing to the serial card we stuck in
there. We had 4 modems hanging off the machine.




> (NOTE: FRED is not really the username)
>
> $ cat /etc/ppp/ppp.conf
> default:
>    set device /dev/cuaa0
>    set debug log Phase Chat LCP IPCP CCP tun command
>    set speed 115200
>    set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK
> ATE1Q0 OK \\dATDT\\TTIMEOUT 40 CONNECT"
>    set timeout 120
>    set ifaddr 192.168.1.1/0 192.168.1.2/0 255.255.255.0 0.0.0.0
>    add default HISADDR
>
> cuaa0:
>    set ifaddr 192.168.1.3 192.168.1.4-192.168.1.9
>    enable passwdauth
>    allow users FRED ppp
>    accept dns
>    set dns 67.36.13.26
>    enable proxy
>
> ttyd0:
>    set ifaddr 192.168.1.3 192.168.1.4-192.168.1.9
>    enable passwdauth
>    allow users FRED ppp
>    accept dns
>    set dns 67.36.13.26
>    enable proxy
>
> $ cat /usr/local/etc/mgetty+sendfax/mgetty.config
>
> 	port cuaa0
> 	debug 4
> 	fax-id 00 00 000000
> 	speed 115200
> 	direct NO
> 	blocking NO
> 	port-owner uucp
> 	port-group uucp
> 	port-mode 0660
> 	toggle-dtr YES
> 	toggle-dtr-waittime 500
> 	data-only YES
> 	fax-only NO
> 	modem-type auto
> 	init-chat "" AT OK
> 	modem-check-time 3600
> 	rings 1
> 	answer-chat "" ATA CONNECT \c \r
> 	answer-chat-timeout 30
> 	autobauding NO
> 	ringback NO
> 	ringback-time 30
> 	ignore-carrier false
> 	issue-file /etc/issue
> 	prompt-waittime 500
> 	login-prompt @!login:
> 	login-time 240
> 	diskspace 1024
> 	notify faxadmin
> 	fax-owner uucp
> 	fax-group modem
> 	fax-mode 0660
>
> $ fgrep ppp /etc/passwd
> ppp:*:1003:1003:ppp:/home/ppp:/etc/ppp/ppp-dialup
>
> $ ls -l /etc/ppp/ppp-dialup
> -rwxr-xr-x  1 root wheel 258 Jan  7 19:56 /etc/ppp/ppp-dialup*
>
> (the content of the script is the same from the webpage, which says it
> is the same as the FreeBSD handbook)
>
> XXXXXXX is the dialin number
>
> here is what I get on the *client end* when I try to dial my PPP server
> Fri Jan  7 21:12:06 2005 : Dialing XXXXXXX
> Fri Jan  7 21:12:06 2005 : CCLWrite : ATDTXXXXXXX\13
> Fri Jan  7 21:12:37 2005 : CCLMatched : +ER:
> Fri Jan  7 21:12:37 2005 : CCLMatched : LAPM
> Fri Jan  7 21:12:37 2005 : Modem Reliable Link Established.
> Fri Jan  7 21:12:37 2005 : CCLMatched : +DR:
> Fri Jan  7 21:12:37 2005 : CCLMatched : V42B\13
> Fri Jan  7 21:12:37 2005 : Modem Compression Established.
> Fri Jan  7 21:12:37 2005 : CCLMatched : CONNECT
> Fri Jan  7 21:12:37 2005 : CCLMatched : 26400
> Fri Jan  7 21:12:40 2005 : Serial connection established.
> Fri Jan  7 21:12:40 2005 : using link 0
> Fri Jan  7 21:12:40 2005 : Using interface ppp0
> Fri Jan  7 21:12:40 2005 : Connect: ppp0 <--> /dev/cu.modem
> Fri Jan  7 21:12:41 2005 : sent [LCP ConfReq id=0x1 <asyncmap 0x0>
> <magic 0x32727ef4> <pcomp> <accomp>]
> Fri Jan  7 21:12:41 2005 : Hangup (SIGHUP)
> Fri Jan  7 21:12:41 2005 : Modem hangup
> Fri Jan  7 21:12:41 2005 : Connection terminated.
>

Looks pretty good up until it hangs up. And no real errors. Not
sure. Is /dev/cu.modem a symlink to /dev/cuaa0?


> and here is what happens on the *server* end
>
> tail -50 /var/log/mgetty.ttyd0
> 01/07 21:12:35 yd0  mgetty: experimental test release 1.1.31-Jul24
> 01/07 21:12:35 yd0  check for lockfiles
> 01/07 21:12:35 yd0  locking the line
> 01/07 21:12:36 yd0  lowering DTR to reset Modem
> 01/07 21:12:36 yd0  send: \dATQ0V1H0[0d]
> 01/07 21:12:37 yd0  waiting for ``OK'' ** found **
> 01/07 21:12:37 yd0  send: ATS0=0Q0&D3&C1[0d]
> 01/07 21:12:37 yd0  waiting for ``OK'' ** found **
> 01/07 21:12:37 yd0  mdm_send: 'ATI'
> 01/07 21:12:37 yd0  Generic Rockwell modem (56000)
> 01/07 21:12:37 yd0  mdm_send: 'ATI3'
> 01/07 21:12:37 yd0  mdm_send: 'ATI4'
> 01/07 21:12:37 yd0  additional info: 'a007040284C6002F'
> 01/07 21:12:37 yd0  modem quirks: 0004
> 01/07 21:12:37 yd0  mdm_send: 'AT+FCLASS=2' -> OK
> 01/07 21:12:37 yd0  mdm_send: 'AT+FCLASS=0' -> OK
> 01/07 21:12:37 yd0  mdm_send: 'AT+FAA=1;+FCR=1' -> OK
> 01/07 21:12:38 yd0  mdm_send: 'AT+FBOR=0' -> OK
> 01/07 21:12:38 yd0  mdm_send: 'AT+FLID="49 115 xxxxxxxx"' -> OK
> 01/07 21:12:38 yd0  mdm_send: 'AT+FDCC=1,5,0,2,0,0,0,0' -> OK
> 01/07 21:12:38 yd0  waiting...
>
> [as far as I know, everything before this is just mgetty setting up,
> and the rest is what happens when a call comes in]
>


Looks good so far.


> 01/07 21:16:04 yd0  wfr: waiting for ``RING''
> 01/07 21:16:04 yd0  send: ATA[0d]
> 01/07 21:16:04 yd0  waiting for ``CONNECT'' ** found **
> 01/07 21:16:30 yd0  send:
> 01/07 21:16:30 yd0  waiting for ``_'' ** found **
> 01/07 21:16:34 ##### data dev=ttyd0, pid=966, caller='none',
> conn='115200', name='', cmd='/etc/ppp/ppp-pap-dialup', user='/AutoPPP/'
>
> [at that point mgetty just resets]
>

I'm a little stumped. What happens if you run the ppp-login script
by itself? It ought to start generating the line-noise-garbage on
stdout. What's in /etc/ppp/ppp-pap-dialup?  That script is running
right before things hose up.



> So it's been a long day, and I've banged my head against this for a
> couple hours.  Going to eat.  Any ideas will be appreciated.
>

Been there. I think you're really close to getting this up and
running (if you haven't already by the time you get this.

-- 
jquinby at node.to
http://packet.node.to
Monday of the First Week of Ordinary Time