Fedora Core 1 apparent routing problems

Good day all;

You see, I have this probllem. I'm trying to get dialup networking
functional on a machine using Fedora Core 1. All the daemons and
connetion software is stock, off the disk that shipped with FC1.
Everything looks good, but...

I've narrowed it down to a routing problem. If I ping an IP, it just
sits there, happily sending packets, listening for returns that never
come. If I ping an address, it sits there, and after a moment or
three, comes back "host unreachable." So, routing problem, right?
Well, as you can see bu the results I have included here, the default
route looks like it is set up properly, and dissapears when I take
down my dialup connection.

Feel free to look at the included information and call me an idiot for
missing something obvious. I'm *not* a trained pro, just a jackleg
home network admin!
Also, I don't have any idea where the 169.254.0.0 route that is
connected to eth0 came from, I never set that up. My home lan (both
computers <grin>) is using 198.164.1.xxx.

Thanks

[root@birhat bin]# cat /var/log/messages
<snip>
Oct 6 10:20:01 birhat pppd[3081]: local IP address 142.166.169.169
Oct 6 10:20:01 birhat pppd[3081]: remote IP address 142.166.169.131
Oct 6 10:20:01 birhat pppd[3081]: primary DNS address 198.164.26.87
Oct 6 10:20:01 birhat pppd[3081]: secondary DNS address 207.179.152.58

[root@birhat bin]# cat /etc/resolv.conf
nameserver 198.164.26.87
nameserver 207.179.152.58

[root@birhat bin]# /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
142.166.169.131 * 255.255.255.255 UH 0 0
0 ppp0
198.168.1.0 * 255.255.255.0 U 0 0
0 eth0
169.254.0.0 * 255.255.0.0 U 0 0
0 eth0
127.0.0.0 * 255.0.0.0 U 0 0
0 lo
default 142.166.169.131 0.0.0.0 UG 0 0
0 ppp0


results from pinging slashdot.org
[root@birhat bin]# /usr/sbin/tcpdump -i ppp0
tcpdump: listening on ppp0
10:30:19.528833 142.166.169.169.32783 > 198.164.26.87.domain: 63315+
A? www.slashdot.org. (34) (DF)
10:30:24.547890 142.166.169.169.32784 > 207.179.152.58.domain: 63315+
A? www.slashdot.org. (34) (DF)
10:30:29.549100 142.166.169.169.32783 > 198.164.26.87.domain: 63315+
A? www.slashdot.org. (34) (DF)
10:30:34.559379 142.166.169.169.32784 > 207.179.152.58.domain: 63315+
A? www.slashdot.org. (34) (DF)
10:30:39.569250 142.166.169.169.32784 > 198.164.26.87.domain: 63316+
A? www.slashdot.org.home.ca. (42) (DF)
10:30:44.579063 142.166.169.169.32785 > 207.179.152.58.domain: 63316+
A? www.slashdot.org.home.ca. (42) (DF)

results from pinging nameserver via IP
[root@birhat bin]# /usr/sbin/tcpdump -i ppp0
tcpdump: listening on ppp0
10:32:17.166869 142.166.169.169 > 207.179.152.58: icmp: echo request
(DF)
10:32:18.179082 142.166.169.169 > 207.179.152.58: icmp: echo request
(DF)
10:32:19.179088 142.166.169.169 > 207.179.152.58: icmp: echo request
(DF)
10:32:20.179095 142.166.169.169 > 207.179.152.58: icmp: echo request
(DF)

C Stewart <(E-Mail Removed)> wrote:
> Good day all;

> You see, I have this probllem. I'm trying to get dialup networking
> functional on a machine using Fedora Core 1. All the daemons and
> connetion software is stock, off the disk that shipped with FC1.
> Everything looks good, but...

> I've narrowed it down to a routing problem. If I ping an IP, it just
> sits there, happily sending packets, listening for returns that never
> come. If I ping an address, it sits there, and after a moment or
> three, comes back "host unreachable." So, routing problem, right?

It does *sound* like you have no default route.

> Well, as you can see bu the results I have included here, the default
> route looks like it is set up properly, and dissapears when I take
> down my dialup connection.

> Feel free to look at the included information and call me an idiot for
> missing something obvious. I'm *not* a trained pro, just a jackleg
> home network admin!
> Also, I don't have any idea where the 169.254.0.0 route that is
> connected to eth0 came from, I never set that up. My home lan (both
> computers <grin>) is using 198.164.1.xxx.

>From RFC 3330 (Special-Use IPv4 Addresses):

169.254.0.0/16 - This is the "link local" block. It is allocated for
communication between hosts on a single link. Hosts obtain these
addresses by auto-configuration, such as when a DHCP server may not
be found.

But I have no idea why "Fedora Core 1" would automatically set up such
a network. I assume this is a regular landline connection. Does it
disappear when the dial-up connection is taken down?

> Thanks

