PPP will be the DEATH of me!!!
Jeff Pratt
I'm going right out of my skull on this one. I have a machine set up for
2 users to dial into. Single modem (real modem, external, 33.6), but we
dial in at different times of the day. Everything was set up and working
fine, with this config:
[root@hotwings /root]# cat /etc/ppp/options
auth -chap +pap modem crtscts debug proxyarp lock
ms-dns <DNS IP ADDR>
[root@hotwings /root]# cat /etc/ppp/pap-sercrets
# Secrets for authentication using PAP
# client server secret IP addresses
carl * <HIDDEN> <PPP IP ADDR>
jsp * <HIDDEN> <PPP IP ADDR>
[root@hotwings /root]# cat /etc/ppp/options.ttyS1
<PPP SERV IP ADDR>:<PPP IP ADDR>
[root@hotwings /root]# cat /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses
[root@hotwings /root]# cat /proc/sys/net/ipv4/ip_forward
1
[root@hotwings /root]# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
root@hotwings /root]# arp
<Majority of output snipped>
<PPP IP ADDR> * * MP
eth0
BUT, nothing travels down the damned pipe!!!!!!!! I can no longer ping the
ppp server, the nameserver, anything! Normally I'd just roll back whatever
changes I'd made recently, but I haven't made any. Tripwire hasn't shown
me anything changed either. Help...
Jeff
Clifford Kite
> I'm going right out of my skull on this one. I have a machine set up for
> 2 users to dial into. Single modem (real modem, external, 33.6), but we
> dial in at different times of the day. Everything was set up and working
> fine, with this config:
[...]
> BUT, nothing travels down the damned pipe!!!!!!!! I can no longer
> ping the ppp server, the nameserver, anything! Normally I'd just
> roll back whatever changes I'd made recently, but I haven't made any.
> Tripwire hasn't shown me anything changed either. Help...
You've showed us configuration files and said they *were* working.
However you've already "gone right out of your skull" if you think
those alone will help us determine what the problem is that you
apparently now have.
You imply that the modem answers the incoming calls. Show us exact
copies of pppd and chat, or mgetty, debug logs including timestamps
(you neglected to say how pppd is started on your end).
Have you upgraded anything that could be related? Hardware or software.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* I hear and I forget. I see and I remember. I do and I understand.
--Confucius, 551-479 BC */
Jeff Pratt
> Jeff Pratt <j...@pizza73.com> wrote:
>
>> I'm going right out of my skull on this one. I have a machine set up for
>> 2 users to dial into. Single modem (real modem, external, 33.6), but we
>> dial in at different times of the day. Everything was set up and working
>> fine, with this config:
>
> [...]
>
>> BUT, nothing travels down the damned pipe!!!!!!!! I can no longer
>> ping the ppp server, the nameserver, anything! Normally I'd just
>> roll back whatever changes I'd made recently, but I haven't made any.
>> Tripwire hasn't shown me anything changed either. Help...
>
> You've showed us configuration files and said they *were* working.
> However you've already "gone right out of your skull" if you think
> those alone will help us determine what the problem is that you
> apparently now have.
>
> You imply that the modem answers the incoming calls. Show us exact
> copies of pppd and chat, or mgetty, debug logs including timestamps
> (you neglected to say how pppd is started on your end).
Sorry, I'd been informed that posting logs here was impolite. pppd is
started by mgetty+sendfax using AutoPPP.
Snippet of /var/log/ppp.log showing one complete session (from a mac):
Feb 27 11:10:49 hotwings pppd[26584]: pppd 2.3.11 started by a_ppp, uid 0
Feb 27 11:10:49 hotwings pppd[26584]: Using interface ppp0
Feb 27 11:10:49 hotwings pppd[26584]: Connect: ppp0 <--> /dev/ttyS1
Feb 27 11:10:49 hotwings pppd[26584]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <auth pap> <magic 0x553aec66> <pcomp> <accomp>]
Feb 27 11:10:49 hotwings pppd[26584]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <auth pap> <magic 0x553aec66> <pcomp> <accomp>]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [LCP ConfReq id=0x25 <asyncmap
0x0> <magic 0xd1efa894> <pcomp> <accomp>]
Feb 27 11:10:51 hotwings pppd[26584]: sent [LCP ConfAck id=0x25 <asyncmap
0x0> <magic 0xd1efa894> <pcomp> <accomp>]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [PAP AuthReq id=0x1 user="carl"
password=<hidden>]
Feb 27 11:10:51 hotwings pppd[26584]: sent [PAP AuthAck id=0x1 "Login ok"]
Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfReq id=0x1 <addr
192.9.200.215> <compress VJ 0f 01>]
Feb 27 11:10:51 hotwings pppd[26584]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x25 <compress
VJ 0f 00> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfNak id=0x25 <addr
192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3 192.9.200.215>]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:10:51 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:10:51 hotwings pppd[26584]: sent [LCP ProtRej id=0x2 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [LCP ProtRej id=0x26 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Feb 27 11:10:51 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x26 <compress
VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
192.9.200.215>]
Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfAck id=0x26 <compress
VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
192.9.200.215>]
Feb 27 11:10:53 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:10:53 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:10:53 hotwings pppd[26584]: sent [LCP ProtRej id=0x3 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:10:53 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x27 <compress
VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
192.9.200.215>]
Feb 27 11:10:53 hotwings pppd[26584]: sent [IPCP ConfAck id=0x27 <compress
VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
192.9.200.215>]
Feb 27 11:10:54 hotwings pppd[26584]: sent [IPCP ConfReq id=0x1 <addr
192.9.200.215> <compress VJ 0f 01>]
Feb 27 11:10:54 hotwings pppd[26584]: rcvd [IPCP ConfNak id=0x1 <compress
VJ 0f 00>]
Feb 27 11:10:54 hotwings pppd[26584]: sent [IPCP ConfReq id=0x2 <addr
192.9.200.215> <compress VJ 0f 00>]
Feb 27 11:10:54 hotwings pppd[26584]: rcvd [IPCP ConfAck id=0x2 <addr
192.9.200.215> <compress VJ 0f 00>]
Feb 27 11:10:54 hotwings pppd[26584]: found interface eth0 for proxy arp
Feb 27 11:10:54 hotwings pppd[26584]: local IP address 192.9.200.215
Feb 27 11:10:54 hotwings pppd[26584]: remote IP address 192.9.200.102
Feb 27 11:10:55 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:10:55 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:10:55 hotwings pppd[26584]: sent [LCP ProtRej id=0x4 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:10:57 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:10:57 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:10:57 hotwings pppd[26584]: sent [LCP ProtRej id=0x5 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:10:59 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:10:59 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:10:59 hotwings pppd[26584]: sent [LCP ProtRej id=0x6 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:11:00 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x25
magic=0xd1efa894]
Feb 27 11:11:00 hotwings pppd[26584]: sent [LCP EchoRep id=0x25
magic=0x553aec66]
Feb 27 11:11:01 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:11:01 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:11:01 hotwings pppd[26584]: sent [LCP ProtRej id=0x7 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:11:03 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:11:03 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:11:03 hotwings pppd[26584]: sent [LCP ProtRej id=0x8 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:11:04 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
00 00 00 00 02 04 00 00 03 03 01
Feb 27 11:11:04 hotwings pppd[26584]: Unsupported protocol 'Appletalk
Control Protocol' (0x8029) received
Feb 27 11:11:04 hotwings pppd[26584]: sent [LCP ProtRej id=0x9 80 29 01 25
00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
Feb 27 11:11:27 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x26
magic=0xd1efa894]
Feb 27 11:11:27 hotwings pppd[26584]: sent [LCP EchoRep id=0x26
magic=0x553aec66]
Feb 27 11:11:40 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x27
magic=0xd1efa894]
Feb 27 11:11:40 hotwings pppd[26584]: sent [LCP EchoRep id=0x27
magic=0x553aec66]
Feb 27 11:11:48 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x28
magic=0xd1efa894]
Feb 27 11:11:48 hotwings pppd[26584]: sent [LCP EchoRep id=0x28
magic=0x553aec66]
Feb 27 11:11:52 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x29
magic=0xd1efa894]
Feb 27 11:11:52 hotwings pppd[26584]: sent [LCP EchoRep id=0x29
magic=0x553aec66]
Feb 27 11:11:54 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x2a
magic=0xd1efa894]
Feb 27 11:11:54 hotwings pppd[26584]: sent [LCP EchoRep id=0x2a
magic=0x553aec66]
Feb 27 11:12:02 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x2b
magic=0xd1efa894]
Feb 27 11:12:02 hotwings pppd[26584]: sent [LCP EchoRep id=0x2b
magic=0x553aec66]
Feb 27 11:12:10 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x2c
magic=0xd1efa894]
Feb 27 11:12:10 hotwings pppd[26584]: sent [LCP EchoRep id=0x2c
magic=0x553aec66]
Feb 27 11:12:18 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x2d
magic=0xd1efa894]
Feb 27 11:12:18 hotwings pppd[26584]: sent [LCP EchoRep id=0x2d
magic=0x553aec66]
Feb 27 11:12:26 hotwings pppd[26584]: rcvd [LCP EchoReq id=0x2e
magic=0xd1efa894]
Feb 27 11:12:26 hotwings pppd[26584]: sent [LCP EchoRep id=0x2e
magic=0x553aec66]
Same login as seen in /var/log/mgetty.log.ttyS1:
--
02/27 10:25:59 yS1 mgetty: experimental test release 1.1.21-Jul24
02/27 10:25:59 yS1 check for lockfiles
02/27 10:25:59 yS1 locking the line
02/27 10:26:00 yS1 lowering DTR to reset Modem
02/27 10:26:00 yS1 send: \dATQ0V1H0[0d]
02/27 10:26:01 yS1 waiting for ``OK'' ** found **
02/27 10:26:01 yS1 send: ATS0=0Q0&D3&C1[0d]
02/27 10:26:01 yS1 waiting for ``OK'' ** found **
02/27 10:26:01 yS1 mdm_send: 'ATI'
02/27 10:26:01 yS1 USR Courier/Sportster V.34(+) detected
02/27 10:26:01 yS1 mdm_send: 'ATI3'
02/27 10:26:02 yS1 additional info: 'USRobotics Courier V.Everything'
02/27 10:26:02 yS1 mdm_send: 'AT+FCLASS=2.0' -> OK
02/27 10:26:02 yS1 mdm_send: 'AT+FAA=1;+FCR=1' -> OK
02/27 10:26:02 yS1 mdm_send: 'AT+FBO=1' -> OK
02/27 10:26:02 yS1 mdm_send: 'AT+FNR=1,1,1,0' -> OK
02/27 10:26:02 yS1 mdm_send: 'AT+FLI="49 115 xxxxxxxx"' -> OK
02/27 10:26:02 yS1 mdm_send: 'AT+FCC=1,5,0,2,0,0,0,0' -> OK
02/27 10:26:02 yS1 waiting...
02/27 11:10:32 yS1 wfr: waiting for ``RING''
02/27 11:10:32 yS1 send: ATA[0d]
02/27 11:10:32 yS1 waiting for ``CONNECT'' ** found **
02/27 11:10:46 yS1 send:
02/27 11:10:46 yS1 waiting for ``_'' ** found **
02/27 11:10:49 ##### data dev=ttyS1, pid=26584, caller='none',
conn='31200/ARQ', name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'
> Have you upgraded anything that could be related? Hardware or software.
The only thing I've added is a logger on /dev/ttyS0, but it's a hardware
logger, and thus shouldn't be affecting anything.
Clifford Kite
> Clifford Kite wrote:
>> Jeff Pratt <j...@pizza73.com> wrote:
>> You imply that the modem answers the incoming calls. Show us exact
>> copies of pppd and chat, or mgetty, debug logs including timestamps
>> (you neglected to say how pppd is started on your end).
> Sorry, I'd been informed that posting logs here was impolite. pppd is
Where did you hear that! I've been working the networking group
for years and no one ever said that. If they had then they would
have been given short shrift by me. Sometimes a simple problem can
be solved with a good narrative, but there is very often simply no
substitute for logged data.
> started by mgetty+sendfax using AutoPPP.
Okay.
> Snippet of /var/log/ppp.log showing one complete session (from a mac):
> Feb 27 11:10:49 hotwings pppd[26584]: pppd 2.3.11 started by a_ppp, uid 0
I guess the kernel is not one in a 2.4.0+ series. You need pppd 2.4.1
for those.
> Feb 27 11:10:49 hotwings pppd[26584]: Using interface ppp0
> Feb 27 11:10:49 hotwings pppd[26584]: Connect: ppp0 <--> /dev/ttyS1
> Feb 27 11:10:49 hotwings pppd[26584]: sent [LCP ConfReq id=0x1 <asyncmap
> 0x0> <auth pap> <magic 0x553aec66> <pcomp> <accomp>]
> Feb 27 11:10:49 hotwings pppd[26584]: rcvd [LCP ConfAck id=0x1 <asyncmap
> 0x0> <auth pap> <magic 0x553aec66> <pcomp> <accomp>]
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [LCP ConfReq id=0x25 <asyncmap
> 0x0> <magic 0xd1efa894> <pcomp> <accomp>]
> Feb 27 11:10:51 hotwings pppd[26584]: sent [LCP ConfAck id=0x25 <asyncmap
> 0x0> <magic 0xd1efa894> <pcomp> <accomp>]
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [PAP AuthReq id=0x1 user="carl"
> password=<hidden>]
> Feb 27 11:10:51 hotwings pppd[26584]: sent [PAP AuthAck id=0x1 "Login ok"]
The peer has been authenticated.
> Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfReq id=0x1 <addr
> 192.9.200.215> <compress VJ 0f 01>]
> Feb 27 11:10:51 hotwings pppd[26584]: sent [CCP ConfReq id=0x1 <deflate 15>
> <deflate(old#) 15> <bsd v1 15>]
Pppd requests CCP with three options, usually that's useless since not
many PPP implementations for other OSs support any of those CCP options.
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x25 <compress
> VJ 0f 00> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfNak id=0x25 <addr
> 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3 192.9.200.215>]
I take it that these DNS server IP addresses are okay.
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
> 00 00 00 00 02 04 00 00 03 03 01
> Feb 27 11:10:51 hotwings pppd[26584]: Unsupported protocol 'Appletalk
> Control Protocol' (0x8029) received
> Feb 27 11:10:51 hotwings pppd[26584]: sent [LCP ProtRej id=0x2 80 29 01 25
> 00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
This is a Protocol-Reject sent by pppd to the peer in response to it's
request for Appletalk Control Protocol.
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [LCP ProtRej id=0x26 80 fd 01 01
> 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
This is a Protocol-Reject from the peer regarding pppd's request for
CCP (deflate, bsd, ect.) above. You might as well add the pppd option
noccp and be done with it.
> Feb 27 11:10:51 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x26 <compress
> VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
> 192.9.200.215>]
> Feb 27 11:10:51 hotwings pppd[26584]: sent [IPCP ConfAck id=0x26 <compress
> VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
> 192.9.200.215>]
> Feb 27 11:10:53 hotwings pppd[26584]: rcvd [proto=0x8029] 01 25 00 11 01 06
> 00 00 00 00 02 04 00 00 03 03 01
Nothing unusual until this. At this point pppd had previously sent
the peer a Protocol-Reject for the Appletalk Control Protocol (0x8029)
and that should have been the end of that. The peer PPP implementation
is broken.
> Feb 27 11:10:53 hotwings pppd[26584]: Unsupported protocol 'Appletalk
> Control Protocol' (0x8029) received
> Feb 27 11:10:53 hotwings pppd[26584]: sent [LCP ProtRej id=0x3 80 29 01 25
> 00 11 01 06 00 00 00 00 02 04 00 00 03 03 01]
> Feb 27 11:10:53 hotwings pppd[26584]: rcvd [IPCP ConfReq id=0x27 <compress
> VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
> 192.9.200.215>]
> Feb 27 11:10:53 hotwings pppd[26584]: sent [IPCP ConfAck id=0x27 <compress
> VJ 0f 00> <addr 192.9.200.102> <ms-dns1 192.9.200.215> <ms-dns3
> 192.9.200.215>]
> Feb 27 11:10:54 hotwings pppd[26584]: sent [IPCP ConfReq id=0x1 <addr
> 192.9.200.215> <compress VJ 0f 01>]
> Feb 27 11:10:54 hotwings pppd[26584]: rcvd [IPCP ConfNak id=0x1 <compress
> VJ 0f 00>]
> Feb 27 11:10:54 hotwings pppd[26584]: sent [IPCP ConfReq id=0x2 <addr
> 192.9.200.215> <compress VJ 0f 00>]
> Feb 27 11:10:54 hotwings pppd[26584]: rcvd [IPCP ConfAck id=0x2 <addr
> 192.9.200.215> <compress VJ 0f 00>]
> Feb 27 11:10:54 hotwings pppd[26584]: found interface eth0 for proxy arp
> Feb 27 11:10:54 hotwings pppd[26584]: local IP address 192.9.200.215
> Feb 27 11:10:54 hotwings pppd[26584]: remote IP address 192.9.200.102
The PPP negotiations should be complete at this point, but the peer
still mindlessly asks for ACP 6 more times.
[...]
> Same login as seen in /var/log/mgetty.log.ttyS1:
> --
> 02/27 10:25:59 yS1 mgetty: experimental test release 1.1.21-Jul24
> 02/27 10:25:59 yS1 check for lockfiles
> 02/27 10:25:59 yS1 locking the line
> 02/27 10:26:00 yS1 lowering DTR to reset Modem
> 02/27 10:26:00 yS1 send: \dATQ0V1H0[0d]
> 02/27 10:26:01 yS1 waiting for ``OK'' ** found **
> 02/27 10:26:01 yS1 send: ATS0=0Q0&D3&C1[0d]
> 02/27 10:26:01 yS1 waiting for ``OK'' ** found **
> 02/27 10:26:01 yS1 mdm_send: 'ATI'
> 02/27 10:26:01 yS1 USR Courier/Sportster V.34(+) detected
> 02/27 10:26:01 yS1 mdm_send: 'ATI3'
> 02/27 10:26:02 yS1 additional info: 'USRobotics Courier V.Everything'
I'd suggest you try initializing this modem with AT&F1, which is
required by some USRs for the CRT/CTS hardware flow control that
mgetty expects by default.
> 02/27 10:26:02 yS1 mdm_send: 'AT+FCLASS=2.0' -> OK
> 02/27 10:26:02 yS1 mdm_send: 'AT+FAA=1;+FCR=1' -> OK
> 02/27 10:26:02 yS1 mdm_send: 'AT+FBO=1' -> OK
> 02/27 10:26:02 yS1 mdm_send: 'AT+FNR=1,1,1,0' -> OK
> 02/27 10:26:02 yS1 mdm_send: 'AT+FLI="49 115 xxxxxxxx"' -> OK
> 02/27 10:26:02 yS1 mdm_send: 'AT+FCC=1,5,0,2,0,0,0,0' -> OK
I'm not sure how FAX plays with a data connection, presumably you do.
> 02/27 10:26:02 yS1 waiting...
> 02/27 11:10:32 yS1 wfr: waiting for ``RING''
> 02/27 11:10:32 yS1 send: ATA[0d]
> 02/27 11:10:32 yS1 waiting for ``CONNECT'' ** found **
> 02/27 11:10:46 yS1 send:
> 02/27 11:10:46 yS1 waiting for ``_'' ** found **
> 02/27 11:10:49 ##### data dev=ttyS1, pid=26584, caller='none',
> conn='31200/ARQ', name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'
>> Have you upgraded anything that could be related? Hardware or software.
> The only thing I've added is a logger on /dev/ttyS0, but it's a hardware
> logger, and thus shouldn't be affecting anything.
Probably not.
Something other thoughts:
Take the options modem, crtscts, and lock out of /etc/ppp/options.
All that is handled by mgetty.
I saw no good reason in the logs for the PPP connection not to work,
although the continued ACP requests after a Protocol-Reject says that
the peer is broken in at least one respect. The question now arises
as to whether the peer has changed.
Does ifconfig show a large number of frame errors? If so then something
is likely wrong with flow control - DCE to DTE or DTE to DTE, or perhaps
the serial device or modem has gone bad on one side or the other.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* I gave up on politics when no matter who I voted for, I regretted it.
* -- Pepper...and Salt, WSJ */
Bill Unruh
]Hello All,
Sorry, your machines are obscure. The above is the info on the server (
the machine you dial up to) But in the last sentence you can not ping
the ppp server, which is this machine. What do you mean? You cannot ping
it from one of th edial up machines? Dos it dial in? What is the debug
output on the server, and on the machines dialing in. What is the route
-n output on the machines dialing in?
Bill Unruh
]Clifford Kite wrote:
The negotiation looks fine. Now what are the symptoms you complain of?
When you do
ping 192.9.200.102
what happens?
What does route -n say?
what does the log on the mac say?
Jeff Pratt
> In <y69f8.25083$DS6.7...@news2.telusplanet.net> Jeff Pratt
> <j...@pizza73.com> writes:
>
> ]Clifford Kite wrote:
>
> ]> Jeff Pratt <j...@pizza73.com> wrote:
> ]>
> ]>> I'm going right out of my skull on this one. I have a machine set up
> for ]>> 2 users to dial into. Single modem (real modem, external, 33.6),
> but we
> ]>> dial in at different times of the day. Everything was set up and
> working ]>> fine, with this config:
> ]>
> ]> [...]
> ]>
> ]>> BUT, nothing travels down the damned pipe!!!!!!!! I can no longer
> ]>> ping the ppp server, the nameserver, anything! Normally I'd just
> ]>> roll back whatever changes I'd made recently, but I haven't made any.
> ]>> Tripwire hasn't shown me anything changed either. Help...
> ]>
> ]> You've showed us configuration files and said they *were* working.
> ]> However you've already "gone right out of your skull" if you think
> ]> those alone will help us determine what the problem is that you
> ]> apparently now have.
> ]>
> ]> You imply that the modem answers the incoming calls. Show us exact
> ]> copies of pppd and chat, or mgetty, debug logs including timestamps
> ]> (you neglected to say how pppd is started on your end).
>
> ]Sorry, I'd been informed that posting logs here was impolite. pppd is
> ]started by mgetty+sendfax using AutoPPP.
>
<SNIP LOGS>
>
> ]
> ]> Have you upgraded anything that could be related? Hardware or
> software.
>
> ]The only thing I've added is a logger on /dev/ttyS0, but it's a hardware
> ]logger, and thus shouldn't be affecting anything.
>
> The negotiation looks fine. Now what are the symptoms you complain of?
> When you do
> ping 192.9.200.102
> what happens?
From my machine:
[jsp@jeff jsp]$ ping 192.9.200.102
PING 192.9.200.102 (192.9.200.102) from 192.9.200.121 : 56(84) bytes of
data.
--- 192.9.200.102 ping statistics ---
27 packets transmitted, 0 packets received, 100% packet loss
From the PPP server:
[root@hotwings /root]# ping 192.9.200.102
PING 192.9.200.102 (192.9.200.102) from 192.9.200.215 : 56(84) bytes of
data.
--- 192.9.200.102 ping statistics ---
19 packets transmitted, 0 packets received, 100% packet loss
> What does route -n say?
Client hung up before I could grab that. They'll be dialing back in in a
bit though...
> what does the log on the mac say?
Unfortunately I can't get ahold of that until they've been able to log in
successfully.
Thanks
Jeff
Bill Unruh
]Bill Unruh wrote:
]<SNIP LOGS>
When you do that , do you see the lights on the modem blink? (I assume
that hotwings is the Linux server which receives the call with mgetty)
Make sure you do
route -n next time. Also do ifconfig -a
Also make sure that you switch off all firewall software, to make sure
it is not getting in the way.
(you can switch it back on after the tests).
Make sure that you have IP Forwarding set up (on Redhat/mandrake in
/etc/sysconfig/network)
This should not make a difference in the peer to peer stuff.
Next time you do ping on your machine, also do
as root
tcpdump -i ppp0 -host hotwings
and see if packets are being sent out.
]> What does route -n say?