Bawue.Net

As most readers of this blog are probably aware, pre-releases of the Linux Kernel 2.6.27 are able to trash the NVRAM/EEPROM of certain Intel Network cards. As usual, lwn.net has a nice writeup of the issue including some background information.
I had a similar problem in the past and as a favour for some friends of mine, I've written down a small description to restoring the ethernet firmware in these cards. This guide should serve as a good primer on reflashing your broken nic but probably needs to be adapted for your own use case.

NB: Instead of just giving a command by command description of what I did, I'll try explaining a bit more about the background and the process of fixing the problem at hand. Maybe this gives other people some insight into valuable problem solving skills.

Some years back we bought quite some Tyan S5112 machines for bawue.net.
The idea was to fit these machines with the Tyan m3289 server management card, an IPMI card allowing remotely powercycling of the machines and offering a serial console via the network.

In order to have the whole setup work, the IPMI management module needs support from the network interface in order to receive IP packets while the machine is powered off. After contacting the Tyan support, we were offered a firmware file to flash into the network adapter activating the needed "management mode". This firmware file came in the form of a .bin file and an accompanying eeupdate.exe file for flashing the firmware image.

The mainboard has two ethernet controllers, with the 82547EI one being the controller utilized by the management card. The lspci output on this board looks as follows:

[root@selene ~]# lspci|grep Ethernet
01:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet Controller
03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller
[root@selene ~]#

The instructions for flashing the firmware were relatively simple: Boot with a DOS bootdisk and execute eeupdate -nic=1 -d 82547EI.eep
After I pressed enter, nothing much happened. The system wasn't reading anything from the disk, there was no progress message on the screen, just the general start-message of the firmware update tool.

When nothing happened after 5 minutes of waiting, I foolishly reset the system. Big mistake!.

On the next boot of the system, there were no PXE messages from the network card and during bootup the e1000 linux driver only threw out the ominous message The EEPROM Checksum Is Not Valid without loading the network interface.
It turns out, I just trashed the firmware of my on-board network interface.
Calling the eeupdate program again did not work as it bailed out because the eeprom was corrupted
At such times, I firmly believe in the use of swearwords accompanied by heavy googling for some advice. Alas, googling told me only that I broke my hardware and needed new one.

As returning hardware because of a problem is akin to giving up, which is generally unacceptable, I decided to look into the issue a bit more and find a workable solution to unbrick the network interface.
To recap, I had the following:

• One on-board network interface with a corrupted nvram
• One eeprom image for said network interface (For reference: 82547EI.EEP)
• No working flash program
• No working driver
• One working Linux system without network
• One working Linux notebook with network

Luckily, the working Linux system and network access is all I needed:

The first step was getting the sources of the e1000 driver from the project page. As this was a few years ago, I chose the version 7.3.15 which was current at this time.

After untaring the sources, a quick grep -R 'The EEPROM Checksum Is Not Valid' e1000-7.3.15 turned up one hit in e1000-7.3.15/src/e1000_main.c: [geshi lang=c] /* make sure the EEPROM is good */ if (e1000_validate_eeprom_checksum(&adapter->hw) < 0) { DPRINTK(PROBE, ERR, "The EEPROM Checksum Is Not Valid\n"); err = -EIO; goto err_eeprom; } [/geshi] So there is a function called e1000_validate_eeprom_checksum responsible for checking the validity of the eeprom. During the main initialization of the card this function is called and in case the checksum is not valid, the error handler err_eeprom is executed which aborts the module load.
On a hunch, I removed the whole check logic containted in this function located in e1000-7.3.15/src/e1000_hw.c. After I was done, the whole function body consisted only of a "return 0" statement meaning that the checksum check will always succeed.

Building the modified module by calling make in the src dir resulted in a e1000.ko file which could be loaded into the running kernel by executing "insmod ./e1000". (Note, this will probably not work with current kernels as the buildscripts have changed. Use a current version of the e1000 driver instead.)
To my great relief the driver returned the following message:

