Comcast IPv6 - Asus RT-N66U Troubles

We were a dual-stack household -- for a while.  Comcast is one of the leaders in the evolution of Internet services from the old IPv4 to the new IPv6 service.

The old IPv4 network has run out of easy-to-allocate IP addresses (the numerical kind, like 130.132.20.1, that are roughly equivalent to your telephone number).  Among other advantages, the new IPv6 allows for gazillions of new addresses.  It will be a key enabler of the new "Internet of Things" that you may have heard about.

As this transition occurs (slowly, as there are so many v4-only systems installed), many of us will need to operate "dual stack" systems that are capable of using both forms of addressing.  Any modern desktop PC (Windows 7 and onward, Linux, etc.) already knows how to do this.  The weak link for many users will be their Internet Service Provider (ISP) that will have to reorganize itself to provide IPv6 services.  So, the good news -- our Comcast system does offer IPv6.

We were able to run dual-stack pretty well with the gateway device that Comcast rents us, a Cisco DPC-3941T.  (We need their gateway, because we use their VOIP telephone service.  That's another story.)  Our Linux operating system (and probably Windows, too) will prefer to use IPv6 over IPv4, when a given Internet service offers both.  Google sites all seem to offer IPv6, for example.

But it wasn't going to be that simple for us, because the Cisco gateway is "crippled". Comcast seems to have decided that a downgraded gateway can offer more security with fewer support issues for the 99% of customers who have simple needs.  It does not support a moderately complicated home network, like ours, where you might want to use specific IP addresses, firewall setups, etc.  In this situation, Comcast recommends that you operate their gateway in a non-routing mode and that you attach your own WiFi router that will be more configurable to local needs.

Enter the Asus RT-N66U.  On paper, this looks like a fine choice for us, offering very good dual-band WiFi and lots of configuration control.  With its standard setup (IPv4), we've had no problems.  (The VOIP service stays with the Comcast gateway.)  When we enable IPv6, things worked well, too, despite the lack of documentation or help files from Asus.

Worked well, that is, for a number of hours.  After a time, the IPv6 service just stopped.   The good news is that Internet service continued with only minor delays using the old IPv4 protocol.  The bad news is that IPv6 isn't reliable using the RT-N66U.  It starts up again if you reboot the router, but it will eventually die with the same symptoms.

According to the router system log, the router starts encountering ICMPv6 checksum errors.  After some substantial number of such errors have been reported, the router decides to drop IPv6 entirely.  That's my interpretation, anyway.  Where the errors arise is not clear.  It could be the Asus router itself, or it could be an interaction with the Cisco device, or something even further upstream.

I have tried all variants of IPv6 setup that I could think of -- enabling/disabling DHCP, response to Internet pings, etc.  Sometimes IPv6 seemed stay up for longer, but eventually it always dropped out.

So despite the initial excitement of operating a cutting-edge dual-stack household, we are back to plain old IPv4 for now.  Maybe someone will suggest a better router configuration, or maybe we will get a firmware update that fixes things.  Meanwhile, we're coasting along on tried and true IPv4.

Note added: To keep things in perspective, there is no great reason to run IPv6 at the present time.  It's just a game, until a significant number of services begin to be offered exclusively on IPv6.  That will happen eventually as the address exhaustion begins to be felt, but for now essentially all IPv6 services are also available via IPv4.

High speed, high cost: it's Comcast!

Comcast (dba Xfinity) is giving us tons of Internet speed these days, at least in our corner of Connecticut.  They gave us a new gateway that is now provides the results shown to the right.  Our current service started out at 50 Mb/s, but has more than tripled with little price increase.

That's all good, but the downside is that they are charging something like $1 per month per megabit per second. High speed is occasionally useful for downloading big files, but we could survive on a fifth of what they are giving.  I suppose a big household where 5 people are all looking at their own HD videos would need this bandwidth.  But that's not us!

The question is whether a downgrade of our "triple play" service would put us at a more reasonable price / performance point.  We'll see.

My home LAN gets used for special ham radio work, servers, and software development, so I need to set up DHCP with some assigned addresses and tailor the network in other ways.  Since Comcast has seen fit to cripple its gateway to prevent me from doing this, I've added a proper Asus RT-N66 WiFi router that runs off the Comcast unit operating in "bridge" mode.  The Asus unit is very nice, including IPv6 service, as you see above.

First FreeDV on Flex 6500!

I'm giving an "SDR" talk in a few weeks, and I thought I should try out some new (to me) stuff.  My Flex-6500 supports FreeDV as a built-in "waveform" app with some help from the Windows PC.

Nothing was happening on the magic frequency, 14.236 MHz, so on a lark I gave a call.  To my surprise, I got a quick answer from Walter, K5WH, in Houston TX.  The band was up and down, but he was 90% copy at least, and I seemed to make the grade myself!

FreeDV (FreeDV.org) is an open-source digital voice system, designed especially for minimal bandwidth communications on the HF bands.  Voice fidelity isn't perfect, depending a little on current signal levels, but it's remarkably good for ~1.5 kHz (less than normal analog SSB).

Morse Motivation!

I've been amiss not contributing to the blogosphere for some time -- busy with some writing assignments.

But this article from 7 years ago came into my inbox today.  It reminds me that there's a lot of room for improvement when it comes to Morse communications.  It needs old-fashioned wetware effort.  (No computer CW for me!)

We won't all achieve 140 wpm or anything like it, but I, for one, have been stuck on a plateau around 20 wpm for many years.

A while back I was inspired by a FISTS article IIRC about the guy who made the simple resolution to have at least one Morse QSO every day.  It seems like such an easy thing -- but he had been doing it for many many years. 

I don't know what goal I should set, but I do need one.

Flex 6500: 11 M band opening

I thought I had seen band openings before, but this is what I saw with the new Flex 6500 this morning:

FlexControl for Linux+ #hamr

Lately I've been on the air with a FLEX-6700 from FlexRadio Systems.  It's a great rig, but that's a story for another day.

Today's subject is the beautiful FlexControl, which is a "USB Knob" ($99.99).  It is designed as an adjunct input device for the Flex software defined radios, for users who need something more traditional than mouse-based pointing and clicking for tuning and managing a radio.

The product is provided for SmartSDR for Windows, the principal interface program for the Flex 6000 series.  It has a great feel, and it has 3 nice buttons and status lights. SmartSDR provides a Windows driver to work with the FlexControl.

So that's fine, but I'm mainly a Linux guy.  For unfortunate but understandable reasons, Flex only provides Windows control software.  What does the FlexControl look like when plugged into a Linux system?  I could not find any documentation.

With help from Wireshark and VirtualBox, we can do some reverse engineering.

The FlexControl is recognized by Linux (Ubuntu 14.04, but probably most other versions, too).  It appears as /dev/ttyACM0 on my machine. "ACM" signifies that this is a CDC_ACM device.  That category is loosely based on ancient Hayes modem interfaces, but don't worry about that!  Really, it just emulates an old-fashioned serial I/O connection at 115 Kbps.

You can set up minicom or any other Linux program to talk to this device.  The only remaining question is the protocol.  It turns out to be simple.  No surprise, this is a simple device.  The scoop:

Sending from FlexControl to host:
All commands terminate with ';' (no returns or line feeds)
U; - knob CW (single tick) -- U02; U03; U04; etc - multiticks
D; - knob CCW (single tick) -- D02; D03; D04; etc - multiticks
S; - short press, main knob
L; - long press, main knob
C; - fast double click, main knob

The fast knob codes reflect multiple encoder ticks between USB polling times, so the knob should be able to keep track of fast spinning.  (Alas, SmartSDR will not always keep up so well.)

XnS; - normal press, key n=1,2,3
XnL; - long press
XnC; - fast double click
e.g. 
   U; (frequency up one tick)
   X2S; (normal press, button 2)

Sending from host to FlexControl:

Ixyz;  where x,y,z = 1 or 0 for LED 0, 1, 2 on or off
e.g.
   I001; set right hand LED on
   I000; set all LEDs off
   I111; set all LEDs on

Note that SmartSDR for Windows only uses a fraction of the FlexControl's button capability.

See a simple Python program to illustrate how to communicate at http://aa6e.net/wiki/FlexControl. 

[Added 4/24/2023: That link has gone dead.  A copy of the old file can be found at http://web.archive.org/web/20150226074911/http://aa6e.net/wiki/FlexControl. Note that the code is written in version 2 Python.  It will need updating for version 3.]

The FlexControl should be very useful for all kinds of DIY software projects.  Connect it to your Raspberry Pi, your Arduino, your Linux PC for any kind of control project! (There are cheaper USB based controllers available -- for games, etc., but few have the right "ham" esthetics IMO.)

Maybe FlexRadio or one of the designers (K6TD or K6TU) would have divulged the same data if they were asked nicely, but it was more fun to work it out on my bench.