Angesichts der Komplexität der vielen Funktionen mag es für die breite Masse durchaus Sinn machen, hier den vielfältigen Funktionen, die das von Pirelli Broadband Solutions stammende Gerät eigentlich mitbringt, einen Riegel vorzuschieben – schliesslich werden dann weniger versierte Anwender auch nicht dazu verleitet, etwas zu verkonfigurieren.
Wer allerdings etwas tiefergehende Konfigurationswünsche hat, wird es zu schätzen wissen, dass man über die Hintertür dennoch an die erweiteren Funktionen des Geräts rankommt.

Ich möchte an dieser Stelle noch darauf hinweisen, dass das nachfolgend beschriebene Vorgehen von Swisscom NICHT unterstützt wird, und dass man bei allfälligen Problemen auf sich alleine gestellt ist. Wer auf dem Centro Grande die versteckten Funktionen freischaltet, tut dies also auf eigene Verantwortung.

Bitte beachten: Die Anleitung gilt für die Pirelli-Router und nicht für die Motorola-Geräte!

Darum sollten die an dieser Stelle nur die Hartgesottenen weitermachen, die wissen was sie tun.

Wie kommt man nun also an diese “Magic Features” ran? Sehr simpel, einfach über die Befehlszeile eine Telnetverbindung auf die IP-Adresse des Centro Grande aufbauen:


telnet 192.168.2.1


Ach ja, wer Windows Vista/7 einsetzt, hat standardmässig kein Telnet mehr installiert. Dies kann über die Systemsteuerung nachinstalliert werden. Alternativ kann ich auch PuTTY empfehlen.

Nach erfolgten Login mit dem admin-Konto (das Passwort dazu kann man bei Bedarf im Swisscom Kundencenter abfragen), muss man folgenden Befehl eingeben:


conf set wbm/admin_wbm a25B06c81


Dies aktiviert die originale Pirelli Management Console, allerdigs erst nach einem Neustart, der mit folgendem Befehl ausgelöst wird:


system reboot


Und hier das ganze am Stück:

mbp:~ Gianpaolo$ telnet 192.168.2.1
Trying 192.168.2.1...
Connected to 192.168.2.1.
Escape character is '^]'.
Username: admin
Password: ***********
OpenRG> conf set wbm/admin_wbm a25B06c81

Returned 0
OpenRG> system reboot
Connection closed by foreign host.
mbp:~ Gianpaolo$

Nach dem Neustart verfügt der Router über zwei Web-Interfaces, einmal das Bekannte von Swisscom unter http://router-ip/ und ein zweites unter http://router-ip/admin.html.

Zugang erhält man mit dem bereits zuvor verwendeten admin-Konto. Gut, es sieht zwar nicht so hübsch aus, wie das Swisscom-eigene GUI, aber dafür kommt man an all die schönen Funktionen ran

Und was kann das Ding nun so alles?

Neben den USB-Ports, an die man beispielsweise USB-Festplatten oder -Drucker anschliessen kann, sind vor allem die VPN-Funktionen oder der Zugang zum lokalen DNS-Server häufig genutzte Power-Features. Ebenso kommt man an die erweiteren Einstellungen fürs WLAN heran, kann manuelles Routing oder Bridging konfigurieren. Auch lässt sich Remote Management konfigurieren und – auch bisweilen hilfreich – die DHCP Lease Time heraufsetzen.
Dazu kommt noch jede Menge weiterer Brimborium, aber das findet ihr am besten selber raus.

Kleiner Tipp am Rande: Von den TR069-Einstellungen unterhalb der Fernverwaltung sollte man tunlichst die Finger lassen – ebenso wie vom händischen Editieren der Konfigurationsdatei
Diese sind für das Remote Management und Upgrade durch Swisscom erforderlich. Im dümmsten aller Fälle könnte eine Fehlkonfiguration dazu führen, dass man kein neues Firmware-Upgrade bekommt, was einen unter Umständen plötzlich Offline und mit abgesägten Hosenbeinen dastehen lässt.

Viel Spass mit dem aufgebohrten Centro Grande


