Experiences with Quest DSL?
Hi all, I apologize that there might be a better place to ask this, but this is the best I can think of. I got a friend to migrate to Linux in the last couple of days, based largely on the inability of Quest to get their DSL connection running under Windows ME without crashing the system every few minutes. Well, now she has a shiny new install of SuSE 10, and it runs just fine on my connection (Comcast cable hosted). It picks up its DHCP info perfectly and promptly and just runs, just the way it should. This morning I took it to my girlfriend's house to put the finishing touches on the toolbar so she'd find it as easy to use as posible, and it works just fine on her connection too (also Comcast). However, later today the owner took it home and plugged it into the ethernet port of her new Actiontec DSL modem, connected to Quest DSL. All the right lights are on on the DSL modem, and if I point her browser at 192.168.0.1, I get a faultless connection to the Actiontec's config pages. Further, if I point the browser at some external sites, it often works. However, it seems that the connection is intermittent, perhaps a few minutes working, then many minutes not working (utterly unusable, not just a bit flakey). Curiously, though, some websites (notably java.sun.com, for no obvious reason) seem to work pretty consistently, and will continue to work even while the other sites are unreachable. I got a couple of short ethereal files capturing the behavior, but managed--due to three hours tearing my hair out I suppose--to leave them behind :( I plugged my laptop into her system, and it exhibits the exact same behavior (and it's entirely reliable at home). Frankly, I had Quest DSL about 18 months ago, and I found it utterly unreliable, but I rather assumed they'd fixed it all up by now. I never worked out what the problem was, I just went to digital cable and was happy from then on. Is this something anyone else has experienced? Any light to shed? It occurs to me that there's a coffee shop in town that I can't use from my laptop. The effect is similar. I get a dhcp response that configures my IP, default route, and DNS believably, but I don't actually get any responses to any requests. Is it conceivable that Quest is running a protocol stack that is in some way not entirely compatible with Linux? I guess that would mean that the vast majority of their customers run other OSes (well, sad but true so far, though probably changing). I'm boggled by the whole thing. Any thoughts (or any other diagnostics) would be gratefully listened too. Quest says they can run some live tests but I can't visit this friend again till next week, so I'd like to have all the ideas in my mind when the time comes. Many thanks all in advance, Cheers, Simon "You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions." Naguib Mahfouz __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
On Saturday 07 January 2006 16:07, Simon Roberts wrote:
Frankly, I had Quest DSL about 18 months ago, and I found it utterly unreliable, but I rather assumed they'd fixed it all up by now. I never worked out what the problem was, I just went to digital cable and was happy from then on.
Sounds to me like flaky DNS servers. To prove it get a list of the actual IP addresses of the sites you are having trouble with. Ping will return the IP address of a web site. Then try pinging the actual IP addresses of a few known sites and then try pinging them using the www address. If that fails then the DNS is at fault. There were problems with Telstra Bigpond over here with their DNS servers for months. The solution was to disable the DNS section of the DHCP and use the IP addresses of the DNS servers of some of the other ISP's . YaST ----> Network Services ---> DNS & Hostname -- Regards, Graham Smith
At 01/06/06 23:40, Graham Smith wrote:
On Saturday 07 January 2006 16:07, Simon Roberts wrote:
Frankly, I had Quest DSL about 18 months ago, and I found it utterly unreliable, but I rather assumed they'd fixed it all up by now. I never worked out what the problem was, I just went to digital cable and was happy from then on.
Sounds to me like flaky DNS servers.
To prove it get a list of the actual IP addresses of the sites you are having trouble with. Ping will return the IP address of a web site. Then try pinging the actual IP addresses of a few known sites and then try pinging them using the www address. If that fails then the DNS is at fault.
There were problems with Telstra Bigpond over here with their DNS servers for months. The solution was to disable the DNS section of the DHCP and use the IP addresses of the DNS servers of some of the other ISP's . YaST ----> Network Services ---> DNS & Hostname
We had a similar problem with ComCast a bit over a year ago, and it was their DNS servers (which they denied, but that's another story). However, that problem was getting initial name resolution so we could go anywhere at all. We pointed our router/firewall at other, non-ComCast DNS servers (we're using 4dot2dot2dot2, 64dot81dot45dot2, and 64dot81dot79dot2), and we've had no problem since. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
--- Eric Hines
We had a similar problem with ComCast a bit over a year ago, and it was their DNS servers (which they denied, but that's another story). However, that problem was getting initial name resolution so
we could go anywhere at all. We pointed our router/firewall at other, non-ComCast DNS servers (we're using 4dot2dot2dot2, 64dot81dot45dot2, and 64dot81dot79dot2), and we've had no problem since.
Many thanks to all who made suggestions, much appreciated. In the end the problem was that the Actiontec DSL modem's DNS proxy server was lying. The effect was that the modem told the DHCP client to use 192.168.0.1 (the modem) and another address for DNS. It reported itself first on the list. For some reason, the web browsers (tried Firefox, Mozilla, and Konqueror) all went to the modem for DNS lookup. Sometimes this was successful, but most of the time, it reported 1.0.0.0 for any requested address. Clearly, when pointed to that address the browsers were bound to fail. Curiously, other parts of the system (ping, nslookup, traceroute etc.) all got the right address. I didn't determine if this was because they abandoned the modem when it was so obviously lying, or because somehow they went to the second server anyway. I _thought_ that DNS lookup was a system call, and they should all get the same response. Any thoughts? Anyway, I reconfigured DHCP to ignore the offered DNS server list, and simply hard-wired the two Qwest servers in to /etc/resolv.conf. The system now works smoothly and my friend is happily learning her way round Linux instead of Windows (yeah! chalk one up to the good guys :) Again, thanks for all comments, Cheers, Simon "You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions." Naguib Mahfouz __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-01-10 at 08:50 -0800, Simon Roberts wrote:
they went to the second server anyway. I _thought_ that DNS lookup was a system call, and they should all get the same response. Any thoughts?
I think I sometimes saw a mozilla process doing some kind of dns cache. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDxBNztTMYHG2NR9URAu3eAKCL8wTJAFOD2KC+n9h9yUJ4EmM2IwCfR3n9 Exu9EMhk/KKaJ5xjShzDQ04= =XrUN -----END PGP SIGNATURE-----
On Fri, 2006-01-06 at 21:07 -0800, Simon Roberts wrote:
Hi all,
I apologize that there might be a better place to ask this, but this is the best I can think of.
I got a friend to migrate to Linux in the last couple of days, based largely on the inability of Quest to get their DSL connection running under Windows ME without crashing the system every few minutes.
Well, now she has a shiny new install of SuSE 10, and it runs just fine on my connection (Comcast cable hosted). It picks up its DHCP info perfectly and promptly and just runs, just the way it should. This morning I took it to my girlfriend's house to put the finishing touches on the toolbar so she'd find it as easy to use as posible, and it works just fine on her connection too (also Comcast).
However, later today the owner took it home and plugged it into the ethernet port of her new Actiontec DSL modem, connected to Quest DSL. All the right lights are on on the DSL modem, and if I point her browser at 192.168.0.1, I get a faultless connection to the Actiontec's config pages. Further, if I point the browser at some external sites, it often works. However, it seems that the connection is intermittent, perhaps a few minutes working, then many minutes not working (utterly unusable, not just a bit flakey). Curiously, though, some websites (notably java.sun.com, for no obvious reason) seem to work pretty consistently, and will continue to work even while the other sites are unreachable. I got a couple of short ethereal files capturing the behavior, but managed--due to three hours tearing my hair out I suppose--to leave them behind :(
I plugged my laptop into her system, and it exhibits the exact same behavior (and it's entirely reliable at home).
Frankly, I had Quest DSL about 18 months ago, and I found it utterly unreliable, but I rather assumed they'd fixed it all up by now. I never worked out what the problem was, I just went to digital cable and was happy from then on.
Is this something anyone else has experienced? Any light to shed?
It occurs to me that there's a coffee shop in town that I can't use from my laptop. The effect is similar. I get a dhcp response that configures my IP, default route, and DNS believably, but I don't actually get any responses to any requests.
Is it conceivable that Quest is running a protocol stack that is in some way not entirely compatible with Linux? I guess that would mean that the vast majority of their customers run other OSes (well, sad but true so far, though probably changing).
I'm boggled by the whole thing. Any thoughts (or any other diagnostics) would be gratefully listened too. Quest says they can run some live tests but I can't visit this friend again till next week, so I'd like to have all the ideas in my mind when the time comes.
I'm not sure if you can do this, if you can it'll help distinguish between hardware and connection problems. Go into the DSL modems setup (is this some sort of switch? all of my dsl modems didn't have any setup on them, just hardware.), and set up the info for your dsl service, and see if it behaves the same way. If it doesn't connect, then you haven't actually ruled anything out. Thing is, I'm not sure if you guys down there can do this. Up here in the Great White North there are very few Telco's so if you've got several dsl providers in one area, they're running through the one telco's switching system and lines, and you can use your dsl on some one elses line providing they are set up to have dsl in the first place.
On Fri, 2006-01-06 at 21:07 -0800, Simon Roberts wrote:
Hi all,
I apologize that there might be a better place to ask this, but this is the best I can think of.
Not a problem. <snip>
Is it conceivable that Quest is running a protocol stack that is in some way not entirely compatible with Linux? I guess that would mean that the vast majority of their customers run other OSes (well, sad but true so far, though probably changing).
Not likely.
I'm boggled by the whole thing. Any thoughts (or any other diagnostics) would be gratefully listened too. Quest says they can run some live tests but I can't visit this friend again till next week, so I'd like to have all the ideas in my mind when the time comes.
I highly recommend that Quest go on site and test the connection there has to be something wrong with the connection. I have Sprint DSL and had a similar experience and it turned out that I was "cross connected" with another customer that caused my connection to drop every 10-15 minutes. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
participants (6)
-
Carlos E. R. -
Eric Hines -
Graham Smith -
Ken Schneider -
Mike McMullin -
Simon Roberts