Date: Mon, 04 Sep 2000 08:24:16 -0700 From: Phil Staub <phils@staub.net> To: freebsd-net@freebsd.org Subject: DSLl and ssh questions Message-ID: <39B3BEA0.B3726565@staub.net>
next in thread | raw e-mail | index | archive | help
I'm running a FreeBSD 4.1-RELEASE system (Pentium-166) connected through a PicoBSD 3.4 firewall (AMD 486DX4-100). The 4.1 system is a dual homed host, serving as a gateway to a mixture of Windoze and other FreeBSD boxes. It has an NE2000 clone on the local network side and an Intel Pro 10/100B/100+ on the firewall side. The firewall machine has a RealTek 8139 on the inside and a NE2000 clone on the DSL side. The DSL modem is a Cisco 675 in bridging mode. The firewall ruleset currently has 18 rules, and is providing NAT translation for the inside network. I recently switched from cable modem to DSL (got tired of @Home's outages and other limitations), and started seeing relatively frequent long pauses (sometimes 15 seconds or more) during an interactive ssh session with a remote host. I'll type a few characters and all will be well, then the next few will not be echoed for a long time. Nothing is lost, it just takes a very long time to echo the characters and respond. Also, if I'm editing a file on the remote machine, screen updates sometimes pause for similar periods. Oddly enough, if I try the same thing over an insecure connection (e.g., via telnet), I still occasionally get delays, but they are very short compared to what I'm seeing with an ssh connection. Also, pinging an outside host from inside for an extended time results in between 10% and 15% dropped packets. Going the other way (pinging the machine behind my firewall/NAT machine) gives similar results. Trying to understand what may be happening, I captured an scp session with tcpdump into a file and then started printing out what I captured with different options, and I also looked at the overall session statistics with tcptrace. Two things stand out: 1. tcpdump reports a *lot* of truncated incoming packets. When a packet is received truncated, it is almost immediately received again. Often, this retransmitted packet is still truncated, but has fewer bytes missing, until eventually the entire packet is received. 2. The tcptrace -l report is consistent with item 1: out of 993351 bytes sent in 695 packets, 562 packets containing 812437 bytes were retransmitted packets. The connection in the other direction is not nearly as bad (though since this was a file copy from the remote machine to the local one, there was not nearly as much traffic this way): out of 483 bytes sent in 10 packets, 1 packet containing 1 byte was retransmitted. Also, tcptrace reports 561 hardware duplicates on the down link and none on the uplink. Clearly something is *very* wrong. I'm a bit suspicious of the RealTek NIC in the firewall, but I was noticing similar problems when I was initially setting up the DSL without the firewall machine in the line (though I wasn't set up to take the tcpdump/tcptrace measurements at that point). Three questions: 1) Is this *really* typical DSL behavior, 2) if not, where do I go next to track this down, and 3) if the RealTek NIC is suspect, would a 3com 3C905C-TX-M that came with the DSL modem installation package be a reasonable alternative? I've already been on the phone with USWest (the DSL provider, though I'm not using them as an ISP), and they told me how to change the signal level on the wire to reduce the error counts at the DSL modem level to a pretty acceptable number (well under 1%). But I have to think there is something else going on here. I'd appreciate any insight that anyone can offer to shed some light and help me figure out who I should talk to to get this straightened out. Thanks, Phil -- Phil Staub, KE7HC phils@staub.net Unix: because reboots are for hardware upgrades To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39B3BEA0.B3726565>