> [root@birhat bin]# cat /var/log/messages
> <snip>
> Oct 6 10:20:01 birhat pppd[3081]: local IP address 142.166.169.169
> Oct 6 10:20:01 birhat pppd[3081]: remote IP address 142.166.169.131
> Oct 6 10:20:01 birhat pppd[3081]: primary DNS address 198.164.26.87
> Oct 6 10:20:01 birhat pppd[3081]: secondary DNS address 207.179.152.58

> [root@birhat bin]# cat /etc/resolv.conf
> nameserver 198.164.26.87
> nameserver 207.179.152.58

> [root@birhat bin]# /sbin/route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> 142.166.169.131 * 255.255.255.255 UH 0 0
> 0 ppp0
> 198.168.1.0 * 255.255.255.0 U 0 0
> 0 eth0
> 169.254.0.0 * 255.255.0.0 U 0 0
> 0 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0
> 0 lo
> default 142.166.169.131 0.0.0.0 UG 0 0
> 0 ppp0

You have the correct default route through the ppp0 interface, so it's
not a routing problem.

> results from pinging slashdot.org
> [root@birhat bin]# /usr/sbin/tcpdump -i ppp0
> tcpdump: listening on ppp0
> 10:30:19.528833 142.166.169.169.32783 > 198.164.26.87.domain: 63315+
> A? www.slashdot.org. (34) (DF)
> 10:30:24.547890 142.166.169.169.32784 > 207.179.152.58.domain: 63315+
> A? www.slashdot.org. (34) (DF)
> 10:30:29.549100 142.166.169.169.32783 > 198.164.26.87.domain: 63315+
> A? www.slashdot.org. (34) (DF)
> 10:30:34.559379 142.166.169.169.32784 > 207.179.152.58.domain: 63315+
> A? www.slashdot.org. (34) (DF)
> 10:30:39.569250 142.166.169.169.32784 > 198.164.26.87.domain: 63316+
> A? www.slashdot.org.home.ca. (42) (DF)
> 10:30:44.579063 142.166.169.169.32785 > 207.179.152.58.domain: 63316+
> A? www.slashdot.org.home.ca. (42) (DF)

DNS lookup fails.

> results from pinging nameserver via IP
> [root@birhat bin]# /usr/sbin/tcpdump -i ppp0
> tcpdump: listening on ppp0
> 10:32:17.166869 142.166.169.169 > 207.179.152.58: icmp: echo request
> (DF)
> 10:32:18.179082 142.166.169.169 > 207.179.152.58: icmp: echo request
> (DF)
> 10:32:19.179088 142.166.169.169 > 207.179.152.58: icmp: echo request
> (DF)
> 10:32:20.179095 142.166.169.169 > 207.179.152.58: icmp: echo request
> (DF)

I'd say you have either a pppd or device file configuration problem,
or a hardware problem - unless you are using a winmodem or relative
thereof and then all bets are off. A firewall could also cause such
a problem.

Sometimes using ATZ for modem initialization instead of, say, ATZ&F
(or F1 for a USR Sportster), can cause a problem. We might be able
to find some clue in the configurations for the modem and pppd, or
in the log messages for pppd and chat with the options debug and -v
added, respectively.

Adding the line

daemon.*;local2.* /var/log/ppp.log

to /etc/syslog.conf and then doing " killall -HUP syslogd " to make
syslogd reread that file will put all those messages into ppp.log .

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

In article <(E-Mail Removed) >, C Stewart wrote:
>I've narrowed it down to a routing problem. If I ping an IP, it just
>sits there, happily sending packets, listening for returns that never
>come. If I ping an address, it sits there, and after a moment or
>three, comes back "host unreachable." So, routing problem, right?

Not necessarily.

>Well, as you can see bu the results I have included here, the default
>route looks like it is set up properly, and dissapears when I take
>down my dialup connection.

What you show looks correct - you are getting the DNS addresses from
your ISP, via 'usepeerdns', so I'd have to think that's ok.

>Also, I don't have any idea where the 169.254.0.0 route that is
>connected to eth0 came from, I never set that up.

That's a b0rken feature that Red Hat decided to include, called
'zero-conf'. It's a windoze feature that allows sales critters who
meet in airport waiting areas to connect their PCs and trade p0rn
and viruses. I say it's broken, because the latest draft document
(draft-ietf-zeroconf-ipv4-linklocal-17.txt dated 8 July 2004)
specifically states that zero-conf should not be configured if a network
is found (para 1.9), but I guess Red Hat hasn't bothered to read that.
If you look in /etc/sysconfig/network-scripts/if-up, you'll find

# Add Zeroconf route.
if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" ]; then
ip route replace 169.254.0.0/16 dev ${REALDEVICE}
fi

So if you set NOZEROCONF=yes in the /etc/sysconfig/network configuration
file, this "feature" will be disabled.

>[root@birhat bin]# cat /var/log/messages

looks good

>[root@birhat bin]# cat /etc/resolv.conf

looks OK (addresses not verified)

>[root@birhat bin]# /sbin/route

Looks good. Use '/sbin/route -n' for now, so that you are not waiting
for the system to time out trying to look up the addresses.

