Technology Firefox, Vista, and SDN

[Apollyon]

---

Members don't see this ad.

So, I have been searching online for a solution, and none of the things I have found have been applicable or functional.

I am here on my mother's computer. She has Win Vista Home, and I am using Firefox. Currently, it is 10.0.2. However, my problem here dates to FF 7 or before. The problem is that pages don't completely load. They seem to draw from the top down, but don't finish. It seems to be a bandwidth thing, partially, as it is most noticeable mid-day and in the afternoon. If I reload the page, only occasionally will it result in the page correctly rendering.

One possible solution from mozilla.org was to clear the cache and history. That seemed to work for - literally - 5 minutes. Since then, though, there is no difference.

I have only seen this with SDN, although I think it may be just heavy page data sites where it occurs (and I don't visit others, whereas here on SDN there can be 50 responses to a page, and that's a lot to write).

Is this clear enough? Does anybody have any advice or opinions (beyond "use Safari/IE/Opera!")? Thanks.

 

[Stroganoff]

Curious about Internet connection (DSL? Cable? dial-up?), which provider and speed, as well as make/model of router and/or modem. Any info would help.
------
Also, can you test with Internet Explorer 9 (or 8 if that's what's installed)? Can you re-create the same issue? This can help you isolate whether it may be a Firefox setting or issue or if it's a connection issue.

Edit: I'm not saying to "use IE/Safari/Opera" but it's part of the deduction process. If you can r/o Firefox, you can move onto other possibilities. Screw zebras here.

 

[BrainSlug]

Could be a fragmentation issue (MTU mismatch), routing issue (TTL declinates too quickly), TCP timeout is set too low, etc... The ddx is likely to be complicated since this is an unusual issue these days. I haven't run into something like this in probably a decade, it was much more common during the dial-up era.

 

[Stroganoff]

My first guess was TCP timeout. I've gotten the same stuff with SDN before but it was back in 2007 at the place I was at. The Linksys WCG200 cable modem gateway/router was a known POS that timed out and lost the cable connection on its own 500x a day, especially with a lot of throughput.

 

[Apollyon]

Sorry fellas for the lack of more info. Cable modem, Time Warner. The cable modem is a Ubee U10C018. I only noticed this with Firefox. I just tried IE (at 0015 EST), and a weird thing happened - I kept getting to a page, then it would go to a "Internet Explorer cannot display the webpage" page. I could reload, and scroll down a bit, and then it came up again. Once it reloaded itself and the web page came up, and then again to the "cannot display" page. I have selected "SDN Classic", and that remains, vs defaulting to the SDN 2012. IE 9.0.5.

As for the speed of the cable modem, I'm not sure, and I haven't run speed tests. Let me check that out. 6051Kb/s down, 920Kb/s up, 42ms latency.

 

[BrainSlug]

The easiest way to fix this without actually solving the problem would be to completely disable your internet cache. This would force the system to retrieve the entire page each time you load it. Given the speed of the connection you are on it shouldn't slow down your browsing much at all.

It's very likely either a routing issue, excessive TTL declination resulting from a bad route, packets being lost, or TCP timeout/excessive retry failures.

I'd have you ping SDN servers for more info but they blackhole pings (good config. on their part, but it makes diagnosing user issues more difficult). We can ping a server close to SDN, most likely a perimeter or gateway server. Run this in a command prompt:

ping -t 216.15.17.18

Let it return 50 results or so. If they all come back (no loss), then the majority of the route to SDN is intact and there are most likely no routing issues. If you only get some of them back there's a good chance there's a routing issue between you and SDN that is eating packets and causing excessive data loss.

Run the following 3-4 times in a command prompt:

tracert 206.82.221.135

If your route is good you should get as far as *.irv.intelenet.net (206.82.223.*) everytime. If you don't get that far every time it's a good sign that you have a routing issue somewhere between you and SDN. Unfortunately there is most likely nothing you can do about it unless it's either inside the cable network (before you get on the backbone) or inside SDN's host farm.

