Zugschlusbeobachtungen

It’s been a while since I blogged. Partly because my work has become more private so that I cannot write too much about it, and partly because other bloggable things in my life simply didn’t happen.

In August 2024, I spent a week on vacation in Switzerland.

The boring way to travel from Chamonix in Haute-Savoie, France to the Valley d’Aosta (in German: Aostatal), Italy, is to take a car or a bus and go through the Mont Blanc Tunnel. It’s about a 30 minute trip that way, with 12 minutes in the dark.

Young and sporty people can hike over the mountains. It’s easy, just 3000 meters. Height meters. But I cannot tell you exactly, Google Maps insists that you hike west of the Mont Blanc, which is 100 km and a 30 hour hike. That’s very obviously wrong.

Or you can take the route for the crazy: With in total five cableways over the Aiguille du Midi and Pointe Helbronner (named after the french topographer, alpinist and geodesist Paul Helbronner, who pioneered cartography of the French Alps) to Entreves, which in turn is a neighborhood of Courmayeur. The ride from Aiguille du Midi to Pointe Helbronner is one of the most spectacular ropeways in Europe. You’re crossing the border between France and Italy either in the middle of the tunnel or on the summit of the mountain Pointe Helbronner.

There is surprisingly little current information about this trip on the Interweb, and this is also a reason for me writing this in English to make the information available to a broader audience. Sorry for some of the links being in German. A lot of the information found on the Web is outdated, especially the one about tariffs. It is hard to obtain current information if you don’t speak French AND Italian. And, frankly, I got the impression that the French and the Italian don’t cooperate well here, despite a sign on Pointe Helbronner claiming that „The journey continues, bypassing the border (…) to bring the two nations together“, and Chamonix and Courmayeur having a relationship as „Sister City“.

You can continue reading after the click

From the perl DBI manual page:

If you'd like the cache to managed intelligently, you can tie the hashref returned by "CachedKids" to an appropriate caching module, such as Tie::Cache::LRU

And what happens when I don't do this? Will my cache be unintelligently managed then, with the consequence of my machine exploding when the cache is filled with more than a handful entries?

It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.

In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I haven't yet found a satisfying solution: Naming of block devices in guest instances.

This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version of this blog article has found solutions for the main question. I should have written this in English in the first place and am thus translating from German to english, hoping that there will be some answers and suggestions.

KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or SCSI device brings a performance penalty.