>results from pinging slashdot.org
>[root@birhat bin]# /usr/sbin/tcpdump -i ppp0
>tcpdump: listening on ppp0
>10:30:19.528833 142.166.169.169.32783 > 198.164.26.87.domain: 63315+
>A? www.slashdot.org. (34) (DF)
>10:30:24.547890 142.166.169.169.32784 > 207.179.152.58.domain: 63315+
>A? www.slashdot.org. (34) (DF)

Your system tried to contact the name servers - no answer.

>results from pinging nameserver via IP
>[root@birhat bin]# /usr/sbin/tcpdump -i ppp0
>tcpdump: listening on ppp0

Not a valid test. Many people have put in firewall rules to block ping
because it has been abused so much. It's getting so that even testing
basic connectivity now requires creativity in devising tests. Try instead
to connect to specific IP addresses - www.slashdot.org is 66.35.250.151,
so try connecting to that. However, at this point, you probably won't
succeed.

A likely problem is that your firewall is blocking everything. As a
general rule, this is a good thing, but as you can see it has it's
drawbacks. Try the command '/sbin/iptables -L' to see what rules are
in place. I don't use Fedora, so I can't tell you how to use their
stupid GUI crap to configure the firewall. You might want to read the
Security-Quickstart-Redhat-HOWTO and see if that helps in doing it
manually. What I'm suspecting is that your rules are so tight,
nothing is allowed in/out the ppp0 interface.

Old guy

Hi Clifford,

In article <(E-Mail Removed)>, Clifford Kite wrote:

>> Also, I don't have any idea where the 169.254.0.0 route that is
>> connected to eth0 came from, I never set that up. My home lan (both
>> computers <grin>) is using 198.164.1.xxx.
>
>>From RFC 3330 (Special-Use IPv4 Addresses):
>
> 169.254.0.0/16 - This is the "link local" block. It is allocated for
> communication between hosts on a single link. Hosts obtain these
> addresses by auto-configuration, such as when a DHCP server may not
> be found.
>
>But I have no idea why "Fedora Core 1" would automatically set up such
>a network. I assume this is a regular landline connection. Does it
>disappear when the dial-up connection is taken down?

This was something Red Hat added to RH9, and it seens to be carried
forward into Fedora. 'zero-conf' or 'link local' hasn't received an
official RFC type blessing - it's in the 17th draft last I checked.
Some time between the seventh (23 August 2002) and twelfth (24 January
2004) drafts, they added section 1.9 which says that you 'should not'
configure a zero-conf address if the interface has a 'routable' address
which they seem to mean not 127.0.0.0 or 169.254.0.0 (in other words,
it does include RFC1918 addresses). Red Hat appears to have missed this
little fact. Also, the _concept_ of this "feature" is that it was
intended to be used only when your interface is using DHCP, _AND_ you
have been unable to find a dhcp server. Ah, well, how are the sales
weasels supposed to trade viruses in the airport waiting area?

Old guy

Thanks so far for all the good ideas folks. As for the *broken*
feature, I'll be shutting it off. To clarify something from an
earlier post, my modem is confirmed as a USR Sportster hardware modem.
One way I can tell, it has jumpers. <grin> That, and it's worked
fine with other flavors of Linux. Also, in regards to the firewall, I
know it's not a good idea for a "running" sustem, but I disabled it
while trying to get this to work. Odd, last time I had this may
problems was using an early version of Slackware with SLIP! In my day
sonny, we had to use slip and crank the computers by hand! As soon as
I get finished here, I'll reboot from Windoze and try some of these
ideas.

Thanks.

In article <(E-Mail Removed) >, C Stewart wrote:
>As for the *broken* feature, I'll be shutting it off.

It's OK - it's not hurting anything at this point, and because it's
on an interface that you control, it wouldn't be easy to exploit.

>To clarify something from an earlier post, my modem is confirmed as
>a USR Sportster hardware modem. One way I can tell, it has jumpers.
><grin> That, and it's worked fine with other flavors of Linux.

Sounds good. The manual says to use 'AT&F1' as the init string.

>Also, in regards to the firewall, I know it's not a good idea for a
>"running" sustem, but I disabled it while trying to get this to work.

OK. FC1 came out of the box not running very many public services,
so disabling the firewall for testing is much less risky than for
example Slackware 96.

>Odd, last time I had this may problems was using an early version of
>Slackware with SLIP! In my day sonny, we had to use slip and crank
>the computers by hand!

You had cranks??? We had to push them, and it was up hill, and snowing
and...

>As soon as I get finished here, I'll reboot from Windoze and try some
>of these ideas.

Do let us know. Hmmm, for jollies, see if you can find a copy of
tcptraceroute, which still depends on ICMP type 11 and type 3, but is
less likely to be blocked. Downright handy little application.

[compton ~]$ whatis tcptraceroute
tcptraceroute (8) - A traceroute implementation using TCP packets
[compton ~]$

http://michael.toren.net/code/tcptraceroute/

Old guy

Bugger it.... I've tried everything I, and many other people can
think of with no luck. It just doesn't want to work. Final step,
pull the ethernet card, and try to set up dialup that way. Bleugh!
Thanks for the tips though.