humiliating network problem

onebuck · 09-20-2006, 08:31 AM

Quote:

Originally Posted by Randux

Hi Gary, I didn't understand your question. I'm pretty clueless in networking although learning a little bit here and there.

Thanks,
Rand

Hi,

Some modems allow you the option to 'nail' or fix the IP to the modem. No lease! Some ISPs' override the option while others let the option stand to allow IP nailing.

Therefore, the IP for your modem would use the same IP along with the possibility of the same interface unless the interface fails then you would be passed to another unit. This all depends on how the interfaces are setup at the ISP. The modem pools can be any number, this also depends on the local load. Along with the polling of the interfaces and how they are switched.

A lot of the systems generally distribute the interface activity across the equipment. When you activate, you sometimes can get the same interface, depends on activity/load. If your ISP is a small service then this is likely to happen for you.

Randux · 09-20-2006, 11:13 AM

Quote:

Originally Posted by shotwellj

I have just woken up and am only barely coherent. Am I correct in saying this problem is browser specific, but that a browser's performance deteriorates over time. Is this true? How does wget perform? What is the ping time for google.com on the linux box compared to the bloze box?

Hi shotwellj,

The problem seemed browser specific but I can't prove it because even though I've tried not to vary anything on any of the machines it seems like my test results aren't repeatable. Dillo is fast but it seems pretty worthless on anything but a simple page and doesn't support anything. I couldn't run the speed tests with links or lynx so that was about it. I did try Opera but it also ran just as slow as mozilla (without the proxy) so I tried Seamonkey. It was immediately better but then started running badly the next day.

I first noticed this whole problem a while ago when it seemed like when I had a fresh DHCP lease things were ok on the browser and then they would get worse gradually (but quickly).

I don't know how wget or ftp perform because I don't know any sites to try with them. FTP from box to box on the LAN runs well but I have no expectations on how fast it should run. The latest thing is that using the ISP's web proxy my browsing is running at the rated connection speed or a little above. I don't know what that means.

The ping time against my ISP from my Slackware boxes seems very erratic and high compared to the ping time from bloze but occasionally I'll get a good set. I only tried pinging my cable company and ISP instead of another site because I was sure (and still am) that the problem is somewhere with the ISP.

Quote:

Originally Posted by shotwellj

If wget performs well, you probably do not have a network problem. Could there be a bottleneck at the disk? How do other disk-intensive programs perform? As silly as it sounds, have you tried clearing out the cache? I don't really know how browsers go about caching things, but perhaps Mozilla started a new cache when you switched to a proxy? Seamonkey most certainly used a new cache.

I do clean the cache regularly with a shutdown script. I did this because one day I was taking a backup and I noticed the tar was full of crap from all the users browser caches. I was close to the size of a CD and I went over the top from that junk so you can bet I won't let that happen again. There are no signs of other system peformance problems (and remember the poor browser performance happens on two Slackwares and one OpenBSD running on two completely different physical boxes) and when I use the ISP's web proxy it runs at full speed so I don't think anything besides the ISP's tricks can be the cause.

I don't know how to use wget or what a good test with it would be but if anyone has ideas I could try that. Even so I don't know what I would do with the results since the ISP has their "solution" and I'm not getting anywhere with them.

Thanks,
Rand

Randux · 09-20-2006, 11:18 AM

Quote:

Originally Posted by gwsandvik

Hi,

Some modems allow you the option to 'nail' or fix the IP to the modem. No lease! Some ISPs' override the option while others let the option stand to allow IP nailing.

Therefore, the IP for your modem would use the same IP along with the possibility of the same interface unless the interface fails then you would be passed to another unit. This all depends on how the interfaces are setup at the ISP. The modem pools can be any number, this also depends on the local load. Along with the polling of the interfaces and how they are switched.

A lot of the systems generally distribute the interface activity across the equipment. When you activate, you sometimes can get the same interface, depends on activity/load. If your ISP is a small service then this is likely to happen for you.

Hi Gary,

I don't understand exactly what you are saying but I don't think this is the issue because I can get full speed to my cable companies servers, I get full speed from my ISP's proxy, and I get full speed from bloze running with no proxy- but I get bad performance from two Slackware machines (one on the bloze box, one an a different box with 100% different hardware) and OpenBSD (running on the bloze box).