Intel(R) PRO/1000 Network Driver - version 7.3.15
Copyright (c) 1999-2006 Intel Corporation.
e1000: 0000:01:01.0: e1000_probe: (PCI:33MHz:32-bit) ff:ff:ff:ff:ff:ff
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:03:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:e0:81:55:f2:01
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection

So even though the mac address of the card is broken, at least the card is somewhat detected and I can work on restoring the eeprom.

For modifying low-level settings of network interfaces under Linux one can usually use the fabulous ethtool utility.
Using the -e parameter dumps the eeprom values of the specified network interface onto the screen. This is great for getting a backup of the eeprom:

[root@selene ~]# ethtool -e eth1 | head -n 5
Offset		Values
------		------
0x0000		00 e0 81 55 f2 01 10 02 ff ff 06 20 ff ff ff ff 
0x0010		ff ff ff ff 0b 64 76 10 86 80 76 10 86 80 84 b2 
0x0020		dd 20 22 22 00 00 90 2f 80 23 12 00 20 1e 12 00 
[root@selene ~]# 

Even better is the -E parameter as it allows changing a single byte at a specified address in the eeprom:

[root@selene ~]# ethtool -E eth0 magic 0x10198086 offset 0x0 value 0x00
[root@selene ~]# 

This command would change the byte at the address 0x0 (the first byte) into the value 0x00. The 0x10198086 value is the "magic" value needed to "unlock" this write operation. Depending on the driver and the card this value is different for each system. In the case of the intel e1000 driver, the magic value is the Device ID and Vendor ID of the selected network card. This value can be gathered by examining the lspci -n output.
As I was in a hurry back then to get the machine working again, I didn't try to find out what exactly the magic value was but just commented out this check in the e1000_ethtool.c file.
For reference, the patch of my modifications to the e1000 driver are e1000-repair.patchdownloadable as a unified diff.

Now, that I could change single values in the eeprom, it was time to take a look at the Tyan provided eeprom file:

[root@localhost root]# head -n 5 82547.eep 
E000 2A81 0855 0A10 FFFF FFFF FFFF FFFF 
FFFF FFFF 640B 1019 8086 1019 8086 B200 
1F35 002A 0E00 0012 0E00 20DD 7777 1F95 
0001 1F73 0098 1F72 3FB0 0009 1200 3649 
00CF 8FA7 290E 0305 0CCA FFFF FFFF FFFF 

Comparing this eeprom file with the dump taken earlier from the second network interface in the machine showed that the .eep file from intel was in "mixed-endian" format, meaning I had to shuffle the values around a bit before being able to rewrite the image. The file contains the eeprom values as groups of two bytes each in reversed order. The first four byte-values in the file are 0xe0 0x00 0x2a 0x81 while in the eeprom they would be 0x00 0xe0 0x81 0x2a.

After I found the correct byte ordering, I could simply call ethtool -E manually with the correct addresses and just write each byte into the eeprom or automate this and reduce the possibility of mistakes. Naturally, automation it is. Back then I chose to do this script in PHP as a small exercise in command-line-interface programming.
The PHP script can be downloaded as eepromer.php and executed by calling php eepromer.php on the shell.
In order to explain it's working, the code is printed below: [geshi lang=php][/geshi] At the start, the variable file contains the filename to read in. This file is then opened and read into memory as it is only 6K large. The PHP String Tokenizer function is used to extract the values from the script and the bytes in each extracted group are then swapped around to put them into big endian byte-order. When the eeprom file has been completely parsed the ethtool commands to write the gathered data into the eeprom are printed to STDOUT:

[root@localhost root]# php eepromer.php | head -n 5
ethtool -E eth0 magic 0x00 offset 0x0 value 0x00
ethtool -E eth0 magic 0x00 offset 0x1 value 0xE0
ethtool -E eth0 magic 0x00 offset 0x2 value 0x81
ethtool -E eth0 magic 0x00 offset 0x3 value 0x2A
ethtool -E eth0 magic 0x00 offset 0x4 value 0x55
[root@localhost root]# 

