But for some reason, the installation reliably freezes at some (variable) point. The last time (I think on the 4th run), the final state shows a progress bar titled “Select and install software” at 1% (see screenshot).

Frozen lenny installation on virtualbox

However, I can still change into another virtual console inside the virtual machine and everything seems to work fine in there. I can create files on the target root partition, read files from the installer CD. Running ps in the machine, the only indicator that something is wrong is that all installer processes are in “stopped” state. On a fully installed machine, I would use tools like strace and gdb to find out what’s going on here, but they are not available inside the installer.

So I’ll go the easy way and create a Xen DomU to test my packages. If somebody has an explanation for this behaviour, I’m all ears…

Software versions used

virtualbox-ose                            3.0.10-dfsg-1
virtualbox-ose-guest-source               3.0.10-dfsg-1
debian-503-i386-netinst.iso

The problem

For a while we were using a DSL 2000 line, which is quite slow – especially for uploads. Unfortunately, that’s as fast as ADSL gets on our phone line. But I was told by a support guy at T-Com that VDSL would likely work with a much higher speed, so I ordered the try & buy package with VDSL 25.

Now I did not have the login data for reasons that are too long-winded to explain here. I tried to get new login data, but found out that the only way is to request it via fax and have the account deactivated until the access data arrives by snail mail. *sigh*

Fortunately, the documentation of my new VDSL router (the Speedport W721V) said that it would automagically configure itself when connected to a VDSL line so I had hope that we could immediately use our new, fast internet connection. OTOH I always need a plan B, after all I did not want to lose connectivity.

I knew that the old (W701V) router could use an external DSL modem, so I checked if the new router would talk PPPOE. Turns out that it does, so I felt that it would not be a problem to connect using the login configuration of the old router. Just degrading the newer, better, faster router to a modem should suffice.

You can infer from me writing this that it did not work out:

• Automatic configuration of login data failed consistently.
• Just connecting the W721V as a modem did not work either.

Solution

After configuring the W721V for PPPOE pass through and turning of NAT etc. to be sure, I connected the W721V to the WAN port of the W701V (which is the same as LAN1). Flipped the int./ext. mdoem switch of the W701V and booted both systems. No internet connection.. (PPPoe timeout says the log of the 701).

My first guess was that both ports did not have auto sense. With no cross link cable available, I connected both routers via an ethernet switch. Which did not work either, but now I could sniff the conversation of both boxes by using the wireshark packet sniffer.

As expected, the W701V was sending PADI requests, but for some reason the W721V would not answer.

At first I suspected that the W721 had a bug and would not work as a DSL modem (who would test that feature anyway?). Out of frustration, I tried running

pppoe-discovery -I eth1

on my Linux system (eth1 being connected to the W721), and to my surprise got a PADO reply.

Looking closer, I noticed that the PADI requests of the W701 had an additional VLAN header. I guessed that the W721 for some reason was not able to look through this additional encapsulation. Playing around with the configuration options did not help in any way.

My last ditch effort to recover connectivity was to save the configuration of the W701 and load the full configuration into the W721 router. Of course, the configuration files were incompatible. But: Out of curiosity I looked into the config file speedportw701v.export written from the W701. Searching for vlan revealed, that there is only a small part of that (text) file that could be of interest:

        vccs {
                ...
                dsl_encap = dslencap_pppoe;
                vlancfg {
                        vlanencap = vlanencap_class_prio;
                        vlanid = 7;
                        vlanprio = 0;
                }
                ...

Now, what would I need to set to turn that VLAN encap off? I looked into the W721 export file for clues and found

torsten@transit:~$ grep -i vlanencap speedportw721v.export
vlanencap = vlanencap_none;
...

With new hope, I tried changing this section above as in the following patch:

--- speedportw701v.export       2008-10-08 21:06:49.915024974 +0200
+++ speedportw701v_novlan.export        2008-10-08 22:51:37.642653617 +0200
@@ -154,8 +154,8 @@
                 priority = 0;
                 dsl_encap = dslencap_pppoe;
                 vlancfg {
-                        vlanencap = vlanencap_class_prio;
-                        vlanid = 7;
+                        vlanencap = vlanencap_none;
+                        vlanid = 0;
                         vlanprio = 0;
                 }
                 ipbridgeing = no;

But I was unable to load the changed configuration file back into the W701. After using google a few times (connected using my mobile phone, ouch!), I found FBEditor which finally allowed me to update the check sum at the end of the export file. Kudos to Oliver Metz!

With that configuration tweak, I finally got my connectivity back. Of course I will switch to a sane configuration once I get new login data. But it is possible to degrade the W721 to playing modem and have the W701 keep playing router job.

Other ways to modify the export file

After using FBEditor, I found more hints how the exported router configuration could be hacked:

• Using the perl script exportsum.pl by Enrik Berkhan.
• Disabling verification of the check sum, see this post. In short, you need to put NoChecks=yes into the header, after the line starting with Country=.

Links

• http://www.congenio.de/infos/vdsl.html
• Wikipedia article on IEEE 802.1Q, the standard for the VLAN tagging used by my W701V.