The key seems to be that performance is fine with the web proxy. Maybe someone who understands that can explain what this means because I don't get it. It's not about caching pages because I'm pulling pages that nobody at my ISP is using.

thanks again,
Rand

hosler · 09-20-2006, 11:42 AM

I know you said you have tried 2 different nics, but maybe you should try a third. I had a similar problem where connection speed would be fast for about 5 minutes and then get really slow. Switching network cards solved that problem.

Randux · 09-20-2006, 12:06 PM

Hi hosler,

But bloze using that nic, or anything else using that nic with the ISP's proxy works fine. So it's not a hardware issue.

Thanks,
Randux

drlouis · 09-20-2006, 01:36 PM

A couple of months ago I had a similar nightmare. Intermitent *very* slow speeds. It was a pain to trouble shoot, because half the time when I had tech support on the phone it looked fine, sometimes they could see the slowdown. Took almost 2 months to get it fixed, it turned out they had "a failing piece of equipment". The hard part was the fact that it wasn't consistent. I noticed it when I was booted into windows, and they of course suggested malware. I did a couple of scans that came up clean, and we troubleshot for a long time. finally I got a nice looking speed test, and booted into Slack with smooth sailing for about an hour... anyway I wont bore you with all the ups and downs, but it was a pain. Is it possible the isp has a piece of hardware going out?

Woodsman · 09-20-2006, 01:37 PM

Hey Randux,

Based upon my recent conversion to broadband, through which I am now noticing some unique differences in the way I am connected and the way in which ISPs provide those services, I affirm your suspicion that your ISP might be the cause of the problem. I'm not saying so for sure, just saying I agree the potential is there. You can read about one of my escapades here.

With the new information I now understand how easily I was confused by the port testing results. But hindsight is always 20/20, n'est pas?

Anyway, I now have to wonder if your ISP recently modified their server configurations that affects your connection. Based upon my experience and those I have heard and read of others, most of the ISP tech support staff are mushrooms. That is, they are kept in the dark about many mods performed by the IT staff. In other words, they probably are not going to be much help. Thus, you might need to insist upon talking with an IT person rather than a tech support person---somebody who actually might know of any recent mods.

Quote:

I first noticed this whole problem a while ago when it seemed like when I had a fresh DHCP lease things were ok on the browser and then they would get worse gradually (but quickly).

One thing I have noticed is that my new ISP uses at least two different subnets to assign my IP address. Therefore one thing you might want to investigate is your assigned IP address when in Windows and then again when in Slackware. Are the assigned IP addresses in the same subnet? For example if you see an assigned IP address in the aaa.bbb.---.--- subnet for both OSs then you know that in both OSs you are going through the same ISP server gateway. If you see different subnets, such as aaa.bbb.---.--- and xxx.yyy.---.---, then you are using different ISP gateways for each OS and that might be a clue.

Quote:

I don't know how wget or ftp perform because I don't know any sites to try with them.

Use a Slackware mirror and download a half dozen files. To make things easier, prefix the wget fetch using the time command. Then you'll have concrete time results to compare. As I mentioned in a previous post, you can download wget for Windows. I use a copy. You have to configure some environment variables to get the Windows version working, but otherwise the Windows version is the same as the 'nix version.

Quote:

I don't know how to use wget or what a good test with it would be but if anyone has ideas I could try that.

Find a simple one-file download example anywhere on the web and then test with your LAN. Then test with a Slackware mirror. Then expand the wget fetch list with a half dozen files so as to increase the load and obtain more realistic results.

Quote:

The ping time against my ISP from my Slackware boxes seems very erratic . . .

Ping tests are good for knowing whether a box exists and is responding, but not for connection speeds. And the ping test uses the ICM protocol, not http or ftp. Apples and oranges kind of thing.

Quote:

The key seems to be that performance is fine with the web proxy.

The proxy probably is a different box than the normal gateway server. You can determine this with IP addresses. That you are obtaining good speeds through the proxy server gateway seems to indicate that that box is configured differently than the normal gateway server. So back to the beginning of this specific post, yes, the ISP could indeed have configured the normal gateway server in a manner that impedes your Slackware connection. What none of us yet know is whether the problem is your Slackware configuration or the ISP, but as the results differ dramatically between the normal and proxy servers, I have to suspect the problem is on the ISP side.

Again, I'm not helping you directly, just throwing out ideas and observations.

Randux · 09-20-2006, 03:00 PM

Quote:

