Re: default gateway not letting me out?
From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 03/21/04
- Next message: Raj: "Re: default gateway not letting me out?"
- Previous message: Unknown: "Re: IPCop Question"
- In reply to: Raj: "default gateway not letting me out?"
- Next in thread: Joachim Mæland: "Re: default gateway not letting me out?"
- Reply: Joachim Mæland: "Re: default gateway not letting me out?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 21 Mar 2004 13:02:43 -0800
raj1q2w@yahoo.com (Raj) wrote in message news:<973a2213.0403160633.328b4dd8@posting.google.com>...
> Hi,
>
> I am using redhat 9.0 and am having a hard time getting anywhere on
> the internet. I dont have the same problem with win32 boxes.
>
> More specifically, I use dhclient to obtain an IP address and other
> related properties. This works fine and I get a IP address and also
> the default gateway (verified routing tables).
>
> It seems like the gateway is not letting me out. My ISP is verizon.
> They say that they do not support linux clients. Whenever I try going
> to any website I get a default "verizon" page.
>
> When I do a traceroute, I see that it does not go beyond the gateway.
>
> Is there anything different in the way linux clients are identified by
> the ISP? Am I looking in the wrong place?
>
> Raj
Posts are getting too nested, so I've gone back to the top.
OT, FYI -- Now this is some _serious_bandwidth_ (and tax $):
... Westchester County,[NY,] which has put all government traffic on
an OC-48(2,488Mbit/sec.) network provided by Lightpath ...
After some needed rest and with a clear mind ...
First noteworthy, hard info from your traceroute to Google:
1 129.122.171.66.subscriber.vzavenue.net (66.171.122.129)
Note the name/IP address -- look familiar? What clue does it give?
Compare to output from route:
66.171.122.0 * 255.255.255.0
default 129.122.171.66. 0.0.0.0
The gw in 1 of your traceroute above is a DNS resolved host name --
the name is a FQDN instead of just the truncated "IP" name used in
your route table. It's an automatically generated name with a _very_
common format used by ISPs. The second line shows you're getting
through the gw onto Verizon's 10 net.
Compare to this output:
[root@localhost dev]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:E0:29:49:E5:33
inet addr:66.171.122.169 Bcast:66.171.122.255 Mask:255.255.255.0
As you would expect -- your gw is on the same subnet as you.
Now let's snoop!
Google "www.vzavenue.net" and then related: was added which lead to
Verizon's login page at:
http://www.vzavenue.net/VerizonAve/install_login.html
<HTML>
<HEAD>
<TITLE>Verizon Ave - Main</TITLE>
</HEAD>
<body BGCOLOR="#ffffff" text="#000000" link="red" vlink="#0000EE"
alink="#FF0000">
<CENTER>
<table border=0 cellpadding=8 >
<tr>
<td valign=bottom align=right colspan=2> <font
color="#29006B"
size="+2"><B>
</B></font></td>
</tr>
<tr>
<td valign="top"><img src="/icons/verizon_login.gif"
width="400"
height="263"></td>
</tr>
</table>
</CENTER>
</BODY>
</HTML>
View source for some (useful?) clues -- re: ID code. Parent directory
I assume is what you mean by "default" Verizon page being presented to
you -- if not, let us know what is.
This also turned up and may be of interest (or maybe not -- note GTE
ref):
http://www.ntlug.org/pipermail/discuss/Week-of-Mon-20030526/016688.html
Sorry for formatting of below ...
ping/traceroute results:
[user@pbrain]$ ping -c4 www.vzavenue.net
PING www.vzavenue.net (66.171.59.135) from x.y.25.164 : 56(84) bytes
of data.
64 bytes from www.vzavenue.net (66.171.59.135): icmp_seq=1 ttl=242
time=61.6 ms
64 bytes from www.vzavenue.net (66.171.59.135): icmp_seq=2 ttl=242
time=68.3 ms
64 bytes from www.vzavenue.net (66.171.59.135): icmp_seq=3 ttl=242
time=47.0 ms
64 bytes from www.vzavenue.net (66.171.59.135): icmp_seq=4 ttl=242
time=53.1 ms
--- www.vzavenue.net ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3033ms
rtt min/avg/max/mdev = 47.022/57.526/68.353/8.124 ms
[user@pbrain]$ /usr/sbin/traceroute www.vzavenue.net
traceroute to www.vzavenue.net (66.171.59.135), 30 hops max, 38 byte
packets
1 10.1.48.1 (10.1.48.1) 7.839 ms 31.904 ms 9.931 ms
2 10.100.3.2 (10.100.3.2) 7.913 ms 6.594 ms 9.040 ms
3 12.126.93.161 (12.126.93.161) 12.824 ms 12.124.131.197
(12.124.131.197) 17.729 ms 28.489 ms
4 gbr1-p56.sl9mo.ip.att.net (12.123.198.33) 21.611 ms 19.916 ms
17.482 ms
5 tbr2-p013502.sl9mo.ip.att.net (12.122.11.113) 18.123 ms 24.991
ms 31.874 ms
6 tbr2-cl7.cgcil.ip.att.net (12.122.10.45) 25.447 ms 32.295 ms
25.525 ms
7 ggr2-p3120.cgcil.ip.att.net (12.123.6.69) 24.474 ms 25.596 ms
25.744 ms
8 so-1-1-0.edge1.chicago1.level3.net (209.0.227.77) 33.889 ms
24.699 ms 25.081 ms
9 so-2-1-0.bbr2.chicago1.level3.net (209.244.8.13) 26.263 ms
24.716 ms 24.370 ms
10 ge-0-3-0.bbr2.washington1.level3.net (64.159.0.229) 42.729 ms
37.774 ms 37.641 ms
11 ge-7-2.ipcolo1.washington1.level3.net (64.159.18.131) 61.881 ms
39.460 ms 38.055 ms
12 unknown.level3.net (63.210.41.130) 40.251 ms 37.135 ms 56.249
ms
13 66.171.40.14 (66.171.40.14) 39.037 ms 49.920 ms 39.514 ms
14 66.171.59.165 (66.171.59.165) 48.394 ms 62.050 ms 49.456 ms
15 * * *
16 * * *
17 * * *
18 * 66.171.59.165 (66.171.59.165) 44.620 ms !X *
19 * * *
20 66.171.59.165 (66.171.59.165) 62.772 ms !X * *
21 * * *
22 * * *
23 * * *
24 66.171.59.165 (66.171.59.165) 52.524 ms !X * *
25 thru 30 * * *
[user@pbrain]$ /usr/sbin/traceroute -I www.vzavenue.net
traceroute to www.vzavenue.net (66.171.59.135), 30 hops max, 38 byte
packets
1 10.1.48.1 (10.1.48.1) 7.739 ms 6.698 ms 7.328 ms
2 10.100.3.2 (10.100.3.2) 7.683 ms 7.788 ms 7.608 ms
3 12.124.131.197 (12.124.131.197) 10.974 ms 12.126.93.161
(12.126.93.161) 11.345 ms 12.126.93.153 (12.126.93.153) 15.272 ms
4 gbr1-p56.sl9mo.ip.att.net (12.123.198.33) 17.292 ms 41.825 ms
28.424 ms
5 tbr2-p013502.sl9mo.ip.att.net (12.122.11.113) 18.872 ms 20.879
ms 17.582 ms
6 tbr2-cl7.cgcil.ip.att.net (12.122.10.45) 25.645 ms 25.145 ms
36.064 ms
7 ggr2-p3120.cgcil.ip.att.net (12.123.6.69) 38.987 ms 29.628 ms
25.441 ms
8 so-1-1-0.edge1.chicago1.level3.net (209.0.227.77) 26.069 ms
33.340 ms 27.755 ms
9 so-2-1-0.bbr2.chicago1.level3.net (209.244.8.13) 34.204 ms
30.892 ms 37.141 ms
10 ge-0-3-0.bbr2.washington1.level3.net (64.159.0.229) 45.360 ms
38.385 ms 44.301 ms
11 ge-7-1.ipcolo1.washington1.level3.net (64.159.18.67) 41.707 ms
38.250 ms 38.073 ms
12 unknown.level3.net (63.210.41.130) 37.777 ms 38.819 ms 40.224
ms
13 66.171.40.14 (66.171.40.14) 44.032 ms 40.406 ms 39.624 ms
14 66.171.59.165 (66.171.59.165) 43.719 ms 58.157 ms 45.587 ms
15 www.vzavenue.net (66.171.59.135) 43.755 ms 50.365 ms 52.109 ms
[user@pbrain]$ /usr/sbin/traceroute 66.171.122.169 -> look familiar?
traceroute to 66.171.122.169 (66.171.122.169), 30 hops max, 38 byte
packets
1 10.1.48.1 (10.1.48.1) 7.669 ms 7.160 ms 7.368 ms
2 10.100.3.2 (10.100.3.2) 6.084 ms 6.541 ms 8.447 ms
3 12.124.131.197 (12.124.131.197) 19.399 ms 12.126.93.161
(12.126.93.161) 24.756 ms 12.126.93.153 (12.126.93.153) 17.157 ms
4 gbr1-p56.sl9mo.ip.att.net (12.123.198.33) 89.266 ms 31.459 ms
21.664 ms
5 tbr2-p013502.sl9mo.ip.att.net (12.122.11.113) 36.383 ms 19.162
ms 17.478 ms
6 tbr2-cl7.cgcil.ip.att.net (12.122.10.45) 40.010 ms 34.831 ms
26.924 ms
7 ggr2-p3120.cgcil.ip.att.net (12.123.6.69) 49.619 ms 38.612 ms
24.285 ms
8 so-1-1-0.edge1.chicago1.level3.net (209.0.227.77) 41.723 ms
34.310 ms 23.912 ms
9 so-2-1-0.bbr1.chicago1.level3.net (209.244.8.9) 41.276 ms 35.945
ms 27.500 ms
10 so-0-0-0.bbr1.newyork1.level3.net (64.159.0.234) 53.202 ms
48.496 ms 54.286 ms
11 so-9-0.hsa1.newark1.level3.net (4.68.113.46) 48.243 ms 48.870 ms
54.770 ms
12 so-8-0.hsa2.newark1.level3.net (4.68.113.50) 49.553 ms 50.001 ms
56.742 ms
13 unknown.level3.net (64.157.185.14) 49.782 ms 58.457 ms 74.144
ms
14 244.2.171.66.subscriber.vzavenue.net (66.171.2.244) 65.769 ms
60.733 ms 56.572 ms
15 10.50.61.14 (10.50.61.14) 57.208 ms 63.180 ms 68.348 ms
16 thru 30 * * * inside the 10 net
Compare the last IP to yours from Google!
traceroute -I (eye) produced same results
we start tickling Verizon's net here (probably):
unknown.level3.net (63.210.41.130)
as this is the first common router in all attempts
I am still not convinced that you are not part of the same net Verizon
uses for its xDSL customers -- why keep them separate? Did you
install _any_ software related to your ISP or Verizon for your Win OS?
If so, it's a dead giveaway that Win is "required" (Macs also
"supported"). If not, there _may_ be hope of getting Linux to work
with your Verizon account/connection.
What I think is happening is this:
-- your Win dhcp request is properly formed and properly processing
_all_ returned info from Verizon -- thus good "connection"
-- your Linux dhcp request is either not properly formed and/or the
returned info is not being properly processed -- thus not a good
"connection"
DHCP is a _very_ flexible protocol with many options/variations on the
info requested/returned -- including athentication/authoriztion info.
Win's implementation of DHCP is known to be "extended and enhanced"
(especially when connecting to a Win DHCP server). It could be that
your Linux request is not properly authenticating you when you try to
route through the Verizon system. You _are_ getting beyond your gw,
as evidenced by your traceroute, ie., your gw entry is OK. But is
your Linux authenticated to use the Verizon services? How would it
"get authenticated"?
The answer to the last could have many variations and one would hope
that Verizon would provide the answer -- or at least state flat out,
"Linux not welcome here." If you are paying for the Verizon account,
check what it offers and _demand_ some satisfactory -- or at least
clear -- answers. If your service is paid for by the property owner,
get some clarification on the nature of the account they have and what
you can expect to receive as a service.
Related note --
The "fact" that your dwelling (apartment?) is fed by a T1 line has
nothing to do with dhcp, TCP/IP, PPP, or whatever. It is just a
digital signal carrier that can be configured many ways to encapsulate
and carry many network protocols. If you do have a T1 feed, there
will be on your premises a CSU/DSU external or internal to the router
that sends traffic through the line. Using T1s for this was quite
popular for a couple of years on new, "modern" apartment/subdivision
developments. Many have been silently converted to xDSL. You would
have no way of knowing without viewing the equipment installed on the
property owner's side of the demarc. Property owners frequently are
not aware of the change!
Continuing:
If Verizon cannot/will not help, then get Ethereal (or other sniffer
that runs on both platforms) and sniff the traffic on the known
working setup, ie., your Win OS. Request a new lease and watch what
passes in the dhcp exchange. Record your IP and route table. Go out
on the net. View/record your arp and route caches for these early
additions -- they should show up in the Ethereal capture also. Be
sure to save to a capture file.
Do the same on Linux. Simply ifconfig down shortly followed by
ifconfig up should be enough to trigger a new lease request -- but may
not with a Win server. Compare the Linux traffic to the Win traffic
for any clues that will tell you how to properly set up Linux --
probably via dhclient.conf. Be prepared for some _hard_ work getting
this right, even if it's possible.
It may be (a wild guess here) that your Win OS is opening a
service/port which dhcp tickled to run and which is checked for when
you send traffic out through Verizon. Or something similar along
those lines. Or something completely different. Only Verizon knows!
I Googled for several hours tyring to find someone with a problem like
yours -- and especially one with a solution. Not many found on the
first (whatever that means) and none on the second. My search terms
brought up too much crap to wade through, so I may try a better
approach later.
Solutions by priority:
-- Verizon, though they are not noted for timely/clear responses
-- A working Linux setup that you can copy or at least use as a guide
-- A user web forum where you post your problem -- even Verizon
xDSL-dhcp users will be helpful, eg., http://www.dslreports.com/
-- Your own detective work that reveals what you need to do -- a
sniffer pretty much required for this -- could be very tough
dhcp related rfc's
http://www.faqs.org/cgi-bin/rfcsearch
handy dhcp header details:
http://www.networksorcery.com/enp/default0601.htm
Use Google and scrounge for info/help, eg.:
verizon linux dhcp -> lots of "noise", find something better
Google searches may reveal scary indicators of just how "open" this
net is (and maybe some clues):
"subscriber.vzavenue.net"
"subscriber.vzavenue.net" + linux
You may turn up some email on linux lists (from above searches) and
maybe check with sender for a solution (ie., a working Linux example
to work from):
https://listman.redhat.com/archives/psyche-list/2003-September/msg00165.html
notice his email address -- does it mean he has linux running with
_some_ Verizon ISP setup?
Will get back if I find anything -- hope above is useful.
prg
email above disabled
- Next message: Raj: "Re: default gateway not letting me out?"
- Previous message: Unknown: "Re: IPCop Question"
- In reply to: Raj: "default gateway not letting me out?"
- Next in thread: Joachim Mæland: "Re: default gateway not letting me out?"
- Reply: Joachim Mæland: "Re: default gateway not letting me out?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