[11-07-12 22:21:22.9387] Slim::Utils::Firmware::downloadAsyncError (557) Warning: Firmware: Failed to download http://update.mysqueezebox.com/update/firmware/7.5.1/baby.version (Couldn't resolve IP address for: update.mysqueezebox.com), will try again in 10 minutes.


Looking for the obvious at the Squeezebox Community Forums I came around a hint to just download the firmware and copy it to the ‘Firmware’ folder manually.
Still, the server kept trying to download the firmware, even after restarting the service, completely ignoring the files I just dropped in there
(note: we’ll take about this again a bit later …)

Well, I’m not giving in that easy, so I tried another way: I created the proper directory structure in the ‘~/Downloads’ folder on my Mac:


$ cd ~/Downloads
$ mkdir -p update/firmware/7.5.1


Then I downloaded the firmware files (actually the files ‘baby.version’, ‘baby.version.sha’, ‘baby_7.5.1_r9218.bin’ and ‘baby_7.5.1_r9218.bin.sha’) in my local ‘~/Downloads/update/firmware/7.5.1′ folder.

Afterwars I started the built-in python web-server of OS X from the ‘~/Downloads’ folder:


$ cd ~/Downloads
$ sudo python -m SimpleHTTPServer 80
Password:
Serving HTTP on 0.0.0.0 port 80 ...


Since my Squeezebox Server runs from a QNAP NAS, I logged into it through SSH.
QNAP, as many other vendors, use Linux as operating system. As I don’t have a local DNS server in my network, my intention was to override the IP address of ‘update.mysqueezebox.com’ through a manual entry in the /etc/hosts file on the NAS server, so I added this new line to it:


192.168.100.54 update.mysqueezebox.com


A quick check using ‘ping’ reveals that it works properly.


[/] # ping update.mysqueezebox.com
PING update.mysqueezebox.com (192.168.100.54): 56 data bytes
64 bytes from 192.168.100.54: icmp_seq=0 ttl=64 time=1.0 ms
64 bytes from 192.168.100.54: icmp_seq=1 ttl=64 time=1.0 ms


Inspecting the logfile after restarting Squeezebox Server revealed however that this didn’t work as expected. It seemed like the application prefers DNS and ingores the local /etc/hosts on the NAS.
I checked in /etc/nsswitch.conf as well to see if we may have a different-than-default lookup order there:


$ grep -e hosts /etc/nsswitch.conf
#hosts: db files nisplus nis dns
hosts: files dns wins


Oh well, exactly what I expected to see. After all I didn’t want to dig into this too much (at least not more as I did already).
So I just searched the code to see where the Firmware download is being handled. I ended up with the file at /share/MD0_DATA/.qpkg/SqueezeBoxServer/var/home/SqueezeboxServer/Slim/Utils/Firmware.pm.

I located the line where the download URL is constructed on line 432:


my $url = BASE() . '/' . $::VERSION . '/' . basename($file);


So I changed it temporarily to read like this:


#my $url = BASE() . '/' . $::VERSION . '/' . basename($file);
my $url = 'http://192.168.100.54/update/firmware/' . $::VERSION . '/' . basename($file);


After restarting Squeezebox Server it finally downloaded the firmware from my Mac’s folder.

Checking back where the files had been actually stored, I saw that the new firmware ended up in ‘/share/MD0_DATA/.qpkg/SqueezeBoxServer/var/home/SqueezeboxServer/Cache/updates’ and not ‘/share/MD0_DATA/.qpkg/SqueezeBoxServer/var/home/SqueezeboxServer/Firmware’ as supposed.
Well, at least I tricked the whole thing into doing what I wanted and my Squeezebox Radio finally accepted to download the new firmware from the Squeezebox Server thereafter.

And yes, this whole trickery would have been obsolete if I had an internet connection. Of course, I could have enabled interconnection sharing on my Mac, which was hooked up to my iPhone. Now don’t ask me why, but somehow that was not working. After setting the network default gateway on the NAS to point to the Mac I’d still have no connection, so I suppose I either had one (or two) NAT sessions to much or some other thing on the Mac went terribly wrong. After all my approach worked out, that counts too

