I'm having a problem with network connections. I'm not sure
when this started exactly, but I have been noticing sporadic
slow PPP speed over the last month or so. I first thought
that it was my ISP's problem, but I could not (at the time)
duplicate the slowdown.
Over the last week or so I began to notice that the slowdowns
occured while Netscape (3.0b4) was left up between bringing
the PPP down and then back up again. I use kerneld to bring
up my PPP connection and have pppd timeout after 10 minutes
and bring down the connection. Right before the PPP connection
is closed I will occasionally notice the following:
Proto Recv-Q Send-Q Local Address Foreign Address (State)
User
tcp 1 0 dialup166.tesser.:1437 netrover.com:www CLOSE_WAIT
rob
tcp 1 0 dialup166.tesser.:1436 netrover.com:www CLOSE_WAIT
rob
This will stay in this state the entire time that the PPP
connection is down. When I bring up the PPP connection
later, the connections in CLOSE_WAIT will stay that way
for quite some time. A while later it will switch to:
Proto Recv-Q Send-Q Local Address Foreign Address (State)
User
tcp 1 1 dialup166.tesser.:1437 netrover.com:www LAST_ACK
root
tcp 1 1 dialup166.tesser.:1436 netrover.com:www LAST_ACK
root
Of course the "Foreign Address" is whatever I had Netscape
connected to last. The connection is *very* slow. I get 1-2
second ping delays to the *terminal server* one hop away.
Very bad indeed. The only way to fix this is to allow the
CLOSE_WAIT and LAST_ACK to timeout, then bring down the PPP
connection. Once re-established, the PPP connection performs
as it should. This last bit about bringing the PPP connection
down then up could be superstition on my part. I need to test
this assumption some more.
This behaviour doesn't seem to occur with all web pages.
When Netscape is pointed to www.yahoo.com, for instance,
it goes through CLOSE_WAIT and LAST_ACK very quickly. I'd
say within a few seconds of completing the page transfer.
It seems that some others, however, seem to never close
the connection properly until Netscape exits. If the PPP
interface goes down, even for a short while, Netscape
cannot close the connection properly.
I just noticed... the connect state will switch from
CLOSE_WAIT to LAST_ACK after I close Netscape. I'm not 100%
sure (i don't *think* it does) that this happens every time.
Also... bringing the PPP connection down while in LAST_ACK
seems to completely close the connection. (Not tested)
If I start and close Netscape during the same PPP session,
the same connections that cause the problems close as they
should. The fact the kerneld is starting the PPP connection
has nothing to do with the problem, since it occurs if I
manually start and shut down the PPP link. PPP is loaded
as a module, but it doesn't matter if the module unloads
or stays resident between the time PPP connection goes down
and comes back up.
It's late and I'm tired. I may have mis-interpreted some of
the interactions. I did not duplicate all of the minor
details. But the PPP slowdown is very repeatable for me.
Connect via PPP. Start Netscape. Point it to
http://www.netrover.com/~eyevet/irc.html. Wait for the
page to finish loading. Bring down the PPP connection.
Check netstat - it should give connection in CLOSE_WAIT.
Restart PPP. PPP is now *very* slow.
Now... I have a couple of questions:
1. Does this make any sense whatsoever?
2. Is there any way to manually close a connection? (the
connection will stay in LAST_ACK until it times out
after Netscape exits.)
3. Anyone else noticing this?
Rob
(rriggs@tesser.com)
P.S. In case you need it:
Linux diamond 2.0.8 #1 Sat Jul 20 01:24:49 MDT 1996 i586
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KERNELD=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_OPTIMIZE=y
CONFIG_SYSVIPC=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_JAVA=m
CONFIG_KERNEL_ELF=y
CONFIG_M586=y
CONFIG_M586_COPY=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_TRITON=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_FIREWALL=y
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
CONFIG_IP_ACCT=y
CONFIG_NET_IPIP=m
CONFIG_INET_RARP=m
CONFIG_IP_NOSR=y
CONFIG_SKB_LARGE=y
CONFIG_IPX=m
CONFIG_ATALK=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_PPP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_ISA=y
CONFIG_NE2000=m
CONFIG_CD_NO_IDESCSI=y
CONFIG_SBPCD=m
CONFIG_MINIX_FS=y
CONFIG_EXT2_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=m
CONFIG_PROC_FS=y
CONFIG_NFS_FS=m
CONFIG_SMB_FS=m
CONFIG_NCP_FS=m
CONFIG_ISO9660_FS=y
CONFIG_SERIAL=y
CONFIG_PRINTER=m
CONFIG_RTC=y
CONFIG_SOUND=y
CONFIG_SB=y
CONFIG_ADLIB=y
CONFIG_AUDIO=y
CONFIG_YM3812=y
SBC_BASE=220
SBC_IRQ=10
SBC_DMA=1
SB_DMA2=5
SB_MPU_BASE=330
SB_MPU_IRQ=-1
DSP_BUFFSIZE=65536