absolutely baffled as to why PPP link doesn't allow pings

absolutely baffled as to why PPP link doesn't allow pings

[Robert P. J. Day]

  ok, a little more detail on a problem that's driving us totally nuts
here.  we have a small embedded system that dials out via an onboard
modem.

  when we connect the onboard modem to the actual telephone system and
dial into a modem pool in another building here, everything works just
fine.  the remote host runs (i *believe*) some variation of windows,
but no one here seems quite sure.  however, the important thing is
that the dialing takes place, the PPP interface comes up, and "ping"
to the remote host actually works -- that's what we're after.

  after that's established, we disconnect the embedded system from the
phone system and plug it into a teltone box, which is further
connected to another modem, then into a test host running fedora core
2.  then we simplify the call to "pppd" to remove *all* authentication
(details to follow).  start PPP on the embedded system, and everything
seems to go swimmingly.  ring, ring, ring, hiss, PPP is established,
interface comes up on both sides, both sides recognize the other side
with the correct IP address and ... nothing.  ping hangs totally when
run on either host.

  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

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)

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>]
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.

  help?

rday

Re: absolutely baffled as to why PPP link doesn't allow pings

[Robert P. J. Day]

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

Re: absolutely baffled as to why PPP link doesn't allow pings

[carlsonj]

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>

Re: absolutely baffled as to why PPP link doesn't allow pings

[Robert P. J. Day]

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

Re: absolutely baffled as to why PPP link doesn't allow pings

[Bill Unruh]

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. 

Re: absolutely baffled as to why PPP link doesn't allow pings

[carlsonj]

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>

Re: absolutely baffled as to why PPP link doesn't allow pings

[Robert P. J. Day]

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

Re: absolutely baffled as to why PPP link doesn't allow pings

[carlsonj]

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>

Re: absolutely baffled as to why PPP link doesn't allow pings

[Robert P. J. Day]

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

Re: absolutely baffled as to why PPP link doesn't allow pings

[carlsonj]

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>