Very Computer

by **Kevi** » Fri, 28 Jun 2002 04:26:58

I recently moved and I'd like to set up a PPP link for internet
service while I wait for my DSL service to be installed at the
new location. I'd like to make ppp0 my default route (and
gateway?), but I haven't been able to do that. If you think you
can point me in the right direction, then details follow.

My Mandrake 8.0, 2.4.8 kernel'd machine has two ethernet cards.
eth0 is on 123.456.212.41 and eth1 is 192.168.blah.blah.

Here's what I've managed to get working.

- I removed the default route through 123.456.212.41 since my
version of pppd won't install ppp0 as the default route if a
default route already exits.

- I started pppd using Gnome ppp and had pppd set up ppp0 as the
default route. My routing table looks like this with ppp
running:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
123.456.7.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
123.456.212.0 0.0.0.0 255.255.252.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 123.456.7.4 0.0.0.0 UG 0 0 0 ppp0

Yes, I know there's a 252 in my netmask. It's supposed to be
like that on the network in question.

My trouble is that I can't get any traffic to traverse the ppp0
link. I get 100% packet loss when pinging to 123.456.7.4.
If I try a traceroute, it doesn't seem to work

traceroute to 123.456.116.137 (123.456.116.137), 30 hops max, 38 byte packets
1 * *
etc...

traceroute to 123.456.7.4 (123.456.7.4), 30 hops max, 38 byte packets
1 * * *
2 * *
etc...

ppp thinks it's working:

myhost kernel: CSLIP: code copyright 1989 Regents of the University of California
myhost kernel: PPP generic driver version 2.4.1
myhost pppd[32522]: pppd 2.4.1 started by kevinc, uid 11334
myhost pppd[32522]: Serial connection established.
myhost pppd[32522]: Using interface ppp0
myhost pppd[32522]: Connect: ppp0 <--> /dev/ttyS0
myhost kernel: PPP BSD Compression module registered
myhost kernel: PPP Deflate Compression module registered
myhost pppd[32522]: local IP address 123.456.212.41
myhost pppd[32522]: remote IP address 123.456.7.4
myhost pppd[32522]: Terminating on signal 15.
myhost pppd[32522]: Connection terminated.
myhost pppd[32522]: Connect time 2.1 minutes.
myhost pppd[32522]: Sent 889 bytes, received 116 bytes.
myhost pppd[32522]: Exit.

What else can I try? I think I'm very close to having this
working.

Many thanks....

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

by **Clifford Kit** » Fri, 28 Jun 2002 08:28:12

> - I started pppd using Gnome ppp and had pppd set up ppp0 as the
> default route. My routing table looks like this with ppp
> running:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 123.456.7.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 123.456.212.0 0.0.0.0 255.255.252.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 123.456.7.4 0.0.0.0 UG 0 0 0 ppp0