The most painful experience in this situation was that I suddenly sat there without working computer around. More dramatically was the fact that my TimeMachine backup was from the evening before, so I had some real nightmares about having partially lost my essay I was writing at that time.
Well, for a fast (and final) fix, I just got myself one of these fancy new MacBook Pro modells, so I could just go on with my work.

Albeit having a new computer, I just wondered about possible reasons for my MacBook failure. While digging around I found that there was well-known issue with 3rd generation MacBook pro with Nvidia graphics adapter, wich was even officially aknowledged by Apple. Actually, Apple even offered free repair of such defective MacBook Pro within four years of purchase (according to their support article).

Defective MacBooks affected by this issue are typically considered having a “blank screen” or distorted video. In case of “blank screen”, affected systems are still playing the “Mac chime” upon power-on and the CAPS-LOCK LED being lit when pressing the key. You could even boot the system and at least “hear” audible feedback to several keystrokes (e.g. the volume up/down keys, etc).

So that qualifies clearly for a MacBook Pro being affected by the Nvidia chip issue.

There’s the problem, however: You need to prove your purchase. If you don’t have an original receipt, Apple gently refuses to repair the broken MacBook Pro, as I was assured after talking to the helpline. Oh well … out of warranty, no proof of purchase … absolute failure! (BAD RANT at Apple for this!!!)

Oh, well, so no fix for me as I don’t have the prove of purchase. Baaah …

To fix the MacBook, I would have needed to exchange the LogicBoard. These do cost however several hundred Swiss Francs, definitely way beyond what’s worthwile to invest into a 4-year-old device.

During my research on the web I came along other sites covering this topic. Some of these sites did even propose fixing the LogicBoard by butting it into your oven and baking it for 5-10 mins at around 200°-220° (392 – 448 F). The idea behind this is simple: By exposing the board to heat in the oven, the reflow soldering assembling conditions are reproduced, which can eventually fix broken soldering points.

I found the best instructions on Philip May’s blog (in german language).
Instruction to disassemble the MacBook Pro were found on ifixit.com.

So tonight I took on the challenge to put my MacBook into the oven … ok, ok, just the plain LogicBoard
Below you’ll find some pictures of the process. And guess what? It really worked. My “broken” 3rd gen is now up and running again.
That leaves me only to this question: I’ve bought a new one already, what would I do with the old one now?

Ok, I must admit, that I took a glimpse at the tiny netbooks more than once. My dream was to actually run it with OS X instead of Windows or Linux.

So, just the next-day my netbook was OS X-ified (a topic, which I’ll cover later on), only to notice some more or less annoying issues.

One of the most annoying issues was the stock WiFi, which required a very ugly 3rd party tool for configuration and was so absoluty not OS X-alike.

Two weeks ago I finally ordered a DW1390 mini PCIe WiFi card. It arrived today, so I went for immediate installation to see if it seamlessly works with my eeePC (or should it be called eeeBook instead?).

Here’s some pictures about the “unboxing experience”, though it’s not served up Apple-style

It’s almost as tiny as a standard USB stick:

Ready to open up the back-cover:

Disconnecting both antenna wires …

This is the empty socket after having the original card removed:

And here’s the new card plugged-in:

After re-assembly I booted into OS X to configure the new WiFi the real OS X-style.

Finally, one of the most annoying things on the eeeBook is gone now

There are many cases however where such a behaviour is simply not desired, considering Windows RAS providing you with no way to circumvent this, you’re on your own for once more.

I wrote this script, ras_init.vbs, out of the requirement to restore my default route for normal connections and route only specific hosts and networks through PPP/PPTP.

ras_init.vbs is released under the terms of the GNU GPL, version 2. Any feedback is appreciated.

ras_init-0.2.zip

Change Log:

r0.3 2007/06/06

r0.2 2006/06/16

• add support for interactive/non-interactive mode

r0.1 2006/06/13

• initial release
• tested on Windows 2000/XP
• searches through all interfaces and looks for the expected RAS subnet address
• removes RAS default route and replace it by your local default route
• optionally set up host/network routes for routing through RAS