Nachbarn bei uns haben neulich berichtet, dass sie sich kein #Glasfaser ins Einfamilienhaus legen lassen wollen, weil man dann auch zu Deutsche Glasfaser wechseln muss, was soweit richtig ist, dafür ist halt der Anschluss kostenlos bis an die Stelle wo aktuell die Telefondose ist.
Die Nacherschließen irgendwann in ein paar Jahren könnten dann nach gültiger Preisliste 1000€ kosten. Telefon und Internetanschluss von denen ist im gleichen Preisbereich wie auch das #VDSL was es hier aktuell gibt.

Falls eure #Eltern auch so 70 Jahre alt sind und das nicht mehr so ganz durchschauen, sagt denen die sollen euch sagen wenn bei denen sowas im Ort gemacht wird, damit ihr schauen könnt ob das Sinn macht.

Wenn #DSL und #VDSL einen ähnliche Weg geht wie ISDN oder analoge Telefonanschlüsse, dann sitzen die irgendwann im Alter ohne #Internetzugang im Haus. Ist unwahrscheinlich, aber diese Ersterschließungen sind halt auch wirklich fair was den Preis angeht (0€).

Here's another #post-mortem for you.

Tl;dr: Be sure your diagnostic tools show everything and do not hide vital information even though running in verbose or verbose-verbose mode.

First of all: My home #network is not as simple as it could be and certainly not as simple as it would be with most private users around the globe.
That brings with it its very own bunch of challenges, none of which is of any particular concern here. Suffice it to say, a regular consumer-grade internet access device (colloquially "WiFi router") would not do it. I have heavier requirements.

That in turn means my #ISP did not supply me with a real router – in fact I decline any ISP-supplied device whenever possible. Instead I bought my own device which does fulfill my requirements, in this case a semi-professional router with #PPPoE #pass-through capabilities, essentially a #DSL‌-modem.

The latter is the important part, because that is where my weekend worries began.

The modem did work for years on end with no reason for me to ever regret my decision to buy it in the first place.
Until last friday morning when it rebooted from the latest firmware upgrade.

At that very moment my internet connection dropped with a very dreaded error message from the #PPP daemon: "Timeout waiting for PADO packets."
That's tech-talk for "the ISP does no longer reply to my connection requests."

The message was already known to me and experience had me on the side of stupid coincidence which I have seen more often than I could count. So, quickly I was on the phone with the ISP requesting a port reset hoping for instant recovery.
Which didn't happen.

I'll skip the boring part of booting, downgrading, recabling and testing (even with a new OS install) for hours while other people expected me to work, but it went on until monday morning. Needless to say, I had a lot of time to think during the weekend.

I will just mention that most of the time I got beyond that PADO step, yet #pppd failed to get any replies for its #LCP configuration requests (that way I can add some more hashtags to the post, yay!).

On monday morning I finally figured I should do a real trace of the conversation appearing on the wire, for as far as #tcpdump told me not only was I sending requests, I even got answers from the ISP. Only, they were ignored by my endpoint software.
tcpdump's console output did not reveal why this should happen, a different network card, updated endpoint software - nothing actually helped. Requests were sent, replies came in and were promptly ignored.

Until I was fed up enough and decided to have a deep look into that very conversation on the wire, using #wireshark. Wireshark is a very powerful tool and its most notable feature is it doesn't hide any information by default.
And it was this now unhidden information which finally pointed me in the right direction: The oh-so-dutifully ignored replies from my ISP carried with them a #VLAN tag.

Short excursion: I am using a #VDSL landline on which the provider offers "triple-play", that is, Internet, Telephone and TV all over the same cable. For that to work technically, the ISP requires its customers to tag their "regular" outgoing internet traffic with a certain VLAN id before sending it out to the ISP. Likewise, the ISP tags all incoming internet traffic with same id.

Usually, the modem should do the tag/untag of the traffic before handing it over to the LAN, in my case to my PPP endpoint.
And it was this very tag/untag which actually stopped working.