The devices brought into the guest via virtio appear in the guest's dev as /dev/vd<x> and do also have their corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at least if it's a block device partitioned inside the guest and formatted with ext3 (I didn't try anything else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume the PCI paths of emulated hardware as stable.

Steinar H. Gunderson, sesse, has written an interesting article about TCP performance. I didn't find your blog's comment function, so I am commenting with a trackback. (note: which didn't work either, "The auto-discovered trackback URI does not match our target URI")

I frequently use mobile internet, using various of the German GSM/UMTS network operators, out of a moving train. As you have written, this frequently causes packet loss which is not only not caused by congestion, but sends the congestion avoidance algorithms on a false path.

For example, when the train passes through the 3575 m long Distelrasentunnel between Frankfurt and Fulda, my network link is broken for like two minutes. Passing through other parts of Germany sometimes gives me a ping response of hundreds of thousands of microseconds by virtue of the rather huge send buffer the UMTS equipment has.

In these circumstances, ssh sessions frequently take tens of minutes to notice that the network is back before the session is useable again. Frequently, it doesn't come up again before an hour has passed. And I have not found a way to work myself around this. Can you explain what's happening here, and do you have any ideas to solve the issue?

This is a rant. A rant which goes to the grub maintainers, and one that could go nearly identically to many people in the KDE environment or many other open source projects.

I really like grub. I really like grub 0.97 despite that it's been unmaintained for years and not booting on two of my important machines. I should like grub 2 because its configuration looks more straightforward and for its better features - direct booting of .iso images, from LVM and RAID. But actually, I have learned to hate grub 2 since it is not finished and badly documented, and that its existence is already being used as an excuse for grub 0's development having stopped years ago (and it being renamed to "grub-legacy" to clearly show that it's the unloved child) - and things looks like this is not going to change any time soon.

Linux policy routing is still incredibly painful if one wants to have more sophisticated routing than just "take source and destination IP address for the routing decision". The mechanisms that have been in use seven years ago still work though, and I didn't find any possibility to do it any easier. In this article, I'll try to explain the "old" mechanisms and hope that somebody from lazyweb will comment and say "it can be done so much easier".

This is a translation of the Usenet article <gu48cs$rul$1@news1.tnib.de> in de.comp.os.unix.networking.misc in the hope that the english-speaking blogosphere can give additional insights.

This is the third installment of my article about the Serial Console Server for the Poor. First installment here, Second installment here.

The first part of the article having covered the hardware and the udev part creating the device nodes, and the second part explaining how to solve the software part using ser2net, this part explains why ser2net was ditched in favor of cereal and how the console server operates with cereal now.

This is just a small reminder (for me and others) that Debian is currently migrating from console-tools to kbd (back again, yes, those who have been around for a few years remember).

This information is obviously a closely-guarded secret. Console-tools is still Priority: important, and kbd is still Priority: extra. However, kbd seems to be much better maintained (current uploads happening, while console-log has seen its last maintainer upload two years ago), and unfortunately, neither package description suggests which package is the way to go. And Debian-installer still installs console-tools by default.

However, a few bugs were filed a year ago by the console-tools maintainer to drop console-tools from depends as console-tools is going away. So I guess that he knows what he's doing...

Before I get around to adding console-tools back to console-log's depends (as I almost did accidentally), I'll better blog this to remind people of console-log going away. Maybe we'll get the Priorities changed just in time for lenny.

This is the second installment of my article about the Serial Console Server for the Poor. First installment here.

The last part of the article having covered the hardware and the udev part creating the device nodes, this part addresses the part of the software that connects the user to the device node.

The serial port is still the way to access network components out of band. It is slow, but reliable, and remarkably well standardized. It does not have technical whiz-bangs that can fail when one needs things to just work. That makes it the natural way to access critical infrastructure and still being sure that this access vector still works when most other things are down.

Every communication link has two sides, so there is a market for devices with a network link and a bigger number of serial ports to connect the actual devices to. Commercial vendors have a broad choice of serial console servers. Most of them, especially the small products with five to ten ports, are quite expensive, so I have been investigating how do build a serial console server with el cheapo hardware.

Today, I had the opportunity to try my UMTS initialization mechanism that I built this weekend with more recent hardware, a newer Option Globetrotter 3G Express Card with Vodafone branding (reporting itself to be a "Globetrotter HSDPA Modem" with Vendor ID 0xaf0 and Product ID 0x6701). To get the card connected to my test Notebook, a hp compaq nc8000, I had a "Expresscard in a PC card slot" adapter and a passive "Expresscard at a normal USB port" adapter. The USB adapter had cost about ten Euros, and I don't imagine the PC card adapter to be much more expensive.

For mobile UMTS/GSM, I have been using an Option 3G Data Card for two and a half years now. I blogged about getting the card to work (in German, sorry) on Linux in July 2005. I never found the time - until now - to automate the card initialization so that I had been using a horrible chat script for card initialization when the PPP connection was built.

I recently took the time to automate this, so that the PIN is transmitted to the card automatically when the card is plugged in. This article documents what I did.

On a side note: Unfortunately, the vendors' attitude towards Linux hasn't changed since 2005. Their Hotlines still deny that their products can be used with Linux at all, and they surely do not publish any documentation that can be of help. Otoh, Vodafone has published a software that supposedly aids usage of their products under Linux. I haven't tried it yet since it is not packaged yet for Debian. Additionally, Vodafone support media and sales do not seem to know about this effort, they still deny that their products work with Linux. Windows users happily install proprietary software products that do little more than sending a handful of AT commands to the emulated USB modem and hand over the connection to Windows' PPP Stack. A very unsatisfying situation.

Just for the record: Dear Vodafone DE, a week ago you missed the sale of a new USB UMTS interface because you don't even document it on Linux. This motivated me to look into the drawer that holds the old, non-HSDPA PC cards that have been decommissioned at the customers' site and use an old, used device. Your fault.

For various reasons, I have the kernel and the initrd that my notebook needs to boot Linux on an USB stick. I recently added the Debian Installer and grml to the stick to allow additional uses of the stick.

Last thursday and friday, I spent around eleven hours in the InterCity Express (ICE) of Deutsche Bahn. I was online, using Simyo GPRS, during this entire time. Thanks to the cellular network repeaters in ICE's coach 3 and 23, this has worked reasonably well and has cost me EUR 5,27 - in a tariff with no basic charge and no commitment.