By piping the output of this quick-and-dirty script into a shell (php eepromer.php | sh), the content of the .eep file is written for real into the eeprom. The last step is changing the first 6 bytes of the eeprom (offset 0x0 to 0x5) to the original mac address of the network interface.
After this has been done, the network card is considered repaird or unbricked.

Now, this explanation should give anyone some hints on fixing his network card's eeprom should this be needed because of problems with the kernel releases mentioned in the beginning. It is unlikely that following the procedure above to the letter is going to have any usable results as every system and situation is different.
The major problem would be, that not everyone has a working .eep file from Intel available after his own card is trashed. My suggestion would be to look for a friend who has exactly the same card. This can be achieved by using lspci:

[root@selene ~]# lspci | grep Ethernet
01:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet Controller
03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller
[root@selene ~]# lspci -n | grep '01:01\.0'
01:01.0 0200: 8086:1019
[root@selene ~]# 

If a friend has the same network card as indicated by the Vendor and Device ID (8086 == Intel, 1019 == 82547EI Gigabit Ethernet Controller in my example) he should be able to take eeprom dump by calling ethtool -e [device] > /tmp/eeprom-[device].dump.:

[root@selene ~]# ethtool -e eth0 | head -n 8
Offset		Values
------		------
0x0000		00 e0 81 55 f2 00 10 0a ff ff ff ff ff ff ff ff 
0x0010		ff ff ff ff 0b 64 19 10 86 80 19 10 86 80 00 b2 
0x0020		35 1f 2a 00 00 0e 12 00 00 0e dd 20 77 77 95 1f 
0x0030		01 00 73 1f 98 00 72 1f b0 3f 09 00 00 12 49 36 
0x0040		cf 00 a7 8f 0e 29 05 03 c8 0c ff ff ff ff ff ff 
0x0050		ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 
[root@selene ~]# 

This dump file can then be written into your own nvram by an easier procedure then described above. After all, no endianness swapping is necessary as ethtool already returned the data correctly. A bit of reformatting of the import is necessary however but can be accomplished in a simple bash script: [geshi lang=bash]magic=0x0 j=0 for i in `sed -e '1,2d' /tmp/eeprom-[device].dump | cut -c 9- | tr -d "\n"` do echo ethtool -E magic $magic offset 0x$(printf %x ${j}) value 0x${i} j=$(($j + 1)) done [/geshi] This script, which can be written as one single line, will remove the header and other superfluous data from the dumpfile, leaving only the values itself which are then echoed to STDOUT in the form of an ethtool command.

