We live quite far from our telephone central office, and the highest available speed is 0.768Mbit/sec. We want to speed up our internet access. Verizon does not make FIOS available at my address, and the alternative is Time Warner Cable.
As of 2012-04-10 Time Warner offers 10Mbit/sec download, 1Mbit/sec upload for $30/month, or 15Mbit/sec download, 2Mbit/sec upload for $40/month; these are introductory prices, and the cable modem is free for 6 months and $2.50/month thereafter. Higher speeds are also available. We picked the 15Mbit/sec plan.
Installation was uneventful. The technician actually arrived before the scheduled time, knew what he was doing, had the needed equipment and supplies, used safety equipment when up the pole, and got the service working (as defined by Time Warner) almost on the first try. This was an exemplary installation, particularly compared to other people's nightmare stories posted on forums.
However, several days of nightmares began for me at that point.
The cable modem is a Cisco 2100, originally rebranded from Atlanta
Scientific (made in Taiwan) and now manufactured by Anatel (China). Model
DPC 2100 R2. Its ports are power (12V), F (coax cable), USB type B (full
size) device port, and RJ45 Ethernet. As supplied from Time Warner it is
already in bridge mode, and I believe this is the only mode it can operate in.
Bridge mode
means that it effectively connects the cable's data
subchannel to the host computer, receiving packets from either side and sending
them unchanged to the other side. The host computer handles obtaining
an IP (Internet Protocol) address via DHCP, repelling hostile sendings from
hackers (firewall), and passing packets to other machines on the local network.
This is what I want it to do.
We are using Ethernet to connect the cable modem to our router, which runs Linux. Time Warner promptly assigned an IP address. One of their good features is that they consistently assign the same IP address for weeks at a time even if the client does not request the address (having released the lease previously). I'm pretty sure they cue on the modem's MAC address to recognize the customer and his service level. The USB interface has a different MAC address (by 1 bit) and you need to tell them which MAC you will be using. Leases last about 12 hours ± 1 hour or so.
I found that my router's USB subsystem reset about twice an hour, with double events (one or two minutes apart) more common than expected by chance. The error message was (timestamps redacted):
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 1-1: USB disconnect, device number 19
asix 1-1:1.0: eth1: unregister 'asix' usb-0000:00:0f.5-1, ASIX AX8817x USB 2.0 Ethernet
etc. etc.
And all of the USB devices on all the ports are ejected and reloaded. This
occurs when the USB NIC is connected to the 7-port hub (USB-2.0), and also when
connected to the host's own USB 2.0 port. I'm inclined to take the note about
EMI?
(electromagnetic interference) seriously. There could be EMI from
the incoming cable signal, but I think it's more likely that when the cable
modem transmits on the cable, significant signal escapes on the other ports.
Forum posters report similar experiences with the Cisco 2100. Respondents sometimes suggest that they scream at customer service and get them to replace the cable modem. However, given my experience with electrical engineering, I'm inclined to blame a design glitch, such as cutting corners on internal filtering for the Ethernet port. Thus I expect that a replacement cable modem would be generally as troublesome as the one I have.
100 feet of cable. My first attempt to attenuate the alleged EMI was to replace the 1 meter Ethernet cable with 100 feet (30 meters) of cable. This was effective; no USB resets occurred over at least 3 continuous days. However, a fat roll of cable on the floor decreases the WAF (Wife Acceptance Factor) of this solution.
Ferrite ring. The second solution was to wrap the 1 meter cable through a big ferrite ring that I have: 10 turns. This was partially effective, one reset over about 24 hours of use.
USB Network. I borrowed a USB device cable with builtin ferrite EMI suppressors. While I had it connected for about 24 hours there were no USB resets. However this solution was not satisfactory because Time Warner would not assign an IP address through the USB interface.
Conclusion. I'm sure that I could have talked to customer service and changed to the USB MAC address, but given the overall direction that this experience is headed, I decided to let sleeping weasels lie and to revert to the 100 foot cable, for which I found a neater location.
The next problem was in TCP/IP connections, such as viewing web pages, retrieving e-mail by IMAP, sending mail by SMTP, or connecting to a shell account at work by SSH. These activities worked on the router, but for other machines on the local network the client would announce that it had connected, then wait forever for the payload. For the shell account I could start the shell and do simple commands, but as soon as a command produced a lot of output the session would freeze up permanently.
The reason is that Time Warner uses a MTU (Maximum Transmission Unit) on the cable of 576 bytes, the minimum allowed by RFC 791, whereas most of the Internet uses 1500 bytes. When my router gets an IP address the DHCP server announces the MTU as well. When the router originates a TCP connection it knows that normal-sized packets cannot get through, so in the initial SYN packet it includes a MSS (Maximum Segment Size) option of 532 bytes, the MTU minus the size of the TCP header. This tells the server to send small packets, which it does, and the connection delivers the payload.
The hosts on the local network, though, know nothing of the downstream network, and they give a MSS option of 1456 bytes, appropriate to the local network. The connection-beginning packets are short so the connection gets initiated, but the servers send back 1500 byte packets, which Time Warner's ingress router tosses because they won't fit.
At this point the ingress router, according to RFC 1191, must send back an
ICMP (Internet Connection Management Protocol) packet of type 3 subcode 4
host unreachable, packet too large
, whereupon the server would either
send smaller packets or turn on the feature of fragmenting packets at the
router (IPv4 only). But it doesn't. I tested this on my work machine, and
although my router does send the ICMP host unreachable packets to local network
clients, Time Warner does not send them to my work machine acting as a server.
It turns out that this problem can be solved. See Peter Holland's blog post about MTU discovery dated 2011-08-23 for a recent discussion, but this solution has been around for quite some time. The router is to be configured to mangle SYN packets passing through, to reduce the MSS option to the size it knows will fit. If you have a commercial router, get into its configuration and make sure that path MTU clamping is turned on. I have a comprehensive firewall on my router machine, running Linux, and in the IPv4 and IPv6 filter FORWARD chains I added this, where it will affect all thru traffic, specifically every connection-beginning SYN packet:
iptables -t filter -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
This done, my internal hosts are happily connecting to external TCP servers. Most customers only use TCP connections, and would consider service to be satisfactory at this point.
I use several datagram protocols, some of which are adversely affected because Time Warner fails to comply with RFC 1191. The protocols are:
Domain Name Service. This service translates alphabetic host names into IP addresses, among other things. Responses are usually but not always short. Presumably Time Warner's DNS servers are configured to send fragmented packets when their own MTU is exceeded, but when a query is made to an outside DNS server it would not be told that it needed to reply with a fragmented packet.
Network Time Protocol. This provides accurate clock synchronization to the clients. Normally the UDP packets are short and it is undisturbed by the small MTU.
Kerberos. This is the generally used high security authentication service, often required for admission to corporate or university sites. When the server sends back the encrypted ticket in a UDP packet, it never arrives through Time Warner's net. Fortunately Kerberos can also use TCP. In your krb5.conf file in the libdefaults section, specify udp_preference_limit=1 meaning to use TCP for all packets bigger than 1 byte. Then, Kerberos authentication is possible if the router is mangling the MSS in SYN packets.
OpenVPN. This VPN (Virtual Private Network) protocol encrypts
generic traffic and packs it up in UDP packets. Other VPN protocols such
as IPSEC do it similarly, with the encrypted traffic sent in various kinds of
datagrams, generally one datagram per content packet. Traffic from the remote
end is lost if the datagrams do not fit in Time Warner's MTU. As with other
datagram protocols, packet fragmentation could have been turned on if Time
Warner had sent the ICMP host unreachable
packet required by RFC 1191,
but they don't. So VPNs in general and OpenVPN in particular cannot be used
through Time Warner's network.
TCP Meltdown. PPTP is a Microsoft-ish VPN protocol which always
uses TCP, and OpenvPN can also be configured to use TCP, but this requires
cooperation at the server end which is usually not forthcoming. These would
work through Time Warner's cable. But VPNs or other tunnels on TCP are subject
to the dreaded TCP meltdown
syndrome. If packets are lost, TCP for both
the tunnel and the payload stream will demand that the other end
retransmit them. If the packet loss rate is over 50%, the
frequency of retransmissions will increase without limit. Thus it's
recommended that tunnels should use UDP or another datagram protocol, letting
the payload TCP stream handle retransmissions.
IPv6 Tunneling (6in4). Each computer needs a unique numeric IP (Internet Protocol) address. In the original version, called IPv4, there are exactly 4294967296 possible addresses. As of fall 2011 all of them have been assigned. In the late 1990s a new IP version was worked out called IPv6, which has 340282366920938463463374607431768211456 possible addresses, which should be enough for the forseeable future. Modern operating systems such as Linux, Windows and MacOS are able to use these addresses. However, retail ISPs such as Time Warner are generally stuck firmly in the 1900's, making do with their already assigned IPv4 addresses. Clients like myself who want to be ready for the new world order in cyberspace need to make an IPv4 tunnel to an ISP that can do IPv6. It is like a VPN except not encrypted, it uses a datagram protocol, and it fails on Time Warner's network for the same reason a VPN does.
VoIP. For voice chat (telephone calls on the Internet), both SIP, the protocol to set up the call, and RDP, the protocol for the voice stream itself, use UDP. If these packets cannot get through, you can't do VoIP on Time Warner cable.
Conclusion. It's a showstopper for us to not be able to use the VPN, VoIP, and other datagram protocols.
Normal
customers will get good service from Time Warner Cable if
they use one computer directly attached to the cable modem (not by a USB NIC),
or if they use the preconfigured router that Time Warner provides at extra
cost, and if they do only ordinary activities like viewing web pages, watching
videos, or downloading MP3s. I, however, use the Internet for my work, and
datagram protocols are important to me. Do my family and I want to depend on
an ISP which does not follow a basic Internet networking standard, RFC 1191,
and for which it seemed that every time we turn around we need to put a
Band-Aid on some aspect of their service, and for which the Band-Aids ran out
for an important category of network activities that we use?
We have decided to cancel Time Warner Cable service and revert to 0.768Mbps DSL from Verizon. When eventually FIOS is installed in our area, we will immediately adopt it. Preliminary testing on a friend's machine indicates that FIOS does not suffer from the problems Time Warner gives its customers.