Originally Posted by drlouis

A couple of months ago I had a similar nightmare. Intermitent *very* slow speeds. It was a pain to trouble shoot, because half the time when I had tech support on the phone it looked fine, sometimes they could see the slowdown. Took almost 2 months to get it fixed, it turned out they had "a failing piece of equipment". The hard part was the fact that it wasn't consistent. I noticed it when I was booted into windows, and they of course suggested malware. I did a couple of scans that came up clean, and we troubleshot for a long time. finally I got a nice looking speed test, and booted into Slack with smooth sailing for about an hour... anyway I wont bore you with all the ups and downs, but it was a pain. Is it possible the isp has a piece of hardware going out?

Hi drlouis,

I really think after all I've seen with this that there is something about win/not win endpoints. Winbloze gets good service 100% of the time. I've been with this ISP for about a year and in that time I never had a problem on bloze that lasted more than a couple of hours or something that refreshing the DHCP lease and getting a new IP address didn't fix. I've also been running Slackware and OpenBSD for about that same time, and the performance has been fine until the past few weeks (or months, I really haven't kept track).

The curious things is why my web performance is fine with their proxy and not fine without it (but only on non-bloze endpoints.) I think this is the key but I don't know what it means. It could be hardware on their end because refreshing the lease and getting a new IP address used to work. But more and more that didn't help. Since there are so many pieces of software on Linux that all come together from different places to make the whole thing work it's difficult and frustrating to try to figure out wtf is going on. Like I just started getting /dev/console input/output error on startup from INIT (which it looks like I "fixed" by changing the vga mode on LILO. But I had been running with this mode on this box for a few weeks and never got the error. I have been changing a few things (added sshd to the startup, playing around with ftp and hosts.deny/hosts.allow) but it shouldn't cause wierd problems. Even on the box that was stable with relative few (maybe none at all) changes over the past year (this is the box that the bloze machine that gets along fine with the ISP runs on) I had bad performance with Slackware and OpenBSD lately.

So the answer is I really have no idea. What I do know is: I can get full speed from my cable company server (which may or may not be the one I go through when they gateway me to the ISP), I can get full speed from my ISP test server without the proxy (which is almost certainly not the one I use when I'm pulling normal web pages from them) and that otherwise, without the web proxy, I am now getting about 50-100 or so kbps out of a 750kbps connection. If I use their web proxy I get full speed and no bumps.

I believe that this last fact means something but since I'm network-impaired I don't know what it means.

Thanks,
Rand

Randux · 09-20-2006, 03:15 PM

Quote:

Originally Posted by Woodsman

Hey Randux,

Anyway, I now have to wonder if your ISP recently modified their server configurations that affects your connection. Based upon my experience and those I have heard and read of others, most of the ISP tech support staff are mushrooms. That is, they are kept in the dark about many mods performed by the IT staff. In other words, they probably are not going to be much help. Thus, you might need to insist upon talking with an IT person rather than a tech support person---somebody who actually might know of any recent mods.

Hi Woodsman,

Glad you got your problems sorted out. Lately things have really sucked for me in the Linux world.

I agree with what you said but there isn't any way I'm going to be able to talk to anybody who knows anything at the ISP. I can tell from the "answers" I get they're all minimum wage telephone operaters who don't know anything- they just go down a list of obvious stuff that punk kids don't know how to do when setting up a connection on bloze or browsing websites. I'm a developer myself in big companies for many many years so I know a messed-up organization when I see one. And I see one.

Quote:

Originally Posted by Woodsman

One thing I have noticed is that my new ISP uses at least two different subnets to assign my IP address. Therefore one thing you might want to investigate is your assigned IP address when in Windows and then again when in Slackware. Are the assigned IP addresses in the same subnet? For example if you see an assigned IP address in the aaa.bbb.---.--- subnet for both OSs then you know that in both OSs you are going through the same ISP server gateway. If you see different subnets, such as aaa.bbb.---.--- and xxx.yyy.---.---, then you are using different ISP gateways for each OS and that might be a clue.

That's another good comment but in this case I'm running all the boxes behind a router. They all get the same connection. That's the hell of it. I can be sitting right here and watching bloze scream on one screen and Slackware starving to death right next to it. Yes, I know not to test stuff at the same time

Quote:

Originally Posted by Woodsman

Use a Slackware mirror and download a half dozen files. To make things easier, prefix the wget fetch using the time command. Then you'll have concrete time results to compare. As I mentioned in a previous post, you can download wget for Windows. I use a copy. You have to configure some environment variables to get the Windows version working, but otherwise the Windows version is the same as the 'nix version.

I will probably try wget on those packages that's a good idea. But I'm done messing around with bloze, I only use it when I have to which is not much. At least I'll be able to see if I'm getting the rated speed on my Slackware boxes with it.

Quote:

Originally Posted by Woodsman

The proxy probably is a different box than the normal gateway server. You can determine this with IP addresses. That you are obtaining good speeds through the proxy server gateway seems to indicate that that box is configured differently than the normal gateway server. So back to the beginning of this specific post, yes, the ISP could indeed have configured the normal gateway server in a manner that impedes your Slackware connection. What none of us yet know is whether the problem is your Slackware configuration or the ISP, but as the results differ dramatically between the normal and proxy servers, I have to suspect the problem is on the ISP side.

This problem is a recent problem. Now one Slackware machine and one OpenBSD machine (both on the same physical box as the winbloze that works) had been running fine until recently. So it's hard to believe that it's related to configuration on my end as these systems were pretty much unchanged for the longest time. The other Slackware machine is a clone of my other machine but running on a completely different box that has nothing in common as far as hardware goes with my other box. Because the problem happened across this setup and hit all three non-bloze endpoints at the same time I really can't draw any conclusion except that the ISP is throttling non-bloze endpoints. Having the proxy "fix" all the problems only strengthens that idea.

Thanks to you and all the guys for the helpful comments.

Rand

evilDagmar · 09-22-2006, 06:24 AM

I'm going to take a shot in the (relative) dark here and surmise aloud that the connection information might not actually be the same between Windows and Linux.

On whichever machine you can easily dual-boot (so we can reduce the number of variables) can we see what you get from the following commands:

Windows: `route print`
Linux: `route -n`

Yes, the format will be different, but unless ECN (explicit congestion notification) has a whole new meaning for your ISP, I am guessing we'll see different routing information, or possibly no gateway at all on the Linux side of things.

Randux · 09-24-2006, 12:22 PM

Thanks Dagmar. I'll try to do this tomorrow and post the results.

Rand

Randux · 09-25-2006, 11:01 AM

Quote:

Originally Posted by evilDagmar

I'm going to take a shot in the (relative) dark here and surmise aloud that the connection information might not actually be the same between Windows and Linux.

On whichever machine you can easily dual-boot (so we can reduce the number of variables) can we see what you get from the following commands:

Windows: `route print`
Linux: `route -n`

Yes, the format will be different, but unless ECN (explicit congestion notification) has a whole new meaning for your ISP, I am guessing we'll see different routing information, or possibly no gateway at all on the Linux side of things.

Ok Dagmar, here's the output from the Win machine. In a minute I'll boot the Slackware machine (on the same box) and print that. Then I'll try the OpenBSD machine (also on the same box).

From winbloze:

Code:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...xx xx xx xx xx xx ...... Intel(R) PRO/100 VE Network Connection - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.3	  20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
      192.168.2.0    255.255.255.0      192.168.2.3     192.168.2.3	  20
      192.168.2.3  255.255.255.255        127.0.0.1       127.0.0.1	  20
    192.168.2.255  255.255.255.255      192.168.2.3     192.168.2.3	  20
        224.0.0.0        240.0.0.0      192.168.2.3     192.168.2.3	  20
  255.255.255.255  255.255.255.255      192.168.2.3     192.168.2.3	  1
Default Gateway:       192.168.2.1
===========================================================================
Persistent Routes:
  None

and now from Slackware:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0

and now from OpenBSD:

Code:

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu  Interface
default            192.168.2.1        UGS         0       10      -   fxp0
127/8              127.0.0.1          UGRS        0        0  33224   lo0
127.0.0.1          127.0.0.1          UH          0        2  33224   lo0
192.168.2/24       link#1             UC          0        0      -   fxp0
192.168.2.1        yy:yy:yy:yy:yy:yy  UHLc        0        0      -   fxp0
192.168.2.3        127.0.0.1          UGHS        0        0  33224   lo0
224/4              127.0.0.1          URS         0        0  33224   lo0

Internet6:
Destination                        Gateway                        Flags    Refs      Use    Mtu  Interface
::/104                             ::1                            UGRS        0        0      -   lo0
::/96                              ::1                            UGRS        0        0      -   lo0
::1                                ::1                            UH          0        0  33224   lo0
::127.0.0.0/104                    ::1                            UGRS        0        0      -   lo0
::224.0.0.0/100                    ::1                            UGRS        0        0      -   lo0
::255.0.0.0/104                    ::1                            UGRS        0        0      -   lo0
::ffff:0.0.0.0/96                  ::1                            UGRS        0        0      -   lo0
2002::/24                          ::1                            UGRS        0        0      -   lo0
2002:7f00::/24                     ::1                            UGRS        0        0      -   lo0
2002:e000::/20                     ::1                            UGRS        0        0      -   lo0
2002:ff00::/24                     ::1                            UGRS        0        0      -   lo0
fe80::/10                          ::1                            UGRS        0        0      -   lo0
fe80::%fxp0/64                     link#1                         UC          0        0      -   fxp0
fe80::2xx:xxx:xxxx:xxxx%fxp0       xx:xx:xx:xx:xx:xx              UHL         0        0      -   lo0
fe80::%lo0/64                      fe80::1%lo0                    U           0        0      -   lo0
fe80::1%lo0                        link#5                         UHL         0        0      -   lo0
fec0::/10                          ::1                            UGRS        0        0      -   lo0
ff01::/32                          ::1                            UC          0        0      -   lo0
ff02::%fxp0/32                     link#1                         UC          0        0      -   fxp0
ff02::%lo0/32                      ::1                            UC          0        0      -   lo0

Thanks a lot,
Rand

evilDagmar · 09-26-2006, 03:29 AM

OKay, that blows that theory.

...but...

It lets us know that unless you diddled the output for "privacy" reasons, that you're definitely connected to some reasonably intelligent equipment on the local end. The equipment that's been assigned the IP address 192.168.2.1... What kind of equipment is that?

If it's in your house, then that's going to be the only thing the ISP sees (meaning it shouldn't make a difference which OS you're using). If you're having communication problems, make sure you can actually ping it without getting strange results (high latency, lost packets, etc). You might just be suffering from strange luck and a dying router.

Randux · 09-26-2006, 07:50 AM

Quote:

Originally Posted by evilDagmar

OKay, that blows that theory.

...but...

It lets us know that unless you diddled the output for "privacy" reasons, that you're definitely connected to some reasonably intelligent equipment on the local end. The equipment that's been assigned the IP address 192.168.2.1... What kind of equipment is that?

If it's in your house, then that's going to be the only thing the ISP sees (meaning it shouldn't make a difference which OS you're using). If you're having communication problems, make sure you can actually ping it without getting strange results (high latency, lost packets, etc). You might just be suffering from strange luck and a dying router.

Yeah I have a router. It's a recent addition. The performance problems started well before I got that and while I had the cable company and ISP on the phone (and before) I ran with and without it to see if it was the problem. Exact same behaviour with and without. I tried everything I could think of short of swapping NICs. I changed cables etc. The results were always the same.

The ping is weird, typically it's erratic from my non-bloze machines and pretty consistent from bloze. I haven't seen anything like this in my life and I've been around since before there were PCs or routers or ISPs or cable companies...

What does it mean to you that with the browser proxy I get full speed from non-bloze endpoints and without it I don't? I think this must be telling us something but I don't know what.

Thanks,
Rand

Woodsman · 09-26-2006, 03:36 PM

Hey Randux,

You state that you are using a router. Thus, as already observed, this device is your sole interface with your ISP servers. The ISP servers always see the same MAC from the router and never sees any hardware info from your boxes behind the router. I wonder if, somehow, the router sees the Windows box based upon the NIC's MAC and treats that box differently than when you connect with the Slack box using a different NIC, which uses a different MAC.

You mentioned above that you have not tested by swapping NICs. A PITA, but perhaps that might be a good test. If the weird connection results follow the NIC, then you would be closer to an answer. At this point you don't know if the culprit is the NIC or the router, but the answer has to be one or the other---or both. If the weirdness follows the NIC then I would suspect that card. If not, then the router---although I don't know what kind of configuration in the router would affect the throughput based simply upon the OS. Yet, a simple answer to that last question is that your Slackware box is configured such that the router is getting confused. And you did mention that you tested with and without the router. So that points toward the NIC in that box or your Slackware configuration.

Just thinking out loud again---.