[root@selene ~]# magic=0x0; j=0; for i in `sed -e '1,2d' /tmp/eeprom-[device].dump | cut -c 9- |
tr -d "\n"`; do echo ethtool -E magic $magic offset 0x$(printf %x ${j}) value 0x${i}; j=$(($j + 1)); done | head -n 5
ethtool -E magic 0x0 offset 0x0 value 0x00
ethtool -E magic 0x0 offset 0x1 value 0xe0
ethtool -E magic 0x0 offset 0x2 value 0x81
ethtool -E magic 0x0 offset 0x3 value 0x55
ethtool -E magic 0x0 offset 0x4 value 0xf2
[root@selene ~]#

Piping this into a shell will restore your eeprom meaning only the mac address has to be reverted to the old one. The correct working of the above bash line should be tested however, as the output of ethtool differs depending on the card and the driver.

Should the network interface not even be visible on the PCI bus anymore (possible due to the usage of the ibautil.exe tool mentioned on some webpages) reflashing the main bios might work for some systems. The flashrom utility from the coreboot project might come in handy for this.
Otherwise it might be necessary to rewrite the necessary part of the eeprom first through the SPI, a serial programming interface, in order to have it enumerate again on the pci bus.
Should this be the case, it might be easier to just return your mainboard for repair though.
Should you be willing however, to try your luck and certainly void any little bit of warranty you had left, Intel offers a nice manual explaining the firmware format of it's ICH8 system.

Die Tatsache, dass Mailinglisten inzwischen nicht mehr das Mittel der Wahl zur Kommunikation sind, hat sich mittlerweile auch bei Internet Provider meiner Wahl herumgesprochen.

Die hohe Anzahl von unerwünschten Werbemails verleitet nicht nur mich dazu, einerseits extrem rigeros zu filtern, andererseits dennoch nur noch höchst widerwärtig in meinen E-Mail Client zu schauen.

Was liegt also näher, zur Kommunikation mit den Vereinsmitgliedern - aber auch mit den normalen Benutzern - ein Blog zu verwenden?

Die Wahl fiel auf Serendipity da es sowohl bereits bekannt ist, als auch einen Mehrbenutzermodus anbietet, bei dem verschiedene Personen Einträge bloggen können.

Zu finden ist das ganze unter http://blog.bawue.net. Ein paar Inhalte habe ich auch schon hinzugefügt, warten wir mal ab, ob das Konzept denn auch angenommen wird.

Als Bonus der ganzen Aktion habe ich mittlerweile herausbekommen, wie man ein Serendipity Template schreibt und habe auch wieder Einblick in den Code mancher Plugins gewonnen... Eine lohnenswerte Aktion also...

We've gotten a new document scanner for bawue.net in order to better handle our documents and our snail-mail communication.
The Canon ScanFront 220P is a network scanner which does (among other things) optical character recognition and is able to send the resulting document as a PDF via e-Mail or upload it to a FTP Server or a SMB Network share.

The device itself is running Windows CE in order to accomplish all that which is fine as it therefore needs no computer connected to it as some other scanners do.

A real problem for the Linux user howerver is that Canon seems to have handed the development of the scanner's web interface to some clueless and moronic developers.
There's simply no excuse for designing a web interface which only works with Internet Explorer and doesn't even allow a Firefox user to log into the interface.
I'd expect MUCH better from a global company such as Canon, especially when the scanner in question costs about US$ 2,150.00

If the device would have been running Linux and the sources would have been delivered as requested by the GPL I'd have a working scanner here and Canon's development team would have had a nice unified diff in the mail fixing their problems. That way, all they are getting is an acrid mail.
Another reason to favour open source operating systems for any development work. Some companies seem to clearly get this.

In the meantime tough I need a working scanner. Greasemonkey to the rescue: I've written a small GPL3 licensed Greasemonkey User script fixing the problems in the ScanFront webinterface. Naturally, one has to have greasemonkey installed to use this script.

It currently fixes the login prompt, makes the "New User" button work, fixes an onload-recursion in the address book and makes the job-control window work when selecting the destination address for a scanjob.
Most of these problems stem from the fact that the Internet Explorer XML parser seems to be somewhat sloppy and does not make a difference by getElementById and getElementsByName.
My userscript works around these issues but a real fix can only be delivered by Canon.

I tried the free as in beer vmware-server on our new quad opteron and probably got exactly what I deserved when using tainted modules. :-)

general protection fault: e040 [1] SMP
<Jan/04 01:48 am>last sysfs file: /class/scsi_host/host0/stats
<Jan/04 01:48 am>CPU 0
<Jan/04 01:48 am>Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler vmnet(U) vmmon(U) ipv6 
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables
x_tables video sbs i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport st sg e100
serio_raw pcspkr ide_cd k8_edac mii cdrom edac_mc floppy tg3 shpchp dm_snapshot dm_zero dm_mirror
dm_mod sym53c8xx scsi_transport_spi 3w_9xxx sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
<Jan/04 01:48 am>Pid: 2317, comm: vmware-vmx Tainted: P      2.6.18-1.2747.el5xen #1
<Jan/04 01:48 am>RIP: e030:[<ffffffff88395db1>]  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am>RSP: e02b:ffff8801e79c7bb8  EFLAGS: 00010282
<Jan/04 01:48 am>RAX: ffff820000000000 RBX: ffffc2000003d000 RCX: 000000000000e040
<Jan/04 01:48 am>RDX: ffff82000000e040 RSI: 0000000000000000 RDI: ffff8801e9bf6000
<Jan/04 01:48 am>RBP: 00002aaaada80a80 R08: 7fffffff00000001 R09: 0000000000000000
<Jan/04 01:48 am>R10: ffff8801e79c7e98 R11: 0000000000000048 R12: ffffffff8058e000
<Jan/04 01:48 am>R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000660
<Jan/04 01:48 am>FS:  00002aaaada80a80(0000) GS:ffffffff8058e000(0063) knlGS:0000000000000000
<Jan/04 01:48 am>CS:  e033 DS: 002b ES: 002b
<Jan/04 01:48 am>Process vmware-vmx (pid: 2317, threadinfo ffff8801e79c6000, task ffff8801ee6fd040)
<Jan/04 01:48 am>Stack:  736282f99c4145dc  000000009d53f5e8  ffff8801e9bf6000  0000000000000246
<Jan/04 01:48 am> 000000008005003b  00002aaaabb65290  00000000b41c1cc3  0000006300005eaf
<Jan/04 01:48 am> 820000000000efff  ef980ea576c5ffff
<Jan/04 01:48 am>Call Trace:
<Jan/04 01:48 am> [<ffffffff883994eb>] :vmmon:Vmx86_RunVM_S1B1+0x3f/0x1a8
<Jan/04 01:48 am> [<ffffffff8838c21e>] :vmmon:__LinuxDriver_Ioctl+0x387/0xd35
<Jan/04 01:48 am> [<ffffffff8027f6f0>] __wake_up_common+0x3e/0x68
<Jan/04 01:48 am> [<ffffffff8022e141>] __wake_up+0x38/0x4f
<Jan/04 01:48 am> [<ffffffff80260729>] _spin_lock_irqsave+0x9/0x14
<Jan/04 01:48 am> [<ffffffff802976dd>] futex_wake+0xc6/0xd5
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8838daf7>] :vmmon:LinuxDriver_Ioctl+0x529/0x583
<Jan/04 01:48 am> [<ffffffff8030512d>] inode_has_perm+0x56/0x63
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8026a78d>] monotonic_clock+0x35/0x7b
<Jan/04 01:48 am> [<ffffffff803051ce>] file_has_perm+0x94/0xa3
<Jan/04 01:48 am> [<ffffffff8838db74>] :vmmon:LinuxDriver_CompatIoctl+0x23/0x36
<Jan/04 01:48 am> [<ffffffff802d7230>] compat_sys_ioctl+0xc5/0x2b1
<Jan/04 01:48 am> [<ffffffff8025d54d>] ia32_sysret+0x0/0xa
<Jan/04 01:48 am> [<ffffffff8025d4e2>] ia32_syscall+0x1e/0x6b


<Jan/04 01:48 am>Code: 0f b6 42 05 83 e0 0f 83 f8 0b 75 0c 8a 42 05 83 e0 f0 83 c8
<Jan/04 01:48 am>RIP  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am> RSP <ffff8801e79c7bb8>
<Jan/04 01:48 am> <0>Kernel panic - not syncing: Fatal exception
<Jan/04 01:48 am> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.

I fear I'll have to look into xen a bit more and use that in the meantime.

UPDATE: Turns out, it's currently impossible to do what I want:

• Xen and VMware are impossible to run at the same time
• Running ia32 guest inside of a x86_64 Xen instance does not work. It seems to be a planned feature though.
• qemu is slow and the binary kernel accelerator does not work on x86_64

I guess I'll just have to disable Xen for now and go with vmware until I have new hardware for the soon to be virtualized host. :(

Für die Elmeg ICT-Serie von Telefonanlagen gibt es ein sogenanntes VoIP-VPN Gateway, dass der Telefonanlage SIP Fähigkeiten beibringt.

Die interessanten Features des Moduls sind:

• Nutzung von maximal 10 SIP Providern als "Amtsleitung"
• Anschluss von SIP-fähigen Telefonen als interne Nebenstelle
• IPSec VPN Verbindungen
  • Voice-over-VPN möglich um externe Telefone als interne Nebenstelle zu nutzen
  • Zusammenschaltung von mehreren dieser Telefonanlagen über VPN Verbindungen um z.B. Niederlassungen günstig an das Hauptbüro anzuschliessen.
• Router Funktion
  • Mini Switch mit 3 internen Ports und einem WAN Anschluss.
  • Internetzugang über PPPoE, ISDN und PPtP, DHCP etc. möglich
  • Interner DHCP Server
  • Stateful Inspection Firewall oder Packet Filter
  • IP-Masquerading/NAT
  • RAS-Server und -Callback
  • Netzwerkweite LAN-CAPI Funktionalität

Diese Features können realisiert werden, da das VoIP-VPN Gateway ein modifizierter Bintec Router ist.

Das schöne daran ist, dass die Telefonanlage deswegen einen Telnet-Daemon laufen hat und man sich dort mit dem Login "admin" und dem Passwort "fec" einloggen kann und somit das Gerät wesentlich umfangreicher konfigurieren kann als über die vorgesehenen Windows Administrations Tools der Telefonanlage. z.B. für ordentliche IPSec Konfiguration ist das notwendig, oder wenn man Portforwardings aktivieren will.
Das unschöne ist, dass man die Konfiguration über Telnet so sehr vermurksen kann, dass das Gerät nicht mehr viel macht und sich direkt aufhängt.
Bei mir ging zwar noch der Login per telnet, aber sollte man dann versuchen "setup" oder einen anderen Befehl an der Shell einzugeben, so war erstmal Schluss.

Der Funkwerk Support kennt in dem Fall die einfache Lösung, wie man das Problem beseitigen kann: Einschicken, wir reparieren das dann.

Danke, aber das war die falsche Antwort.

Aber es gibt ja genügend Stecker auf dem Board, einer wird schon helfen.

[Note to english speaking readers, aggregating this blog: The following article is written in german about gaining root on a piece of embedded server monitor hardware from Rittal and configuring ssh access. If there is demand, I'll translate this article in english as well.]

Ich hatte zuvor ja schon hier und hier ein wenig über das Rittal CMC-TC System gesprochen, dass wir verwenden um unseren Serverschrank zu überwachen.

Das System selber ist soweit ja sehr schön, und hat auch ein paar nette Features, aber leider fehlt z.B. der ssh Zugang. Telnet anzubieten ist doch schon ein wenig schwach heutzutage. Das ganze wäre ja kein Problem, würde Rittal sich an die GPL Lizenz halten, und mir den Sourcecode und die Buildumgebung zur Verfügung stellen, die gebraucht wird um sich einen eigenen sshd zu installieren.
Nunja, mal schauen was das noch wird.

Nun will ich aber dennoch einen ssh Daemon auf dem Gerät haben, was sich auch nicht als sonderlich kompliziert rausstellt. Man muss das Gerät nur booten und den vorhandenen sshd starten.

Aber fangen wir vorne an.

Schauen wir uns also mal die Bootmeldungen an:

U-Boot 1.1.3 (Jun  8 2005 - 15:08:40)

U-Boot code: 20F00000 -> 20F1A868  BSS: -> 20F1EE48
RAM Configuration:
Bank #0: 20000000 16 MB
Board: CMC-PU2 (Rittal GmbH)
Flash:  8 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
no DHCP
## Booting image at 10030000 ...
   Image Name:   ARM Linux-2.4.27
   Created:      2005-04-22   4:52:03 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    698499 Bytes = 682.1 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.4.27-vrs1 (mkr@s020403) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #2
     Fri Apr 22 06:49:12 CEST 2005
CPU: Arm920Tid(wb) revision 0
Machine: ATMEL AT91RM9200
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock3 ro ethaddr=00:d0:93:12:34:56 ip=192.168.0.190::::
     CMC-TC-PU2::off console=ttyS0,9600
mtdparts=cmc_pu2:128k(uboot)ro,64k(environment),768k(linux),4096k(root),-
Calibrating delay loop... 89.70 BogoMIPS
Memory: 16MB = 16MB total
Memory: 14452KB available (1382K code, 275K data, 60K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
CPU: Testing write buffer: pass
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 5 MTD partitions on "CMC PU2 flash":
0x00000000-0x00020000 : "uboot"
0x00020000-0x00030000 : "environment"
0x00030000-0x000f0000 : "linux"
0x000f0000-0x004f0000 : "root"
0x004f0000-0x00800000 : "Partition_004"
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
ttyS0 at MMIO 0xfefc0000 (irq = 6) is a AT91_SERIAL
ttyS1 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL
ttyS2 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL
ttyS3 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL
ttyS4 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL
eth0: Link now 100-FullDuplex
eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:d0:93:12:34:56)
eth0: Davicom 9196 PHY (Copper)
AT91 Watchdog Timer enabled (5 seconds)
Found AT91 i2c
I2C: RS5C372 RTC driver successfully loaded
CMC buzzer driver $Revision: 0.2 $
CMC digital IO driver $Revision: 0.2 $
Serial driver version 0.03 (2004-12-17) with no serial options enabled
ttyS5 at 0xc2084000 (irq = 29) is a TI16752
ttyS6 at 0xc2086000 (irq = 30) is a TI16752
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0: Link now 100-FullDuplex
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.0.190, mask=255.255.255.0, gw=255.255.255.255,
     host=CMC-TC-PU2, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 60K
serial console detected.  Disabling virtual terminals.
init started:  BusyBox v0.60.2 (2002.10.10-17:17+0000) multi-call binary
eth0: ROVR error
eth0: ROVR error
Startup CMC
no update..
CMC Applications
rs422, Version: V2.00, Build Date: Mon Sep 19 18:01:58 2005
eeprom, Version: V2.00, Build Date: Mon Sep 19 18:00:03 2005

rs232, Version: V2.00, Build Date: Mon Sep 19 18:39:00 2005

CMC-TC-PU2 Thu Jan 1  1970 00:00:15, User 0
CMC-TC-PU2 login: VCC status = OK
cmc_main, Version: V2.15, Build Date: Wed Nov 16 15:20:38 2005
No Options..

Setting up clock 18:03:30 15.06.2006

CMC-TC-PU2 Thu Jun 15  2006 18:03:35, User 0
CMC-TC 192.168.0.190 login:

Eindeutig. Ein Linux mit einer BusyBox Shell. Eine im Embedded-Bereich sehr verbreitete Kombination. In diesem Fall leider ein Lizenzverstoss.

Jetzt stellt sich die Frage, wie man root wird. Als Login hat man naemlich nur cmc und admin zur Verfügung, die beide normale Useraccounts sind und anstelle einer Shell ein fertiges Menü starten.

Im Nachhinein, nachdem man sich auf dem Gerät umgeschaut hat, fallen mir verschiedene Möglichkeiten ein, aber die einfachste ist dem Bootloader zu sagen, dass ich gerne eine Shell hätte.
Mehr Details gibt es im Rest des Artikels.

In Ein Heim für Server hatte ich ja bereits auf die Türsteuerung per SNMP verwiesen.

Hier ist mal ein kleiner Hack, wie sich sowas in PHP realisieren lässt.

Manche von Euch, die mich im RL kennen, werden es schon wissen: Bawue.Net, der beste Internetprovider von Welt, hat sich vor kurzem ein neues Rack geordert.
Da das nicht alle Tage vorkommt, lässt man sich natürlich nicht lumpen, und nimmt gleich mal mit eines mit der besseren Ausstattung.

Das hier rechts ist es. Ein Rittal TS8 Modell in den Traummassen 80cm Breite, 100cm Tiefe und 2200cm Höhe. Damit passt selbst unsere StorageTek DLT-Library hinein, die ja ein wenig länger ist und unsere beiden Cyclades PM 20i an der Seite.

Das besonders schicke an dem Schrank ist die Schranküberwachung von Rittal:
Das Gerät ganz oben im Schrank sind drei CMC-TC Einheiten, die mehrere Temperatursensoren und einen Rauchmelder überwachung und gleichzeitig auch die Schranktüren und Seitenteile überwachen.
Werden die Türen geöffnet oder die Sensoren bemerken eine zu hohe Temperatur oder sollte der Rauchmelder anschlagen (bitte nicht), so kann je nach Konfiguration Alarm ausgelöst werden, alle Verbraucher abgeschaltet werden oder eine optionale Racklöschung angeschaltet werden. Die Racklöschung in 3HE wollten wir dann aber doch nicht mehr haben, schliesslich ist sie bei den Gittertüren verlorene Liebesmühe.

Besonders praktisch an dem CMC-TC System ist, dass man über ein WebInterface oder SNMP Befehle die Türen entriegeln kann, und dann ohne Schlüssel an den Schrank herankommt.
Der Befehl dafür lautet wie folgt: "snmpset -v 1 -c $community $ip unit1OutputSet.2 i 3" zum Öffnen der vorderen Tür und entsprechend "snmpset -v 1 -c $community $ip unit1OutputSet.5 i 3" zum Öffnen der hinteren Tür.

Beim seriellen Zugriff auf das Gerät begrüsst einen netterweise ein Linux mit BusyBox. Ich habe gleich mal bei Rittal angefragt, woher ich denn die Sourcen bekomme, weil mir telnet ein wenig unangenehm ist für den Netzwerkzugriff. SSH mit dropbear wäre schon angebracht.

Mal abwarten wie die Reaktion ist. Dementsprechend kann ich immer noch auf GPL etc. verweisen.

Heute war ich einkaufen. Und zwar 8 Stühle und einen Konferenztisch (Fotos gibt es dann wenn die Teile geliefert sind) für das Bawue.Net Büro.

Erschreckend fand ich, dass von den ungefähr 80 verschiedenen Stuhmodellen, die für einen Konferenztisch geeignet sind (also keine Rollen, kein "Chefsessel", kein Fuß in Sternform, nicht drehbar etc.) nur *ein einziges* Modell annehmbar war.

Das fängt an bei der wohl aktuellen Unsitte Stühle mit einer halbhoen Lehne zu fertigen und endet bei garantierten Rückenschmerzen.

Update: Jetzt mit Foto

If one is testing the sql backend functionality of openldap in connection with a MySQL Database, it is likely that slapd will not start. The following error can be observed when starting slapd with debugging enabled by using the -d 1 parameter:

backsql_load_schema_map(): error executing at_query:
Return code: -1
   Native error code: 1054
   SQL engine state:  S0022
   Message:           [unixODBC][TCX][MyODBC]
                      Unknown column 'sel_expr_u' in 'field list'
==>backsql_free_db_conn()
backsql_free_db_conn(): closing db connection

This error appears as the MySQL Templates shipped with openldap 2.2 are broken and have been so for quite some time. :-(

The short workaround ist adding the sel_expr_u row to your ldap_attr_mappings table as follows:
[geshi lang=sql] ALTER TABLE `ldap_attr_mappings` ADD `sel_expr_u` VARCHAR( 255 ) AFTER `sel_expr` ; [/geshi]

However, there are more problems...