From this point on the solution was pretty simple: If the tagging inside the modem is unreliable, the feature can be disabled (in fact, it can be configured to suit the ISP's requirements). So I did that. Now that caused the situation to deteriorate in the first step, because now nothing was coming back at all anymore. Where at least I got ignored replies from the ISP before now I got nothing.

However, #linux is capable of a lot of things, one of which is making network cards do "the right thing". In this case I reconfigured the system's network to add the required VLAN tag to everything related to the much needed PPP connection. A side effect is that the kernel now also removes the tag from any incoming frame.
At this point my PPP endpoint finally got the replies again and within seconds the connection was back up as it was designed in the first place.

Needless to say I think it's a bug in the modem's firmware, yet since downgrading did not improve the situation, it seems the bug was introduced much earlier but never manifested itself.
Also, to reference the "tl;dr" from above: Had I done the wireshark trick right from the start I probably would have stumbled over the wrong VLAN tag much earlier, saving me a lot of testing hours as well as a lot of worries on how to get the system back to its intended state.
The lesson I learned is that even though diagnostic tools can be made to be very verbose, sometimes they still skip some information vital to the issue in question and thus can not necessarily be fully trusted. It is not only important to have those tools at hand, it is quite as important to know their limitations and how to handle or overcome them.

OpenWRT on a Netgear DM200 ADSL Modem

Another bit of craptacular consumer tech gets the boot.

Ever since picking up a new DSL modem a ways back I'd been wanting to get OpenWRT up and running on it. That process turned out to be ... involved. Though with a bit of path-smoothing it could have gone far better.

The major pitfalls encountered were:

• Determining the proper flashing method for installing the OpenWRT firmware. Which affects the next point:
• Determining which OpenWRT firmware to install.
• Determining how to recover from failed attempts and revert to Netgear's OEM firmware.
• Properly configuring the WAN DSL interface.
• Having the appropriate documentation available whilst offline during various experiments.

OpenWRT's documentation is excellent -- far better in detail, substance, and quantity than Netgear's DM200 offerings. But as with most FOSS projects, the fact that it attempts to cover a great deal of territory means that there's possible confusion as well.

The Netgear DM200 ADSL modem is a modest, US$60 unit capable of 100 Mbps speeds -- a service ceiling I'm unfortunately at no risk of exceeding. It sports 64 MB RAM, 8 MB Flash storage, and is built on the Lantiq XWAY VRX220 SoC, with a 500 MHz dual-core MIPS 34Kc V5.6 CPU. Yeah, I've got a multiprocessor modem.... Connectivity is a 10/100 Mb RJ-45 Ethernet port and an ADSL/VDSL RJ-11 port. Power is 12V 0.5A, size is roughly an old multi-disk CD jewel box. Nothing fancy, but sufficient to task. OpenWRT supports the device well, including the ADSL/VDSL2 modem.

Choosing the flashing method

TL;DR: for installation onto a system already running a vendor's OEM firmware, the factory install method. This relies on the (generally) built in firmware-updating capabilities of networking kit, and is pretty sane.

Choosing the right firmware

The OpenWRT Netgear DM200 page will point you at the current downloads. Again, factory firmware is what you're looking for. The "sysupgrade" image is for use with systems already running OpenWRT. You're not there yet.

Restoring the OEM image

In the best Sorcerer's Apprentice tradition, it helps tremendously to know how to get back to the status quo ante after you've been stretching your wizardly ambitions. For most modern network kit, you can use a TFTP client to send a firmware image to the device at boot time.

This is pretty clean and no-fuss, once you have the parts and process together.

You will need:

• A tftp client. I prefer command-line tools (they're scriptable), though there are GUI clients as well. Linux, OSX/MacOS, and Windows all have the BSD tftp utility available. Your distro's repos -- apt, yum, ports, Homebrew, etc., will provide this if it's not already installed.

• Your vendor's OEM firmware image. You'll need to download this BEFORE you go cutting off your Internet connection, along with a few other details (like all the documentation you'll need).

• The device's default IP address. For the DM200, that's 192.168.5.1, a fact Netgear's own KB misstates, just sayin'....

• An Ethernet cable. This is a wired-access process.

• A device that can talk to the modem. A desktop or laptop system, which can accept an Ethernet cable. Your Smartphone, tablet, or no-ports super-skinny notebook computer may not cut it.

Note that this is client-side stuff -- you don't need to get fancy-pants with TFTP daemons, BOOTP, DHCP servers, or any of that jazz.

I wrote a brief script to manage the process of bringing down my network connection, bringing it back up, then sending over the files:

sudo ifconfig eth0 down
sudo ifconfig eth0 192.168.5.10 netmask 255.255.255.0 up
/sbin/ifconfig # to verify settings
tftp 192.168.5.1 <<EOF
verbose
binary
#trace
status
put DM200-V1.0.0.61.img
status
quit
EOF

(Mac users will probably use en0 rather than eth0 for their network device.)

You should see the put command, and then the bytes transferred and seconds elapsed (~30s or so). A timeout means tftp couldn't find the modem.

If things aren't working as intended, you can try uncommenting the "trace" line for additional debugging info.

The modem will take a few minutes (generally ~4) to receive, load, and boot the new image. When it does so, the power LED will shine constant green, and you should be able to down and up your interface, this time under DHCP, to talk to the modem again:

sudo ifconfig eth0 down
sudo dhclient eth0

I don't have NetworkManager (a/k/a NetworkMangler) running on this system, you may need to shut that down to regain full control of your senses network, on systemd afflicted based Linux systems.

A saved OEM system configuration will allow you to restore settings from the backup, so that's another good preparatory step.

DSL configuration

As noted, the key item for PPoE configuration was setting the MTU to 1492 rather than 1500. Ideally, OpenWRT would take care of this itself, but presently it does not.

Have local documentation

After the first failure at getting DSL configured, in which I did not have much of the OpenWRT documentation locally accessible, I opened up multiple pages in browser tabs, and saved several as PDF or HTML format. The fact that OpenWRT doesn't have a single PDF- or ePub-formatted documentation set to download is actually slightly annoying. I've been exploring various web-based archival tools, and might try to mirror the site (or similar projects) using tools such as HTTrack or wget in future.

End result: some pain, some lessons learned, and a working system.

Why Bother?

So what does this buy me?

I'd had a few frustrations with the stock Netgear OEM image.

• The interface was at best cumbersome. At worst, confusing, inconsistent, misleading, and useless. And it was slow.
• The software was not frequently updated, a point of concern after the FBI issued a national request for people to reboot their broadband modems last year.
• There was no SSH server, though an undocumented telnet daemon existed, requiring visiting a specific page (debug.htm) to launch.
• There was no remote-logging or management capabilities.
• The shell tools were limited, with annoyances such as a fixed-screen-size "less" utility (25 rows only, I tend to run my terminal windows larger).
• System logs were primitive and only accessible via the web interface. Logs were not timestamped, a fact which is stunningly inane.

Out of the box, OpenWRT gives regular updates, SSH, remote syslogging, a vastly better designed and more responsive Web interface, and a less that handles arbitrarily-sized terminals. I'm exploring other packages and built-in features as well. The limited size and power of the modem suggest keeping aspirations limited, but having options is useful.

The other issue has been occasional service issues -- some local/internal wiring, some ISP-related. Having a more powerful, flexible, and shell-addressable (via SSH) set of tools may be useful with these if (!) they occur in future.

And -- with a Turris Omnia router, I've got another OpenWRT-based device and standardising on the toolset seems useful. The Omnia is far more powerful and has much more memory (2 GB) and storage (8 GB), the latter of which is further expandable with either internal or external storage. A nice set-up, actually.

So I'll be looking into the options and opportunities here for a while.

But if you're running the DM200 or similar kit and would prefer a Real Operating System on it, well, here's a quarter.

#Networking #OpenWRT #DSL #ADSL #VDSL #DM200 #Linux