* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
@ 2004-10-15 16:33 ` Robert P. J. Day
2004-10-15 16:43 ` carlsonj
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Robert P. J. Day @ 2004-10-15 16:33 UTC (permalink / raw)
To: linux-ppp
On Fri, 15 Oct 2004, Robert P. J. Day wrote:
> host (10.1.1.96) <-> modem <-> teltone <-> embedded (10.1.1.97)
>
> on the embedded side, after PPP comes up, the routing table has a
> single entry:
>
> 10.1.1.97 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
crap. that first address should say 10.1.1.96, of course -- the host
on the *other* end of the link. sorry.
rday
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
2004-10-15 16:33 ` Robert P. J. Day
@ 2004-10-15 16:43 ` carlsonj
2004-10-15 16:52 ` Robert P. J. Day
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: carlsonj @ 2004-10-15 16:43 UTC (permalink / raw)
To: linux-ppp
Robert P. J. Day writes:
> host (10.1.1.96) <-> modem <-> teltone <-> embedded (10.1.1.97)
So, if I understand this right (it's still hard to figure what you've
done from the description provided):
- Connecting the embedded system (running an unknown version
of PPP) to a Windows box works fine.
- Connecting the embedded system (again, unknown PPP) to a
Linux box running pppd fails.
Assuming that's right, try "noccp" on the Linux box. I see that
you've negotiated CCP with the Deflate algorithm. That never would
have happened when talking to a Windows system, and it's possible that
one side or the other has bugs with data compression. The symptoms of
bugs there would be _exactly_ what you're now seeing.
--
James Carlson <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
2004-10-15 16:33 ` Robert P. J. Day
2004-10-15 16:43 ` carlsonj
@ 2004-10-15 16:52 ` Robert P. J. Day
2004-10-15 16:55 ` Bill Unruh
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Robert P. J. Day @ 2004-10-15 16:52 UTC (permalink / raw)
To: linux-ppp
On Fri, 15 Oct 2004 carlsonj@workingcode.com wrote:
> Robert P. J. Day writes:
> > host (10.1.1.96) <-> modem <-> teltone <-> embedded (10.1.1.97)
>
> So, if I understand this right (it's still hard to figure what you've
> done from the description provided):
sorry, i did try to provide enough detail regarding the configuration
of the host once the PPP link was apparently up:
> - Connecting the embedded system (running an unknown version
> of PPP) to a Windows box works fine.
yup. worked flawlessly.
> - Connecting the embedded system (again, unknown PPP) to a
> Linux box running pppd fails.
oops, yes, version numbers would have been useful, sorry. both
systems are running PPP 2.4.1. the embedded system is running a
2.4.22-pre8 kernel, while the host is running a 2.6.5 kernel.
> Assuming that's right, try "noccp" on the Linux box. I see that
> you've negotiated CCP with the Deflate algorithm. That never would
> have happened when talking to a Windows system, and it's possible that
> one side or the other has bugs with data compression. The symptoms of
> bugs there would be _exactly_ what you're now seeing.
ok, i'll give it a shot. one of the things we did was loaded the
"options" file on the host with every no-compression option we could
find, since we initially suspected a problem with compression. but
we'll try it with just that additional option, thanks.
since we have no /etc/ppp/options file on the embedded system (it's
all crammed onto the call to pppd), i'll stick that into the options
file on the host. i'll let you know. thanks.
rday
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (2 preceding siblings ...)
2004-10-15 16:52 ` Robert P. J. Day
@ 2004-10-15 16:55 ` Bill Unruh
2004-10-15 17:07 ` carlsonj
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Bill Unruh @ 2004-10-15 16:55 UTC (permalink / raw)
To: linux-ppp
On Fri, 15 Oct 2004, Robert P. J. Day wrote:
> the layout:
>
> host (10.1.1.96) <-> modem <-> teltone <-> embedded (10.1.1.97)
>
> on the embedded side, after PPP comes up, the routing table has a
> single entry:
>
> 10.1.1.97 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
Either your layout is wrong or this is wrong. 10.1.1.97 is the embedded
system itself. There is no entry in the routing table for the remote
host (.96) This may be a misprint on one of these lines.
The other possibility is that the firewall is running on the Fedora
system and is allowing nothing through.
It might help to publish the exact (not hand copied) logs from the pppd
negotiation of the Fedora box. --- all of them. YOu do not understand
what is wrong--> you do not know what is important and what is not.
Please do not edit the log. of the pppd negotiation.
>
> exactly what i would expect. no defaultroute, we don't need one.
>
> on the host side, the results of running various commands:
>
> ifconfig:
> ---------
>
> eth0 Link encap:Ethernet HWaddr 00:03:47:0A:BB:8E
> inet addr:10.1.1.91 Bcast:10.1.1.255 Mask:255.255.255.0
> inet6 addr: fe80::203:47ff:fe0a:bb8e/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2107928 errors:0 dropped:0 overruns:0 frame:0
> TX packets:11670 errors:1 dropped:0 overruns:0 carrier:1
> collisions:484 txqueuelen:1000
> RX bytes:291672739 (278.1 Mb) TX bytes:1330567 (1.2 Mb)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:4957 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4957 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:3350770 (3.1 Mb) TX bytes:3350770 (3.1 Mb)
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:10.1.1.96 P-t-P:10.1.1.97 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:552 Metric:1
> RX packets:9 errors:1 dropped:0 overruns:0 frame:0
> TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:411 (411.0 b) TX bytes:1497 (1.4 Kb)
>
Note that its address is .96 not.97. YOur embedded system has no way of
contacting this. There is no route to this host if I believe your route
command output.
> route -n:
> ---------
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.1.1.97 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 10.1.1.1 0.0.0.0 UG 0 0 0 eth0
>
> here's the excerpt from /var/log/messages:
> ------------------------------------------
>
> Oct 15 11:53:22 lgl mgetty[20364]: data dev=ttyS0, pid 364, caller='none', conn='33600/ARQ/V34/LAPM/V42BIS', name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'
> Oct 15 11:53:22 lgl pppd[20364]: pppd 2.4.1 started by a_ppp, uid 0
> Oct 15 11:53:22 lgl pppd[20364]: Using interface ppp0
> Oct 15 11:53:22 lgl pppd[20364]: Connect: ppp0 <--> /dev/ttyS0
> Oct 15 11:53:25 lgl pppd[20364]: Deflate (15) compression enabled
> Oct 15 11:53:25 lgl pppd[20364]: local IP address 10.1.1.96
> Oct 15 11:53:25 lgl pppd[20364]: remote IP address 10.1.1.97
>
> here's the syslog output for just pppd:
> ---------------------------------------
>
> Oct 15 12:03:56 lgl pppd[20364]: Terminating on signal 15.
> Oct 15 12:03:56 lgl pppd[20364]: Script /etc/ppp/ip-down started (pid 20527)
> Oct 15 12:03:56 lgl pppd[20364]: sent [LCP TermReq id=0x2 "User request"]
> Oct 15 12:03:56 lgl pppd[20364]: Script /etc/ppp/ip-down finished (pid 20527), status = 0x0
> Oct 15 12:03:59 lgl pppd[20364]: sent [LCP TermReq id=0x3 "User request"]
> Oct 15 12:04:02 lgl pppd[20364]: Connection terminated.
> Oct 15 12:04:02 lgl pppd[20364]: Connect time 10.6 minutes.
> Oct 15 12:04:02 lgl pppd[20364]: Sent 1497 bytes, received 411 bytes.
> Oct 15 12:04:03 lgl pppd[20364]: Exit.
> Oct 15 12:04:48 lgl pppd[20556]: pppd 2.4.1 started by a_ppp, uid 0
> Oct 15 12:04:48 lgl pppd[20556]: using channel 55
> Oct 15 12:04:48 lgl pppd[20556]: Using interface ppp0
> Oct 15 12:04:48 lgl pppd[20556]: Connect: ppp0 <--> /dev/ttyS0
> Oct 15 12:04:48 lgl pppd[20556]: sent [LCP ConfReq id=0x1 <mru 552> <asyncmap 0x0> <magic 0xe9238fde> <pcomp> <accomp>]
> Oct 15 12:04:48 lgl pppd[20556]: rcvd [LCP ConfAck id=0x1 <mru 552> <asyncmap 0x0> <magic 0xe9238fde> <pcomp> <accomp>]
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf687cd39> <pcomp> <accomp>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xf687cd39> <pcomp> <accomp>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [IPCP ConfReq id=0x1 <addr 10.1.1.96> <compress VJ 0f 01>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
Put noccp into /etc/ppp/options.
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [IPCP ConfNak id=0x1 <addr 10.1.1.97>]
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [IPCP ConfAck id=0x1 <addr 10.1.1.96> <compress VJ 0f 01>]
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15>]
> Oct 15 12:04:51 lgl pppd[20556]: Deflate (15) compression enabled
> Oct 15 12:04:51 lgl pppd[20556]: rcvd [IPCP ConfReq id=0x2 <addr 10.1.1.97> <compress VJ 0f 01>]
> Oct 15 12:04:51 lgl pppd[20556]: sent [IPCP ConfAck id=0x2 <addr 10.1.1.97> <compress VJ 0f 01>]
> Oct 15 12:04:51 lgl pppd[20556]: local IP address 10.1.1.96
> Oct 15 12:04:51 lgl pppd[20556]: remote IP address 10.1.1.97
> Oct 15 12:04:51 lgl pppd[20556]: Script /etc/ppp/ip-up started (pid 20585)
> Oct 15 12:04:51 lgl pppd[20556]: Script /etc/ppp/ip-up finished (pid 20585), status = 0x0
>
>
> anything here look suspicious? we're baffled by the fact that the
> actual PPP activation seems fine, but once the link is up, we get
> nothing. i can provide more info, of course, if it's necessary, but
> to start, does any of the host-side configuration look out of sorts?
> we've had three different people looking at this, and no one can see
> anything odd.
As I said, your routing may be wrong, or your firewall may be blocking
everything.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (3 preceding siblings ...)
2004-10-15 16:55 ` Bill Unruh
@ 2004-10-15 17:07 ` carlsonj
2004-10-15 18:45 ` Robert P. J. Day
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: carlsonj @ 2004-10-15 17:07 UTC (permalink / raw)
To: linux-ppp
Robert P. J. Day writes:
> > Assuming that's right, try "noccp" on the Linux box. I see that
> > you've negotiated CCP with the Deflate algorithm. That never would
> > have happened when talking to a Windows system, and it's possible that
> > one side or the other has bugs with data compression. The symptoms of
> > bugs there would be _exactly_ what you're now seeing.
>
> ok, i'll give it a shot. one of the things we did was loaded the
> "options" file on the host with every no-compression option we could
> find, since we initially suspected a problem with compression. but
> we'll try it with just that additional option, thanks.
There are really only a couple of master options that control
compression:
noaccomp Disables HDLC address/control compression.
When that compression mode is enabled, it
saves 2 bytes per packet.
nopcomp Disables PPP Protocol Field compression. When
enabled, it saves 1 byte per data packet.
novj Disables VJ TCP/IP header compression. When
enabled, it can save around 38 bytes per
packet.
noccp Disables CCP data compression. These are the
complex user data compression algorithms.
Most are around a 50% compression ratio.
The first three are just header compression schemes and (except
perhaps with VJ compression) rarely run into trouble. The last one is
the complex one, which uses a wide range of compression algorithms on
the user data. Think of it as being like "gzip" or "compress," but
applied a packet at a time. Bugs in various implementations are not
exactly unknown. :-/
So, boiling that all down, "novj noccp" is the standard recipe to use
when one suspects that compression is running awry.
The rest of the options control the details of how compression
operates. They normally shouldn't be touched, and turning them off
probably doesn't do what you want.
> since we have no /etc/ppp/options file on the embedded system (it's
> all crammed onto the call to pppd), i'll stick that into the options
> file on the host. i'll let you know. thanks.
It just needs to be configured on one side.
--
James Carlson <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (4 preceding siblings ...)
2004-10-15 17:07 ` carlsonj
@ 2004-10-15 18:45 ` Robert P. J. Day
2004-10-15 18:55 ` carlsonj
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Robert P. J. Day @ 2004-10-15 18:45 UTC (permalink / raw)
To: linux-ppp
On Fri, 15 Oct 2004 carlsonj@workingcode.com wrote:
> Robert P. J. Day writes:
> > host (10.1.1.96) <-> modem <-> teltone <-> embedded (10.1.1.97)
>
> So, if I understand this right (it's still hard to figure what you've
> done from the description provided):
>
> - Connecting the embedded system (running an unknown version
> of PPP) to a Windows box works fine.
>
> - Connecting the embedded system (again, unknown PPP) to a
> Linux box running pppd fails.
>
> Assuming that's right, try "noccp" on the Linux box. I see that
> you've negotiated CCP with the Deflate algorithm. That never would
> have happened when talking to a Windows system, and it's possible that
> one side or the other has bugs with data compression. The symptoms of
> bugs there would be _exactly_ what you're now seeing.
well, we're making progress, although not the way i would have liked.
as a simple test, we just hooked up the serial ports of the systems
direct connect with a serial cable, and PPP worked just dandy.
putting the modems back in the circuit re-introduced the problem. so
it could be the modems or the initialization strings we're using.
back to the drawing board ...
rday
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (5 preceding siblings ...)
2004-10-15 18:45 ` Robert P. J. Day
@ 2004-10-15 18:55 ` carlsonj
2004-10-15 19:52 ` Robert P. J. Day
2004-10-15 20:25 ` carlsonj
8 siblings, 0 replies; 10+ messages in thread
From: carlsonj @ 2004-10-15 18:55 UTC (permalink / raw)
To: linux-ppp
Robert P. J. Day writes:
> well, we're making progress, although not the way i would have liked.
> as a simple test, we just hooked up the serial ports of the systems
> direct connect with a serial cable, and PPP worked just dandy.
>
> putting the modems back in the circuit re-introduced the problem. so
> it could be the modems or the initialization strings we're using.
> back to the drawing board ...
That certainly points in a different direction. One possibility is
that you're running into flow control problems or transparency issues
with the modems.
If they're like USR modems, then "AT&F1" usually does the trick. If
they're not, then see the manual. :-/
Two things to try: "asyncmap 0xa0000" and "noasyncmap". The former
will escape XON/XOFF characters, on the theory that the modems are
eating those characters by default. The latter will escape all
control characters.
--
James Carlson <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (6 preceding siblings ...)
2004-10-15 18:55 ` carlsonj
@ 2004-10-15 19:52 ` Robert P. J. Day
2004-10-15 20:25 ` carlsonj
8 siblings, 0 replies; 10+ messages in thread
From: Robert P. J. Day @ 2004-10-15 19:52 UTC (permalink / raw)
To: linux-ppp
On Fri, 15 Oct 2004 carlsonj@workingcode.com wrote:
> Robert P. J. Day writes:
> > well, we're making progress, although not the way i would have liked.
> > as a simple test, we just hooked up the serial ports of the systems
> > direct connect with a serial cable, and PPP worked just dandy.
> >
> > putting the modems back in the circuit re-introduced the problem. so
> > it could be the modems or the initialization strings we're using.
> > back to the drawing board ...
>
> That certainly points in a different direction. One possibility is
> that you're running into flow control problems or transparency issues
> with the modems.
>
> If they're like USR modems, then "AT&F1" usually does the trick.
you are the man. i can't believe it was nothing more than turning on
HW flow control. grrrrr .....
rday
p.s. but on the bright side, i know a lot more about PPP now. :-P
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: absolutely baffled as to why PPP link doesn't allow pings
2004-10-15 16:28 absolutely baffled as to why PPP link doesn't allow pings Robert P. J. Day
` (7 preceding siblings ...)
2004-10-15 19:52 ` Robert P. J. Day
@ 2004-10-15 20:25 ` carlsonj
8 siblings, 0 replies; 10+ messages in thread
From: carlsonj @ 2004-10-15 20:25 UTC (permalink / raw)
To: linux-ppp
Robert P. J. Day writes:
> you are the man. i can't believe it was nothing more than turning on
> HW flow control. grrrrr .....
>
> rday
>
> p.s. but on the bright side, i know a lot more about PPP now. :-P
Good to hear that it's working.
Yes, it'd be nice if such things were easier to debug and (with better
tools) less likely to happen.
--
James Carlson <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread