[lug] Newbie tries to make laptop modem work
D. Stimits
stimits at idcomm.com
Thu Dec 6 13:34:31 MST 2001
Glenn Murray wrote:
>
> On Wed, 5 Dec 2001, D. Stimits wrote:
> > If you just run wvdial at a prompt and not background it, it will appear
> > to just sit there once you are connected; the connection dies when you
> > kill the prompt program. So run it in the background instead:
> > wvdial whatever &
> > (notice ampersand '&')
> >
> > Now if you still can't get in/out, it means you have not attached a
> > route to the device, preferably a default route. Try checking the output
> > of "route" both before and after the connection. Don't know kppp, can't
> > comment on it.
I'm no network guru, but some of this seems to make more sense now, I'll
take a stab at it. Consider I might have a serious flaw in my arguments
at any point. Also, I forget if you are using redhat or something else,
if I give a file name, it might be a redhat-ism that doesn't apply
exactly to you.
>
> So I tried the ff:
>
> glenn at puck:glenn/$ sudo route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> localnet * 255.255.192.0 U 0 0 0 eth0
> default 138.67.1.1 0.0.0.0 UG 1 0 0 eth0
> default 138.67.1.1 0.0.0.0 UG 1 0 0 eth0
Somehow you have 2 default routes assigned to a single ethernet
card...shouldn't be so. Don't know what it means to have it listed
twice, but it doesn't seem "wise". Let me start by comparing with my
machine with ppp NOT connected. I have an internal network on 10.0.0.0,
which has associated a netmask of 255.0.0.0 (it responds to anything
from 10.0.0.0 to 10.255.255.255), but note that probably my "U" flag
should be "UG", but it doesn't seem to matter:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
It appears your loopback, lo, is missing! Now, it might work perfectly
fine with the localnet destination, but that means all traffic on this
one machine, that is bound to go to *itself*, is traveling through the
ethernet card (big waste, local machine traffic saturating its own
ethernet). You need 127.0.0.0 and netmask of 255.0.0.0 on it. Try a
route command (manually, don't put it permanently in any files unless it
works):
route add -net 127.0.0.0
(this should automatically set the mask)
Now run route again, see if you get a 127.0.0.0 entry with Iface lo. As
an afterthought, see what happens *before* you do this with a traceroute
127.0.0.1, and again do a traceroute after this. Compare if the route
used to go through the ethernet to get to 127.0.0.1, and then if it goes
directly. It should be a single hope directly to 127.0.0.1.
Incidentally, unless 138.67.1.1 itself has a gateway or some means of
forwarding your machine to the internet, it should *NOT* be a default,
it should just be a net. With that as a default, everything that does
not have a specific route assigned to it will attempt to reach its
destination through 138.67.1.1. This is a problem if 138.67.1.1 is
anything less than a network that can figure out where to send packets
bound for anywhere. The situation of an internal network should list
that network, but it should not be default...the mask and the
destination will determine if a packet goes there. A ppp connection will
automatically add a default that points at the remote connection point
as a host. Here is my route output after I connect via ppp (I'm chopping
out "Metric", "Ref", and "Use" to avoid line wrapping in email, all
entries there are "0"):
Kernel IP routing table
Destination Gateway Genmask Flags Iface
pm3-k56-1.idcom * 255.255.255.255 UH ppp0
10.0.0.0 * 255.0.0.0 U eth0
127.0.0.0 * 255.0.0.0 U lo
default pm3-k56-1.idcom 0.0.0.0 UG ppp0
Note that the default is my ppp, the pm3-k56-1.idcom is the "remote IP
address" that your /var/log/messages printed out when connect was
complete (down below this paragraph). I know this because I did
"nslookup -sil pm3-k56-1.idcomm.com"...this value changes each dial up.
This remote point is listed twice, once at the exact point, the first
entry, with flags "UH" (H for host, it is a point), and last as default.
Default only exists while connected, not continuously.
>
> Before that was finished, I think, in another terminal I ran
>
> glenn at puck:glenn/$glenn at puck:glenn/$ sudo wvdial &
>
> and /var/log/messages said
>
> Dec 6 06:59:57 puck pppd[790]: pppd 2.3.11 started by root, uid 0
> Dec 6 06:59:57 puck pppd[790]: Using interface ppp0
> Dec 6 06:59:57 puck pppd[790]: Connect: ppp0 <--> /dev/ttyLT0
> Dec 6 06:59:58 puck pppd[790]: found interface eth0 for proxy arp
> Dec 6 06:59:58 puck pppd[790]: local IP address 138.67.57.35
> Dec 6 06:59:58 puck pppd[790]: remote IP address 138.67.1.16
>
> At this point I could ping 138.67.57.35 but nothing else I tried. I
> ran "route" again:
>
> glenn at puck:glenn/$ sudo route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 138.67.1.16 * 255.255.255.255 UH 0 0 0 ppp0
> localnet * 255.255.192.0 U 0 0 0 eth0
> default 138.67.1.1 0.0.0.0 UG 1 0 0 eth0
> glenn at puck:glenn/$
Bingo, your default route is wrong. It looks like bringing up ppp got
rid of only one of the two default entries. If you can figure out where
eth0 is being assigned a default route while not connected with ppp, you
should remove both entries (I can guarantee at least one should be
removed, but from past problems, I suggest that both defaults should be
removed).
>
> and /var/log/messages said
>
> Dec 6 07:03:09 puck kernel: eth0: flipped to 10base2
> Dec 6 07:03:10 puck kernel: eth0: coax cable problem
This might be related to two default routes? Don't know.
>
> As always, any help appreciated. I didn't have time to try the /cdrom
> suggestion; I'll try tonight. I haven't changed any /cdrom link or
> fstab so it seems strange to me that installing a new kernel image
> would make it stop working. Perhaps by tonight I'll be able to
> connect via Linux and report success!
Now for a specific file, if RH, I *think* you might want to go to
/etc/sysconfig/network-scripts/. Within that directory, you will find
scripts for each network interface, and possibly other scripts for pre-
and post-execution rules; in the case of ppp, ifdown-ppp that executes
when ppp connect drops, and ifup-ppp that runs when ppp connects. In my
ifup-ppp I found an interesting comment:
if [ "${DEFROUTE}" != no ] ; then
# pppd will no longer delete an existing default route
# so we have to help it out a little here.
route del default >/dev/null 2>&1
opts="$opts defaultroute"
fi
So it looks like (I didn't look closely) bringing up ppp will kill an
old default route only if $DEFROUTE is not "no". But it only has one
route delete line, I do not know if that works to delete both of your
default routes (you have a duplicate default, don't know how it got
there). I am guessing that $DEFROUTE is not "no", so it is running, but
that it is deleting only one of the default routes. Somewhere the "opts"
is being passed to this script also, and I am guessing the opts line
would assign ppp0 as default if opts is correct, else not.
Now I have ifcfg-eth0 file with this in it:
DEVICE="eth0"
BOOTPROTO="none"
BROADCAST=10.255.255.255
IPADDR="10.0.0.6"
NETMASK="255.0.0.0"
NETWORK=10.0.0.0
ONBOOT="yes"
IPXNETNUM_802_2=""
IPXPRIMARY_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="no"
IPXACTIVE_ETHERII="no"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="no"
IPXACTIVE_SNAP="no"
(this machine is 10.0.0.6 internally, nice to know all 10.x.x.x is
firewalled as well as non-routeable)
You might examine file ifcfg-eth0 and figure out if a default is being
assigned through that in some way, remove it if so. Possibly there is
something in aliases dual assigning things, don't know. Looking a bit
closer at ifup-routes, I see it consults the static-routes file, which
is quite likely to contain the bogus default route entry (this file is
in the parent directory, not the current directory, so cd to
/etc/sysconfig/ to find it).
Anyway, you might go to /etc/sysconfig/ and do a recursive grep for
138.67.1.1:
rgrep -r "138[.]67[.]1[.]1" *
Consider yourself on a data hunt. Lucky you!
D. Stimits, stimits at idcomm.com
>
> Thanks,
> Glenn Murray
> www.mines.edu/~gmurray/public_html/Welcome.html
>
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
More information about the LUG
mailing list