If it's not a routing issue it's most likely a misconfiguration in the host system. We would have to increase the TCP timeout/retry values in order to give the system more time to retrieve the data before giving up.

 

[Apollyon]

Appreciate that. Let me give that all a try. Ironically/coincidentally, at 1246EST, when I loaded SDN, I had to reload 5 times, as the page did it again.

 

[Apollyon]

My mother's computer has the CA firewall installed, but I don't get exception notice pop ups for it. The ping lost all packets (61/61).

The trace was good until it started getting to us.above.net. Latency went up to about 90ms and stayed there. Hop 14 got to irv.intelenet.net, then hop 15 irv.intelenet.net, then it timed out for the rest of the cycle.

Disabling the cache did not work around the problem. I flushed the cache, and set it to zero, but the thread I was checking stopped at the exact same point.

I didn't think the firewall was the issue, because it is an intermittent problem.

 

[BrainSlug]

My mother's computer has the CA firewall installed, but I don't get exception notice pop ups for it. The ping lost all packets (61/61).

The trace was good until it started getting to us.above.net. Latency went up to about 90ms and stayed there. Hop 14 got to irv.intelenet.net, then hop 15 irv.intelenet.net, then it timed out for the rest of the cycle.

Disabling the cache did not work around the problem. I flushed the cache, and set it to zero, but the thread I was checking stopped at the exact same point.

I didn't think the firewall was the issue, because it is an intermittent problem.

Sounds like your route is probably intact. You'll want to take down the firewall and try the ping test again. If you were actually 0/61 your internet connection wouldn't even be functional. Most firewalls block outgoing and incoming ping by default. 90ms latency isn't wonderful, but it's not bad. Certainly not enough to cause TCP timeout, you wouldn't see that become a problem until you get close to 400-500ms each jump.

 

[Apollyon]

So, now, at 1500EST, SDN is loading just fine. However, running ping and trace, the pings time out and drop all packets, and the tracer times out at hop 16 (after getting to irv.intelenet.net). I haven't tried yet to turn off the firewall.

 

[Stroganoff]

FWIW BrainSlug, I can't ping that IP either, so it's not the best test.

I googled "Ubee U10C018" and there's some timeout and connectivity issues with this cable modem. I'll have to dig around some more, but this may be it.

 

[Apollyon]

FWIW BrainSlug, I can't ping that IP either, so it's not the best test.

I googled "Ubee U10C018" and there's some timeout and connectivity issues with this cable modem. I'll have to dig around some more, but this may be it.

When I googled it, I didn't find the good stuff. Thanks.

 

[BrainSlug]

FWIW BrainSlug, I can't ping that IP either, so it's not the best test...

Typo! It is supposed to be 216.55.17.18, that's the IP address for what appears to be the perimeter for intelenet.net.

If the pings come back clean the only thing we can try is to increase the TCP timeout/retry to the maximum values to make the connection more fault tolerant (although it will slow it down since it will wait longer and re-request lost packets in greater numbers). That's only a patch for the problem though. If it's a hardware failure (def. possibility since intermittent failures are typically hardware in origin, software is rarely intermittent), and we've ruled out the route to and from SDN, leaving only the local hardware, the only ultimate solution is replacing the modem.

 

[Apollyon]

Ping was 73/73 - zero packets dropped. Latency was 87ms to 190ms, but that 190 was quite an outlier. Next longest was 108. The vast majority were 87-90.

 

[BrainSlug]

Ping was 73/73 - zero packets dropped. Latency was 87ms to 190ms, but that 190 was quite an outlier. Next longest was 108. The vast majority were 87-90.

The route back and forth to/from SDN is most likely clean then. That makes it a local problem. Increasing the TCP timout/retry window should help, but that's not the source of the problem. I'd check the drop from the street to the house, from the house to the modem, and the cable that goes from the modem to the computer. If all of those are physically intact (can't really test for continuity without a tester) It's likely the NIC that the modem interfaces with, or the modem. I'd start with the modem first, a much more likely source of failure than the NIC.

 

[Apollyon]

Mondo mahalos!