The 123.456.x.x IP addresses are bogus. The largest positive decimal
integer in any of the 4 parts of an IP address is 255 (maybe 254 -
I don't really know which). If you used bogus IP addresses in the pppd
IP address option then you can't expect to do much, even if the PPP
provider is so broken as to accept them.

If you were silly and made these up to hide the real IP addresses then
add the pppd debug option and find and post an exact copy, not a hand
copy, of the PPP link negotiations with timestamps. These should be
in some file in /var/log - which file depends on how /etc/syslogd.conf
is configured.

--

PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* Speak softly and carry a +6 two-handed sword. */

by **Kevi** » Fri, 28 Jun 2002 08:52:40

Quote:> The 123.456.x.x IP addresses are bogus. The largest positive decimal
> integer in any of the 4 parts of an IP address is 255 (maybe 254 -
> I don't really know which). If you used bogus IP addresses in the pppd
> IP address option then you can't expect to do much, even if the PPP
> provider is so broken as to accept them.

> If you were silly and made these up to hide the real IP addresses then
> add the pppd debug option and find and post an exact copy, not a hand
> copy, of the PPP link negotiations with timestamps. These should be
> in some file in /var/log - which file depends on how /etc/syslogd.conf
> is configured.

I think you'll find that this is essentially the same as
before; only the IP addresses were changed in the
original picture.

Jun 25 21:47:55 joseph kernel: CSLIP: code copyright 1989 Regents of the University of California
Jun 25 21:47:56 joseph kernel: PPP generic driver version 2.4.1
Jun 25 21:47:56 joseph pppd[32522]: pppd 2.4.1 started by kevinc, uid 11334
Jun 25 21:48:30 joseph pppd[32522]: Serial connection established.
Jun 25 21:48:30 joseph pppd[32522]: Using interface ppp0
Jun 25 21:48:30 joseph pppd[32522]: Connect: ppp0 <--> /dev/ttyS0
Jun 25 21:48:39 joseph kernel: PPP BSD Compression module registered
Jun 25 21:48:39 joseph kernel: PPP Deflate Compression module registered
Jun 25 21:48:40 joseph pppd[32522]: local IP address 128.181.212.41
Jun 25 21:48:40 joseph pppd[32522]: remote IP address 128.181.7.4
Jun 25 21:50:31 joseph pppd[32522]: Terminating on signal 15.
Jun 25 21:50:31 joseph pppd[32522]: Connection terminated.
Jun 25 21:50:31 joseph pppd[32522]: Connect time 2.1 minutes.
Jun 25 21:50:31 joseph pppd[32522]: Sent 889 bytes, received 116 bytes.
Jun 25 21:50:31 joseph pppd[32522]: Exit.

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
128.181.7.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
128.181.212.0 0.0.0.0 255.255.252.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 128.181.7.4 0.0.0.0 UG 0 0 0 ppp0

eth0 Link encap:Ethernet HWaddr 00:A0:CC:59:82:5E
inet addr:128.181.212.41 Bcast:128.181.215.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:34001 dropped:0 overruns:0 carrier:68002
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:15 Base address:0xe000

eth1 Link encap:Ethernet HWaddr 00:A0:24:B5:22:DB
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:11619 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:1998468 (1.9 Mb)
Interrupt:15 Base address:0xd800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:30229 errors:0 dropped:0 overruns:0 frame:0
TX packets:30229 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2570585 (2.4 Mb) TX bytes:2570585 (2.4 Mb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:128.181.212.41 P-t-P:128.181.7.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
RX packets:9 errors:3 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:100 (100.0 b) TX bytes:2933 (2.8 Kb)

Thanks....

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

by **Clifford Kit** » Fri, 28 Jun 2002 12:19:29

> I think you'll find that this is essentially the same as
> before; only the IP addresses were changed in the
> original picture.

Yes, they are essentially the same. But pppd seems to get the local
address, 128.182.212.41, from the eth0 interface. That's not usual for
a dynamic IP address assignment by the ISP which is the most common PPP
connection to an ISP. Does the ISP know you are going to use that as
a local one for a PPP connection? There should be a prior agreement
with the ISP that a static local IP address will be used for the PPP
connection.

If the ISP is accepting that local IP address and shouldn't be doing
so then you can add the pppd noipdefault option to force the ISP to
supply the local IP address.

Quote:> Jun 25 21:47:55 joseph kernel: CSLIP: code copyright 1989 Regents of the University of California
> Jun 25 21:47:56 joseph kernel: PPP generic driver version 2.4.1
> Jun 25 21:47:56 joseph pppd[32522]: pppd 2.4.1 started by kevinc, uid 11334
> Jun 25 21:48:30 joseph pppd[32522]: Serial connection established.
> Jun 25 21:48:30 joseph pppd[32522]: Using interface ppp0
> Jun 25 21:48:30 joseph pppd[32522]: Connect: ppp0 <--> /dev/ttyS0
> Jun 25 21:48:39 joseph kernel: PPP BSD Compression module registered
> Jun 25 21:48:39 joseph kernel: PPP Deflate Compression module registered
> Jun 25 21:48:40 joseph pppd[32522]: local IP address 128.181.212.41
> Jun 25 21:48:40 joseph pppd[32522]: remote IP address 128.181.7.4
> Jun 25 21:50:31 joseph pppd[32522]: Terminating on signal 15.
> Jun 25 21:50:31 joseph pppd[32522]: Connection terminated.
> Jun 25 21:50:31 joseph pppd[32522]: Connect time 2.1 minutes.
> Jun 25 21:50:31 joseph pppd[32522]: Sent 889 bytes, received 116 bytes.
> Jun 25 21:50:31 joseph pppd[32522]: Exit.

The time-sequencing seems about right, as far as the log goes.

This still doesn't show the PPP negotiation messages resulting from the
pppd debug option. My signature contains a recipe for creating a log file
with those messages if you can't find them in a file in /var/log (e.g.,
syslog, messages, debug). That can tell us more about what is negotiated
that might cause trouble. It might be well to add the chat -v option too.
Well, if "Gnome ppp" uses chat anyway. It may not.

A list of pppd options that you use would also be useful.

Quote:> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 128.181.7.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 128.181.212.0 0.0.0.0 255.255.252.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 128.181.7.4 0.0.0.0 UG 0 0 0 ppp0

The PPP routing looks okay.

Quote:> eth0 Link encap:Ethernet HWaddr 00:A0:CC:59:82:5E
> inet addr:128.181.212.41 Bcast:128.181.215.255 Mask:255.255.252.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:34001 dropped:0 overruns:0 carrier:68002
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Interrupt:15 Base address:0xe000
> eth1 Link encap:Ethernet HWaddr 00:A0:24:B5:22:DB
> inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:11619 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:1998468 (1.9 Mb)
> Interrupt:15 Base address:0xd800
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:30229 errors:0 dropped:0 overruns:0 frame:0
> TX packets:30229 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:2570585 (2.4 Mb) TX bytes:2570585 (2.4 Mb)
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:128.181.212.41 P-t-P:128.181.7.4 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1

I suspect that "mtu 296" is a pppd option and suggest removing it.

Quote:> RX packets:9 errors:3 dropped:0 overruns:0 frame:0

Nothing unusual about 3 RX errors, that could be a result of a text
lead-in by the ISP on connection.

Quote:> TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:100 (100.0 b) TX bytes:2933 (2.8 Kb)

You are getting something back from the peer. Maybe tcpdump could show
you what the peer is sending and shed some light on the problem.

PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* Recipe for a unified PPP debug log file: Add the line
" local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
(may need Tab separators) to the /etc/syslog.conf file, and then do
" kill -HUP `pidof syslogd` " to make syslogd reread it. */

by **Kevi** » Sun, 30 Jun 2002 08:36:34

ck> Yes, they are essentially the same. But pppd seems to get the local
ck> address, 128.182.212.41, from the eth0 interface. That's not usual for
ck> a dynamic IP address assignment by the ISP which is the most common PPP
ck> connection to an ISP. Does the ISP know you are going to use that as
ck> a local one for a PPP connection? There should be a prior agreement
ck> with the ISP that a static local IP address will be used for the PPP
ck> connection.

The static IP address was part of the problem. I should
have used noipdefault in the options to prevent ppp0 from
subsuming the eth0 address.

ck> If the ISP is accepting that local IP address and shouldn't be doing
ck> so then you can add the pppd noipdefault option to force the ISP to
ck> supply the local IP address.

Done & it worked.

ck> This still doesn't show the PPP negotiation messages resulting from the
ck> pppd debug option. My signature contains a recipe for creating a log file
ck> with those messages if you can't find them in a file in /var/log (e.g.,
ck> syslog, messages, debug). That can tell us more about what is negotiated
ck> that might cause trouble. It might be well to add the chat -v option too.
ck> Well, if "Gnome ppp" uses chat anyway. It may not.

Found the messages, but I like your syslog recipe.

ck> A list of pppd options that you use would also be useful.

Now using: defaultroute lock name kevinc noipdefault

kc> ppp0 Link encap:Point-to-Point Protocol
kc> inet addr:128.181.212.41 P-t-P:128.181.7.4 Mask:255.255.255.255
kc> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
>
ck> I suspect that "mtu 296" is a pppd option and suggest removing it.

Done. Now I get:

ppp0 Link encap:Point-to-Point Protocol
inet addr:128.181.7.177 P-t-P:128.181.7.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:42 (42.0 b) TX bytes:63 (63.0 b)

kc> RX packets:9 errors:3 dropped:0 overruns:0 frame:0
>
ck> Nothing unusual about 3 RX errors, that could be a result of a text
ck> lead-in by the ISP on connection.

Fine.

kc> TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
kc> collisions:0 txqueuelen:3
kc> RX bytes:100 (100.0 b) TX bytes:2933 (2.8 Kb)
>
ck> You are getting something back from the peer. Maybe tcpdump could show
ck> you what the peer is sending and shed some light on the problem.

It's working better now, so tcpdump should reflect that.
I didn't look before dinking with the ppp options though.

ck> PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/

Very nice HOWTO there!

ck> /* Recipe for a unified PPP debug log file: Add the line
ck> " local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
ck> (may need Tab separators) to the /etc/syslog.conf file, and then do
ck> " kill -HUP `pidof syslogd` " to make syslogd reread it. */

Nice recipe. Thanks....

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

by **Kevi** » Sun, 30 Jun 2002 08:37:53

bill> Yes but as Clifford Kite pointed out to you, you have the
bill> same IP address on eth0 and ppp0, and this is breaking
bill> things - badly.

I'm sure that's the main culprit!

bill> This looks like a laptop that uses the eth0 interface at
bill> work, and you are dialing in to the company terminal server
bill> from home. This type situation ALWAYS makes for networking
bill> nightmares.

Actually it's a deskside machine that got caught up in a
move recently. I just got my DSL line working again today.

kc>eth0 Link encap:Ethernet HWaddr 00:A0:CC:59:82:5E
kc> inet addr:128.181.212.41 Bcast:128.181.215.255 Mask:255.255.252.0
kc> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
kc> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
kc> TX packets:0 errors:34001 dropped:0 overruns:0 carrier:68002

bill> Notice, your box thinks that it can reach hosts on this
bill> network, and is trying to, but because the cable is
bill> unplugged - you are going nowhere. Thus, a ping to your
bill> desktop box, or any other system on this subnet is going to
bill> try this interface, and ignore the ppp0 interface.

Got it.

kc>eth1 Link encap:Ethernet HWaddr 00:A0:24:B5:22:DB
kc> inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
kc> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
kc> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
kc> TX packets:11619 errors:0 dropped:0 overruns:0 carrier:0
kc> collisions:0 txqueuelen:100
kc> RX bytes:0 (0.0 b) TX bytes:1998468 (1.9 Mb)

bill> Sent out 1.9 Megs, got nothing back? You have another
bill> problem here, but it's not related.

The problem again is move related. There is no other
equipment* on that port.

kc>ppp0 Link encap:Point-to-Point Protocol
kc> inet addr:128.181.212.41 P-t-P:128.181.7.4 Mask:255.255.255.255

bill> So, anything you send out here (such as a ping, traceroute,
bill> or an attempt to log in to your POP server) is going to
bill> break, because all of the replies are being sent to the
bill> network jack in your office.

Makes sense, once modified for the "move" rather than "home
vs. office" context.

bill> Solutions:
bill>
bill> 1. Take down the eth0 interface when at home.
bill> 2. Add 'noipdefault' as Clifford Kite says.

The 'noipdefault' option worked. What I'm really hoping to
do in the long run is to have both eth0 and ppp0 up at the
same time and route different groups of traffic to each of
them. This is what I was starting with a year ago, the last
time it was important to me.

route add default gw 4.54.72.19 metric 0 ppp0
route add default gw 128.181.212.1 metric 1 eth0

I'm under the impression that the lower metric count of ppp0
would favor that port over eth0.

Thanks for the help!

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

by **Clifford Kit** » Mon, 01 Jul 2002 01:31:03

> The 'noipdefault' option worked. What I'm really hoping to
> do in the long run is to have both eth0 and ppp0 up at the
> same time and route different groups of traffic to each of
> them. This is what I was starting with a year ago, the last
> time it was important to me.
> route add default gw 4.54.72.19 metric 0 ppp0
> route add default gw 128.181.212.1 metric 1 eth0
> I'm under the impression that the lower metric count of ppp0
> would favor that port over eth0.

Yes, but you can't route different groups of traffic with just a metric
change - the metric 0 interface will rule all the time. That will
require delving into iproute2 and perhaps traffic control, reading such
things as the Adv-Routing-HOWTO, and tc documentation such as found here:

http://lartc.org/HOWTO/cvs/2.4routing/lartc.html.

--

PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/

Very Computer

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?

ppp0, eth0 & eth1 ROUTING troubles?