ixs' Vodkamelone - Hardware

Avocent PM webinterface issues

andreas@dicp.de (andreas) — Sat, 7 Sep 2019 19:27:00 +0200

At bawue.net we are using several Avocent PM 3000 power distribution units to connect our servers.
A nice feature of these PDUs is that they work great with our existing Cyclades console servers.

In addition to the serial console and the SSH interface, these devices also offer a web interface. This interface never worked with Chrome or Chromium where it only shows a blank page. It does however work with Firefox, or so I thought at least.
I recently needed to verify something and found out that with the latest Firefox the webinterface on these devices is now not broken. Empty page, same as with Chrome.

As there is no firmware upgrade, I tried figuring out what is going on.

It turns out, the web interface was written using the JavaScript document.load() function to fetch content from the device. Unfortunately, this function was never standardized, never supported on Chrome or Safari and has by now been removed from Firefox as well.
Bummer!

But thanks to Greasemonkey or Tampermonkey it is possible to make the web interface work again. We just need to provide a document.load() function that uses AJAX/XHR Requests to load data from the device and all is good.

Such a userscript can be found on my public github gist.

The missing man page: cyc_ipmicmd - Avocent IPMI power control

andreas@dicp.de (andreas) — Thu, 30 Apr 2015 11:10:38 +0200

Avocent (formerly Cyclades) is a supplier for various datacenter management tools. They are best known for their rackmounted power distribution units and their serial console servers. Both devices run Linux and have been around for years.

Both the now EOL'd devices from Cyclades as well as the newer devices from Avocent can powercycle devices either through a serially attached smart PDU or through IPMI. Every device under the Advanced Console Server (ACS) label can control IPMI devices with a recent firmware.

While the functionality of the attached PDUs is quite well documented, there's no matching documentation for the IPMI interface. The web-interface works but the logic is mostly inside the AcsWeb webserver binary.
There's a cyc_ipmicmd binary but that one doesn't offer any --help functionality to explain how to call it.

For future reference here's the missing man page:

cyc_ipmicmd(1)                    General Commands Manual                    cyc_ipmicmd(1)

NAME
       cyc_ipmicmd - utility for power cycling servers via IPMI

SYNOPSIS
       cyc_ipmicmd SERVER COMMAND

DESCRIPTION
       The cyc_ipmicmd utility is a wrapper around /bin/ipmitool which allows to send IPMI
       power commands such as On, Off, Status and Cycle to configured devices.

       The server address as well as necessary authentication data is taken from
       /etc/IPMIServer.conf.

CONFIG FILE FORMAT
       The /etc/IPMIServer.conf file contains the necessary data to successfully send IPMI
       commands to remote devices.

       Each line contains one remote server definition with the following colon separated
       fields:

        - Numerical server ID (starting at 1)
        - IP address
        - Authentication Type (none, password, md2, md5)
        - Access Level (user, operator, admin)
        - Username
        - Password
        - Alias (human readable name)

       An example line might look as follows:
              1:192.168.0.1:password:operator:user:pass:Example Server:

SERVER parameter
       The server parameter is the numerical server ID taken from the first field of the
       configuration file.

COMMAND parameter
       The command parameter is numerical code which specifies which command is being
       sent to the remote IPMI device.

       0       Off
              Poweroff the server
       1      On
              Poweron the server
       2      Status
              Reportpower status
       3      Cycle
              Powercycle the server

EXAMPLES:
       Powercycle the first server:
              cyc_ipmicmd 1 3

AUTHOR:
       Andreas Thienemann

dss_cli, an Open-E Data Storage Server command line interpreter

andreas@dicp.de (andreas) — Thu, 16 May 2013 22:15:18 +0200

Introduction

dss_cli is a small command line program written in Python which can serve as the base for automating tasks on the Open-E Data Storage Server. A sysadmin can use it to control regular maintainance from the shell instead of having to log into the web-interface through a browser.
It can access the existing API via SSH and provides missing functionality by interfacing with the web-server on the DSS appliance. It is using both mechanize and Beautiful Soup to make it resiliant to changes in the webinterface. While it was originally written on a DSS v6, initial tests showed that it mostly works on the DSS v7 release as well.

Background

The "Data Storage Server" from Open-E is a linux based software appliance. After installing the software on a server, the server can then offer NAS and iSCSI storage to attached clients and is manageable through a web-interface.

One interesting feature of the appliance is, that it does offer failover for both iSCSI exported block devices as well as for NFS shared folders, something which makes it very interesting for Bawue.Net. The active/passive failover pair should give us better availability for maintenance as one half of the failover pair can be taken down for maintenance without affecting the virtual machines using the filer as a storage.

During testing of the DSS v6 system we did notice however a certain lack of functionality: The webinterface is great to manage the servers, create volumes, export these and set them up for replication. But using the webinterface is a manual process full of repetitive steps while the tasks at hand call for automation to reduce operator errors and to allow configuration through tools like puppet.

In order to help with automation, the DSS appliance offers an API/CLI access via ssh: Generate a key, connect to the server via ssh and pass some commands:

$ ssh -p 22223 -i filer1.key -l api 192.168.2.220 get_driveslist -v
Unit       Size(GB)   Serial Number  Status
S001       1862.64    4096e40371761527 vg,arc_vol_000
S002       279.40     4096e41532029185 vg,arc_vol_001

Unfortunately, the API is incomplete: It does allow for a lot of automation tasks, it does not export all the functionality to create working failover volumes and destroy them again. If there are plans to use the DSS filer as a storage backend for any kind of automated creation of virtualized servers these functions are sorely needed to prevent the need for manual interaction.

In order to address this lack of functionality, I wrote dss_cli, a command line client aimed at owners and administrators of DSS appliances in order to support all daily administration tasks needed on these filers.

Future plans

Provide a second tool to combine common steps for creation of iSCSI and NAS targets in a cluster.
Otherwise I am also taking nominations for needed functionality.

Installation

The current code is available on GitHub::ixs/dss_cli and is published under the GPLv2. Preqrequisites to running the dss_cli command is a recent Python installation with the Paramiko module for SSH connectivity and mechanize and Beautiful Soup for the web-scraping functionality.

Installation is simple: Download the latest code, unzip it in a new directory and edit config.ini to reflect your environment.
The [failovergroup] section contains your failover pairs, one group per line.
The example below defines one failovergroup called main, containing the dss1 and the dss2 filer.
The [dss1] and [dss2] section define their address, their admin passwords, the ssh_key needed for the API functionality and whether they are the primary or the secondary host in the failover group.

[failovergroups]
main = dss1 dss2

[dss1]
address = 192.168.220.1
password = admin
sshkey = dss1_api.key
mode = primary

[dss2]
address = 192.168.220.2
password = admin
sshkey = dss2_api.key
mode = secondary

Usage

./dss_cli --help
Usage: dss_cli [options]  

Command Line Interface to interact with an Open-E DSS Storage Server

Options:
  -h, --help            show this help message and exit
  -f FILE, --file=FILE  Configuration file to use
  -l, --list            List all commands available
  -g, --failovergroup   List all configured failover groups
  -d, --debug

Use --list to get a list of all supported commands. Each command should
support the --help parameter to get a list of accepted arguments.

Running ./dss-cli -l dss1 does give a list of all commands supported on that device:

$ ./dss_cli -l filer1
build - Lists and sets default build.
check_mk_agent - Returns information from check_mk monitor
create_iscsilv - Creates a logical iSCSI Volume.
create_naslv - Creates a logical NAS volume.
date - Sets time and date; please use the following format: yyyy-mm-dd hh:mm:ss
failover - This function allows you to stop, run or change the operation mode for the given server.
failover_task - Manage a failover task
get_TXbytes - Returns total number of bytes transmitted for the given interface.
get_TXpackets - Returns total number of packets transmitted for the given interface.
get_driveslist - Fetches a list of drives.
get_hwstatus - Returns information from system hardware monitor.
get_memorystatus - Fetches memory status.
get_nichealth - Fetches the status of the given Network Interface Card.
get_nicslist - Lists Network Interface Cards.
get_raidstatus - Returns information about RAID.
help - Lists all available methods
iscsi_target_access - Configure Target IP access
iscsi_target_assign - Assign lv with given name to existing iSCSI target.
iscsi_target_create - Creates a new iSCSI target.
iscsi_target_list - Lists iSCSI targets (syntax: alias;name).
iscsi_target_remove - Remove an existing iSCSI target
iscsi_target_restart - Restart iSCSI target service.
iscsi_target_sessions - Shows and manages iSCSI target sessions.
iscsi_target_status - Lists the parameters of the selected target.
iscsi_target_unassign - Unassign from given iSCSI target lvname.
lv_remove - Remove a logical volume
nas_settings_http - Enables and disables access to shares via HTTP.
nas_share_access_afp - Modifies AFP share access.
nas_share_access_ftp - Enables and disables access to shares via FTP
nas_share_access_http - Enables and disables access to shares via HTTP.
nas_share_access_nfs - Enables and disables access to the given share via NFS.
nas_share_access_smb - Modifies SMB/AFP share access.
nas_share_create - Create share on specified volume.
nas_share_details - Display detailed configuration of share
nas_share_edit - Changes share location or comment.
nas_share_groups - Groups manipulation functions.
nas_share_list - Lists shares
nas_share_remove - Removes the given share.
nas_share_toggle_smb - Enable or disable SMB support for a share
nas_share_users - Users manipulation functions.
nas_user_add - Create user in the system.
nas_user_groups - Adding and removing users to groups.
nas_user_remove - Removes the given user from the system.
nas_user_rename - Rename NAS user.
ntp - Fetches the time and date from an NTP server.
reboot - Reboots the system.
set_nic - Configures Network Interface Cards.
set_powersettings - Sets the power button action scheme.
shutdown - Shuts the system down.
snapshot_task - Starts and stops snapshots.
task - This function allows you to start task.
test - Generates an example of a help message.
unit_manager - Creates new volume group or adds unit(s) to existing volume group.
update - Initiates and checks the status of software update.
version - Fetches the software version.
volume_group_status - Lists Volume Groups.
volume_iscsi_remove - Removes a logical iSCSI volume
volume_replication - Adds and removes replication to volume.
volume_replication_mode - Set volume replication mode to source or destination
volume_replication_remove - Removes replication from Volume
volume_replication_task_create - Create a volume replication task
volume_replication_task_remove - Remove a replication task
volume_replication_task_status - Status of a replication task
volume_replication_task_stop - Stop a replication task
volume_status - Displays storage info.

Example

The following commands would serve to create a failover iSCSI volume on dss1 and dss2:

Create the logical volumes on both filers as part of the arc_vol_000 volume group. Command line arguments are create_iscsilv <vg_name> <size> blockio
The size argument is specified in 32MB blocks. 150GB * 1024 / 32 = 4800.

$ ./dss_cli filer1 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000
$ ./dss_cli filer2 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000

Enable volume replication for both logical volumes on both filers and set the logical volume on filer2 to be a secondary volume/replication destination.

$ ./dss_cli filer1 volume_replication add lvarc_vol_00000
$ ./dss_cli filer2 volume_replication add lvarc_vol_00000
$ ./dss_cli filer2 volume_replication_mode lvarc_vol_00000 secondary

Create, start and monitor the replication task on the primary filer and give it 80MBps bandwidth for initial synchronisation.

$ ./dss_cli filer1 volume_replication_task_create lvarc_vol_00000 lvarc_vol_00000 failover_iscsi_target0 80
$ ./dss_cli filer1 task --start VREP failover_iscsi_target0
$ ./dss_cli filer1 volume_replication_task_status failover_iscsi_target0

Create the iSCSI targets on both systems.

$ ./dss_cli filer1 iscsi_target_create target0
$ ./dss_cli filer2 iscsi_target_create target0

Assign the created volume to the just created iSCSI target on both systems. The server will report back with a randomly generated SCSI id for the LUN. Make sure to pass this one when assigning the volume on the secondary system. These ids need to be the same.

$ ./dss_cli filer1 iscsi_target_assign target0 lvarc_vol_00000
lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5
$ ./dss_cli filer2 iscsi_target_assign target0 lvarc_vol_00000 -s Dgp5VLni08UGb5W5
lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5

Add the replication task to the list of active failover tasks and make sure that failover services are started.

$ ./dss_cli filer1 failover_task failover_iscsi_target0 enable
$ ./dss_cli filer1 failover --start

Contact

Find me as "ixs" on the usual IRC networks. (IRCnet, EFnet, oftc, freenode)

How to recover an ASUS WL-330N3G mobile access point

andreas@dicp.de (andreas) — Thu, 23 Feb 2012 23:06:42 +0100

As I am travelling quite a bit I am often in the situation that I have a hotel room with a network cable and Internet access, but I have a notebook and a smart phone with me and the only device with an Ethernet connector is the notebook.

When I saw the ASUS WL-330N3G wireless mobile router I immediately bought the gadget. It's a small and portable router with 3 main uses for me:

Connect a 3G stick to it and the router will share the UMTS Internet via cable and a wifi network.
Connect it to the Ethernet cable from the hotel and use the internet via the wifi network.
Connect the router to a wireless hotel hotspot, authenticate and then use the single device hotspot account for accessing the Internet from both wired and wireless devices.

When playing around with the router you can brick the device (e.g. uploading incorrectly rebuilt firmware from the GPL sources). If this happens, the device will not boot correctly any more but will be flashing it's power LED and possibly the network activity LED as well. The device can be put into rescue mode however where it will take a tftp uploaded firmware file and flash it:

Connect the router to the Ethernet port of your computer.
Connect the router to your USB port or the supplied USB power adapter.
Press the restore button on the back of the device and hold it for 10 seconds or so.
If you are running tcpdump on the Ethernet interface you should see ARP requests from 192.168.1.1 for 192.168.1.20.
Configure your Ethernet IPv4 address as static: 192.168.1.20 netmask 255.255.255.0.
Use tftp to upload a firmware file to the device:
Under Windows this can be done with "tftp -i 192.168.1.1 put WL-330N3G_1.0.2.0.trx".
Under Linux you can use the "tftp 192.168.1.1" command and then send the following commans: "binary", "trace", "rexmt 1" and finally "put WL-330NG_1.0.2.0.trx" to upload the firmware image.
Wait...
The tftp server on the device will send OACK and reboot

At this point the device has recovered and you'll be able to log in again...

Monitoring a Snom phone with MRTG through SNMP

andreas@dicp.de (andreas) — Fri, 28 Jan 2011 10:58:57 +0100

Snom is the maker of pretty decent VoIP phones running Linux. I have had a Snom 360 for some time now and am reasonably happy with it.

The Snom phones do support SNMP but their SNMP daemon is severly limited. It only supports GETs on a small number of OIDs, doesn't support WALK and standard MIBs like the system-MIB are not supported. The Snom Wiki has a list of the supported OIDs and a description how to enable SNMP on the phones.
The limited support makes autodetection by network management systems or MRTG's cfgmaker fail. In order to chart this data, a manually created template is therefore needed.

Traffic Monitoring (bytes) a Snom Phone

The Snom phone exports all it's interfaces aggregated. This means all vlans and locally generated traffic. The only traffic not exported is the traffic generated on the loopback interface and the traffic bypassing the phone completely via the internal switch. The latter means that the traffic of the machine connected to the PC/passthrough port is not monitored. The MRTG template to chart the incoming and outgoing bytes is the following. The IP Address 192.168.2.124 would have to be changed, as well as the descriptive details.

######################################################################
# System: Snom360
# Description: Snom VoIP Phone
# Contact: System Administration <root@localhost>
# Location: Amsterdam, The Netherlands
######################################################################

### Interface Net >> Descr: 'Net' | Name: 'Net Port' | Ip: '192.168.2.124' | Eth: '' ###

Target[192.168.2.124_Net_byte]: 1.3.6.1.2.1.7526.2.1.1&1.3.6.1.2.1.7526.2.2.1:public@192.168.2.124
RouterUptime[192.168.2.124_Net_byte]: 1.3.6.1.2.1.7526.2.8:public@192.168.2.124
SetEnv[192.168.2.124_Net_byte]: MRTG_INT_IP="" MRTG_INT_DESCR="Net"
MaxBytes[192.168.2.124_Net_byte]: 12500000
Title[192.168.2.124_Net_byte]: Traffic Analysis for Net -- 192.168.2.124
PageTop[192.168.2.124_Net_byte]: <h1>Traffic Analysis for Net -- 192.168.2.124</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>192.168.2.124 in Amsterdam</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>root@localhost</td>
</tr>
<tr>
<td>Description:</td>
<td>Net Port</td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
<tr>
<td>Max Speed:</td>
<td>100.0 Mbits/s</td>
</tr>
</table>
</div>

Traffic Monitoring (packets) a Snom Phone

The setup to monitor packets is basically the same as for traffic. MRTG can do this out of the box and only needs labels changed.

######################################################################
# System: Snom360
# Description: Snom VoIP Phone
# Contact: System Administration <root@localhost>
# Location: Amsterdam, The Netherlands
######################################################################

### Interface Net >> Descr: 'Net' | Name: 'Net Port' | Ip: '192.168.2.124' | Eth: '' ###

Target[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.1.2&1.3.6.1.2.1.7526.2.2.2:public@192.168.2.124
RouterUptime[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.8:public@192.168.2.124
SetEnv[192.168.2.124_Net_pkts]: MRTG_INT_IP="" MRTG_INT_DESCR="Net"
MaxBytes[192.168.2.124_Net_pkts]: 10000000
Title[192.168.2.124_Net_pkts]: Traffic Analysis (packets) for Net -- 192.168.2.124
YLegend[192.168.2.124_Net_pkts]: Pkts per Second
Legend1[192.168.2.124_Net_pkts]: Avg Input Unicast Packets
Legend2[192.168.2.124_Net_pkts]: Avg Output Unicast Packets
Legend3[192.168.2.124_Net_pkts]: Maximal Input Unicast Packets
Legend4[192.168.2.124_Net_pkts]: Maximal Output Unicast Packets
LegendI[192.168.2.124_Net_pkts]:  ifInUcastPkts: 
LegendO[192.168.2.124_Net_pkts]:  IfOutUcastPkts: 
ShortLegend[192.168.2.124_Net_pkts]: p/s
PageTop[192.168.2.124_Net_pkts]: <h1>Traffic Analysis (packets) for Net -- 192.168.2.124</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>192.168.2.124 in Amsterdam</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>root@localhost</td>
</tr>
<tr>
<td>Description:</td>
<td>Net Port</td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
</table>
</div>

Some other values worth charting could be CPU load and free memory or the number of registered extensions. This could be useful for tracking down errors. Unfortunately, mrtg is unable to chart this correctly out of the box and needs some help converting the data.
This is therefore left as an excercise to the reader.

Installing OpenWrt on a Microtik Routerboard RB433

andreas@dicp.de (andreas) — Thu, 13 Nov 2008 23:56:00 +0100

A friend of mine wanted a small embedded linux router. After evaluating several options such as Routerboard, Soekris or ALIX systems, he decided to get himself a Microtik Routerboard 433.

The RB433 is a small MIPS board based on the Atheros AR7100 chipset with a 300MHz CPU, 64MB RAM, 3 100Base-TX ethernet ports and three slots for MiniPCI Cards.

The Routerboard manufacturer Microtik delivers these systems with a software called "RouterOS". I haven't looked any closer at it but it seems to be Linux based system with some proprietary userspace management applications. RouterOS seems mostly to be just a Nortel-ish command line interface and a fugly webinterface. Some people claim that RouterOS is kinda nifty, but it's definitely not hackable enough considering the plans my friend had with his device.

To solve his dilemma, we did what everyone else does in a similar situation, we put a real Linux on it:
OpenWrt to the rescue!

Getting to know the Routerboard

When connecting the power to the Routerboard, the system beeps after a short time and outputs some status messages to the serial port. In order to read these, one has to connect to the serial port via a serial crossover cable and use a terminal program.

Minicom is one such terminal program. Personally though, I prefer cu from the uucp package as it is rather lightweight. All one has to type is cu -l ttyS0 -s 115200 and the bootup messages from the routerboard connected to COM1 will be visible. If you're using any other terminal program, the console settings are the usual 115200bps, 8 data bits, No parity bits and 1 stop bit.

RouterBOOT booter 2.15

RouterBoard 433

Authorization: Passed
CPU frequency: 300 MHz
  Memory size:  64 MB

Press any key within 2 seconds to enter setup

Now is a good time to press any key to enter the setup mode in order to see what the device can do.
You'll be presented with the following screen:

RouterBOOT-2.15
What do you want to configure?
   d - boot delay
   k - boot key
   s - serial console
   o - boot device
   u - cpu mode
   f - cpu frequency
   r - reset booter configuration
   e - format nand
   g - upgrade firmware
   i - board info
   p - boot protocol
   x - exit setup
your choice:

Change the bootmode to tell the device _not_ to boot from the local flash chip (called NAND) but from the network. To do that, press "o" and "e".
Afterwards press "x" to leave the setup.
The device will try to boot and get its kernel from the network.

RouterBOOT booter 2.15

RouterBoard 433

Authorization: Passed
CPU frequency: 300 MHz
  Memory size:  64 MB

Press any key within 2 seconds to enter setup
trying dhcp protocol...........................................................
kernel loading failed

So it seems the device is looking for a kernel.
Let's build one for it to boot sucessfully from...

Building OpenWrt Kamikaze

In order to correctly install the OpenWrt system a linux host is needed to build the kernel image on. I've been using Fedora 9 from the Fedora Project which did the job perfectly. Any other recent distribution should work equally well.

First, check out the current development code via Subversion to have the greatest and latest code:

[athienem@localhost ~]$ mkdir ~/openwrt
[athienem@localhost ~]$ cd ~/openwrt
[athienem@localhost openwrt]$ svn co https://svn.openwrt.org/openwrt/trunk/
[...]
Updated to revision 13193.
[athienem@localhost openwrt]$

In order to install the system correctly we'll be needing two different OpenWrt images:
One image is a JFFS2 or SquashFS image to install onto the target device.
The other image is the so called ramdisk image which can be booted over the network and contains a minimal shell. This image will be used to install the JFFS2 or SquashFS image onto the device and will never again be used. Think of it as a "rescue image".

Both images are basically built the same way.
First, change to the svn checkout directory called trunk and execute make menuconfig to configure the OpenWrt image.

[athienem@localhost openwrt]$ cd trunk/
[athienem@localhost trunk]$ make menuconfig

This command will start the ncurses interface to generate a .config file. It should look familiar to people having built kernels before.
Make sure that "Atheros AR71xx [2.6]" is selected as the target system:

This will make sure that the resulting kernel is bootable on the Routerboard 433.

The next step is to select the target image format, chose ramdisk for now:

Now select "< Exit >" in the main menu and confirm that you want to save your new OpenWrt configuration.

The next step is to actually build the image by calling "make

*** End of OpenWrt configuration.
*** Execute 'make' to build the OpenWrt or try 'make help'.
[athienem@localhost trunk]$ make
Checking 'working-make'... ok.
Checking 'case-sensitive-fs'... ok.
Checking 'working-gcc'... ok.
Checking 'working-g++'... ok.
Checking 'ncurses'... ok.
Checking 'zlib'... ok.
Checking 'gawk'... ok.
Checking 'bison'... ok.
Checking 'flex'... ok.
Checking 'unzip'... ok.
Checking 'bzip2'... ok.
Checking 'patch'... ok.
Checking 'perl'... ok.
Checking 'wget'... ok.
Checking 'gnutar'... ok.
Checking 'autoconf'... ok.
Checking 'non-root'... ok.
Collecting target info: done
Collecting package info: done
Checking 'bison'... ok.
Checking 'automake'... ok.
 make[2] tools/install
[...]
 make[2] target/install
 make[3] -C target/linux install
 make[2] package/index
[athienem@localhost trunk]$

Everything went fine and there should be a ramdisk image in elf format:

[athienem@localhost trunk]$ ls -all bin/openwrt-ar71xx-vmlinux-initramfs.elf 
-rwxrwxr-x 1 athienem athienem 3735060 2008-11-13 22:27 bin/openwrt-ar71xx-vmlinux-initramfs.elf
[athienem@localhost trunk]$

The next step is to build the system image to be installed on the device. Execute make menuconfig again but this time select either squashfs or jffs2 as the target image format instead of ramdisk:
After saving the config, execute make again. This time, it should be much faster as nearly everything is already compiled.

#
# using defaults found in .config
#


*** End of OpenWrt configuration.
*** Execute 'make' to build the OpenWrt or try 'make help'.

[athienem@localhost trunk]$ make
++ mkdir -p /home/athienem/openwrt/trunk/staging_dir/toolchain-mips_gcc4.1.2
++ cd /home/athienem/openwrt/trunk/staging_dir/toolchain-mips_gcc4.1.2
++ mkdir -p bin lib include stamp
 make[1] world
[...]
 make[2] target/install
 make[3] -C target/linux install
 make[2] package/index
[athienem@localhost trunk]$

Now the bin/ directory should be filled with some files:

[athienem@localhost trunk]$ ls -all bin/
total 23656
drwxrwxr-x  3 athienem athienem    4096 2008-11-08 18:25 .
drwxrwxr-x 15 athienem athienem    4096 2008-11-13 22:44 ..
-rw-rw-r--  1 athienem athienem     710 2008-11-13 22:46 md5sums
-rw-rw-r--  1 athienem athienem 1499367 2008-11-08 18:25 openwrt-ar71xx-rootfs.tgz
-rw-rw-r--  1 athienem athienem 1441792 2008-11-08 18:25 openwrt-ar71xx-root.squashfs
-rw-rw-r--  1 athienem athienem 2492740 2008-11-13 22:46 openwrt-ar71xx-uImage.gz
-rwxrwxr-x  1 athienem athienem 2248838 2008-11-08 18:25 openwrt-ar71xx-vmlinux.bin
-rwxrwxr-x  1 athienem athienem 2258096 2008-11-08 18:25 openwrt-ar71xx-vmlinux.elf
-rw-rw-r--  1 athienem athienem 1048576 2008-11-08 18:25 openwrt-ar71xx-vmlinux.gz
-rwxrwxr-x  1 athienem athienem 3725815 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.bin
-rwxrwxr-x  1 athienem athienem 3735072 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.elf
-rw-rw-r--  1 athienem athienem 2555904 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.gz
-rw-rw-r--  1 athienem athienem 2293760 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.lzma
-rw-rw-r--  1 athienem athienem  786432 2008-11-08 18:25 openwrt-ar71xx-vmlinux.lzma
drwxrwxr-x  3 athienem athienem    4096 2008-11-08 17:50 packages
[athienem@localhost trunk]$

Booting OpenWrt on the RouterBoard

To boot the routerboard, a dhcp server is needed to tell the bootloader on the Routerboard which IP address it should use and where to get it's bootable kernel image.
The tftp server is needed to actually serve said image to the RouterBoard.

Under Fedora linux, installing both just needs the command yum install -y dhcp tftp-server. To activate both services, chkconfig can be used as root:

[root@localhost ~]# chkconfig dhcpd on
[root@localhost ~]# chkconfig tftp on

The configuration for the dhcpd needs to be adapted to the local circumstances. The setup I've been using was a crosslinked cable between the notebook and the Routerboard with a manually configured IP address of 192.168.23.254/24. All that is configured in that file is to assign the RouterBoard an IP address and tell it to boot the file vmlinux. Adapt the following file as needed for your own circumstances:

[root@localhost ~]# cat /etc/dhcpd.conf 
# Global Parameters

authoritative;

max-lease-time 604800;
default-lease-time 3100;

ddns-update-style none;
ddns-ttl 7200;

allow booting;
allow bootp;
one-lease-per-client true;

subnet 192.168.23.0 netmask 255.255.255.0 {
	option routers 192.168.23.254;
	option subnet-mask 255.255.255.0;
	option broadcast-address 192.168.23.255;
	ignore client-updates;
}

group {
	host routerboard {
		hardware ethernet 00:0c:42:32:43:8a;
		next-server 192.168.23.254;
		fixed-address 192.168.23.2;
		filename "vmlinux";
	}

}
[root@localhost ~]#

Start the dhcp server by calling service dhcpd start, if there are any problems, look into /var/log/messages and fix the issues noted there.

The tftp-server has already been activated earlier but might need a service xinetd restart to be really started. Do that.
Then copy the ramdisk image named openwrt-ar71xx-vmlinux-initramfs.elf to the tftproot. This is /tftpboot on older systems or /var/lib/tftpboot/ on newer systems. Name the copied file vmlinux.

If everything is working fine, the system should boot:

RouterBOOT booter 2.15

RouterBoard 433

Authorization: Passed
CPU frequency: 300 MHz
  Memory size:  64 MB

Press any key within 2 seconds to enter setup...

trying dhcp protocol... OK
resolved mac address 00:1C:23:03:AA:F8
Gateway: 192.168.23.254
transfer started ............................ transfer ok, time=1.68s
setting up elf image... OK
jumping to kernel code
Linux version 2.6.26.7 (athienem@localhost.localdomain) (gcc version 4.1.2) #1 Sat Nov 8 18:11:40 CET 2008
console [early0] enabled
CPU revision is: 00019374 (MIPS 24K)
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal          0 ->    16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    16384
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
Writing ErrCtl register=000227c0
Readback ErrCtl register=000227c0
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 60768k/65536k available (1762k kernel code, 4700k reserved, 312k data, 1572k init, 0k highmem)
SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 484 bytes
NET: Registered protocol family 16
MIPS: machine is MikroTik RouterBOARD 433/AH
registering PCI controller with io_map_base unset
PCI: mapping irq 33 to pin1@0000:00:13.0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
yaffs Nov  8 2008 18:08:56 Installing. 
msgmni has been set to 118
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A
console handover: boot [early0] -> real [ttyS0]
ag71xx_mdio: probed
eth0: Atheros AG71xx at 0xba000000, irq 5
eth1: Atheros AG71xx at 0xb9000000, irq 4
NAND flash driver for RouterBoard 4xx series version 0.1.10
NAND SPI clock 25000 kHz (AHB 150000 kHz / 6)
FLASH SPI clock 25000 kHz (AHB 150000 kHz / 6)
NAND device: Manufacturer ID: 0xad, Chip ID: 0x76 (Hynix NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 828 at 0x00cf0000
Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00040000 : "booter"
0x00040000-0x00400000 : "kernel"
0x00400000-0x04000000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
split_squashfs: no squashfs found in "NAND 64MiB 3,3V 8-bit"
Atheros AR71xx SPI Controller driver version 0.2.2
Atheros AR71xx hardware watchdog driver version 0.1.0
Registered led device: rb4xx:yellow:user
TCP vegas registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear 
All bugs added by David S. Miller 
Freeing unused kernel memory: 1572k freed
Algorithmics/MIPS FPU Emulator v1.5
[sighandler]: No more events to be processed, quitting.
[cleanup]: Waiting for children.
[cleanup]: All children terminated.
- preinit -
Press CTRL-C for failsafe

Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
device eth0 entered promiscuous mode
PPP generic driver version 2.4.2
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
wlan: trunk
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 2008-10-02 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, DFS, XR)
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk)
ath_rate_minstrel: look around rate set to 10%
ath_rate_minstrel: EWMA rolloff level set to 75%
ath_rate_minstrel: max segment size in the mrr set to 6000 us
wlan: mac acl policy registered
ath_pci: trunk
PCI: Enabling device 0000:00:13.0 (0000 -> 0002)
Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
ath_pci: wifi0: Atheros 5212: mem=0x10000000, irq=33
eth0: link up (100Mbps/Full duplex)
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state



BusyBox v1.11.2 (2008-11-08 17:55:16 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r13141) -------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

If something didn't work out, check your system log to see what happens. Adding the "-s" parameter to the tftpd binary might be useful as it will log single requests.

Permanently installing OpenWrt on the RouterBoard

As we have an accessible Linux system running now on the RouterBoard the available tools such as scp and mtd can be used to copy the needed files onto the NAND device and thus permanently install OpenWrt on the device.

Under Linux the NAND device is partitioned and can be accessed through the mtd framework which exports some information to userspace through the /proc filesystem:

root@OpenWrt:/# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00004000 "booter"
mtd1: 003c0000 00004000 "kernel"
mtd2: 03c00000 00004000 "rootfs"

As can easily be seen, there are three "partitions" available. Leave the one called "booter" alone, it might be important and contain the bootloader. I haven't checked. All we're interested in is "kernel" and "rootfs". The former contains the kernel, the latter the root filesystem.

To install the elf kernel binary named openwrt-ar71xx-vmlinux.elf, it has to be transferred onto the RouterBoard and written onto the second mtd partition. Make sure that the file is called kernel.
Note: OpenWrt configures its IP address to be 192.168.1.1 on bootup. You might have to change this with ifconfig.

root@OpenWrt:/# scp athienem@192.168.23.254:openwrt/trunk/bin/openwrt-ar71xx-vmlinux.elf /tmp/
root@OpenWrt:/# mount /dev/mtdblock1 /mnt/
yaffs: dev is 32505857 name is "mtdblock1"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.1, "mtdblock1"
root@OpenWrt:/# mv /tmp/openwrt-ar71xx-vmlinux.elf /mnt/kernel
root@OpenWrt:/# ls /mnt
kernel      lost+found
root@OpenWrt:/# umount  /mnt/
save exit: isCheckpointed 0
root@OpenWrt:/#

The kernel image is installed.
The rootfs is even easier, as the mtd-device does not need to be mounted at all to write the squashfs image called openwrt-ar71xx-root.squashfs in my case.
This just needs to be written as is onto the mtd block device named rootfs:

root@OpenWrt:/# scp athienem@192.168.23.254:openwrt/trunk/bin/openwrt-ar71xx-root.squashfs /tmp/
root@OpenWrt:/# cat /tmp/openwrt-ar71xx-root.squashfs > /dev/mtdblock2
root@OpenWrt:/#

After a few seconds the squashfs image has been written and the device can be rebooted. Don't forget to disable the network boot in the Bios:

root@OpenWrt:/# reboot
root@OpenWrt:/# br-lan: port 1(eth0) entering disabled state
device eth0 left promiscuous mode
br-lan: port 1(eth0) entering disabled state
eth0: link down
Restarting system.


RouterBOOT booter 2.15

RouterBoard 433

Authorization: Passed
CPU frequency: 300 MHz
  Memory size:  64 MB

Press any key within 2 seconds to enter setup..

RouterBOOT-2.15
What do you want to configure?
   d - boot delay
   k - boot key
   s - serial console
   o - boot device
   u - cpu mode
   f - cpu frequency
   r - reset booter configuration
   e - format nand
   g - upgrade firmware
   i - board info
   p - boot protocol
   x - exit setup
your choice:

Press "o" twice and "x" once to continue booting normally from the NAND.

RouterBOOT booter 2.15

RouterBoard 433

Authorization: Passed
CPU frequency: 300 MHz
  Memory size:  64 MB

Press any key within 2 seconds to enter setup..
loading kernel from nand... OK
setting up elf image... OK
jumping to kernel code
Linux version 2.6.26.7 (athienem@localhost.localdomain) (gcc version 4.1.2) #2 Sat Nov 8 18:25:41 CET 2008
console [early0] enabled
CPU revision is: 00019374 (MIPS 24K)
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal          0 ->    16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    16384
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
Writing ErrCtl register=000227c0
Readback ErrCtl register=000227c0
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62208k/65536k available (1762k kernel code, 3252k reserved, 312k data, 124k init, 0k highmem)
SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 484 bytes
NET: Registered protocol family 16
MIPS: machine is MikroTik RouterBOARD 433/AH
registering PCI controller with io_map_base unset
PCI: mapping irq 33 to pin1@0000:00:13.0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
yaffs Nov  8 2008 18:08:56 Installing. 
msgmni has been set to 121
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A
console handover: boot [early0] -> real [ttyS0]
ag71xx_mdio: probed
eth0: Atheros AG71xx at 0xba000000, irq 5
eth1: Atheros AG71xx at 0xb9000000, irq 4
NAND flash driver for RouterBoard 4xx series version 0.1.10
NAND SPI clock 25000 kHz (AHB 150000 kHz / 6)
FLASH SPI clock 25000 kHz (AHB 150000 kHz / 6)
NAND device: Manufacturer ID: 0xad, Chip ID: 0x76 (Hynix NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 828 at 0x00cf0000
Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00040000 : "booter"
0x00040000-0x00400000 : "kernel"
0x00400000-0x04000000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
split_squashfs: no squashfs found in "NAND 64MiB 3,3V 8-bit"
Atheros AR71xx SPI Controller driver version 0.2.2
Atheros AR71xx hardware watchdog driver version 0.1.0
Registered led device: rb4xx:yellow:user
TCP vegas registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear 
All bugs added by David S. Miller 
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 124k freed
Please be patient, while OpenWrt loads ...
Algorithmics/MIPS FPU Emulator v1.5
- preinit -
Press CTRL-C for failsafe
- init -

Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
device eth0 entered promiscuous mode
PPP generic driver version 2.4.2
ip_tables: (C) 2000-2006 Netfilter Core Team

nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
wlan: trunk
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 2008-10-02 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, DFS, XR)
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk)
ath_rate_minstrel: look around rate set to 10%
ath_rate_minstrel: EWMA rolloff level set to 75%
ath_rate_minstrel: max segment size in the mrr set to 6000 us
wlan: mac acl policy registered
eth0: link up (100Mbps/Full duplex)
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
ath_pci: trunk
PCI: Enabling device 0000:00:13.0 (0000 -> 0002)
Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
ath_pci: wifi0: Atheros 5212: mem=0x10000000, irq=33



BusyBox v1.11.2 (2008-11-08 17:55:16 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r13141) -------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

Done.

OpenWrt has been installed on the device and can be used and configured as usual.

For more information about configuring, using and customizing OpenWrt see the Kamikaze Manual, the OpenWrt Wiki or use the source. For network related configuration issues, /lib/network/config.sh and the files in /lib/wifi/ are a good start.

Unbricking an Intel Pro/1000 (e1000) network interface

andreas@dicp.de (andreas) — Thu, 16 Oct 2008 23:23:31 +0200

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:

/* 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;
}

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:

<?php
$file = "82547.eep";

$handle = {FNAMEL}">fopen($file, "r");
$contents = {FNAMEL}">fread($handle, {FNAMEL}">filesize($file));
{FNAMEL}">fclose($handle);

$tok = {FNAMEL}">strtok($contents, " \n\r");
$eepdata = "";

$i = 0;
while ($tok !== false) {
$eepdata .= {FNAMEL}">substr($tok, 2,2).' ';
$eepdata .= {FNAMEL}">substr($tok, 0,2).' ';
$tok = {FNAMEL}">strtok(" \n\r");
$i++;
}

$tok = {FNAMEL}">strtok($eepdata, " ");
$i = 0;
while ($tok !== false) {
$offset = {FNAMEL}">sprintf("%x", $i);
{FNAMEL}">echo "ethtool -E eth0 magic 0x00 offset 0x$offset value 0x$tok\n";
$tok = {FNAMEL}">strtok(" ");
$i++;
}
?>

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:

span style="color: #ff0000;">"\n"

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.

lm_sensors on an ASUS Pundit-R350

andreas@dicp.de (andreas) — Wed, 16 Jul 2008 00:12:37 +0200

I've recently started to unpack some of the boxes from my last move. In there I found an older Booksize PC, an ASUS Pundid-R350. It's not the nicest system I've ever had, the fan is incredibly noisy and it's constantly switching to full speed when the system is loaded. I guess I should swap the fan for something much quieter, but haven't had the time yet.

It took me some time to figure out the correct settings to have lm_sensors running on the device as there's been no template configuration to be found on google. To rectify this omission, I'm dumping mine on my blog:

# Asus Pundit-R350
chip "it8712-∗"

# Voltage monitors as advised in the It8705 data sheet

    label in0 "VCore 1"
    label in2 "+3.3V"
    label in3 "+5V"
    label in4 "+12V"

    # Seem not to be connected on the Pundit-R
    ignore in1
    ignore in5
    ignore in6
    ignore in7
    ignore in8
    ignore cpu0_vid

    compute in3 ((6.8/10)+1)∗@ ,  @/((6.8/10)+1)
    compute in4 ((30/10) +1)∗@  , @/((30/10) +1)

# Set some upper and lower limits

    set in0_min 1.4 ∗ 0.95
    set in0_max 1.4 ∗ 1.05
    set in2_min 3.3 ∗ 0.95
    set in2_max 3.3 ∗ 1.05
    set in3_min 5.0 ∗ 0.95
    set in3_max 5.0 ∗ 1.05
    set in4_min 12 ∗ 0.95
    set in4_max 12 ∗ 1.05

# Temperature
    label temp1       "CPU Temp"
    set temp1_type 3
    set   temp1_max   75
    set   temp1_min   15
    label temp2       "M/B Temp"
    set temp2_type 2
    set   temp2_max   55
    set   temp2_min   15
    ignore temp3

# Fans
   set fan1_div 2
   set fan1_min 2500
   ignore fan2
   ignore fan3

With this configuration written to /etc/sensors3.conf the freshly installed fedora 9 system correctly shows some sensible sensor readings:

[root@workstation ~]# sensors
it8712-isa-0260
Adapter: ISA adapter
VCore 1:     +1.39 V  (min =  +1.33 V, max =  +1.47 V)
+3.3V:       +3.26 V  (min =  +3.14 V, max =  +3.47 V)
+5V:         +5.00 V  (min =  +4.76 V, max =  +5.24 V)
+12V:       +12.03 V  (min = +11.39 V, max = +12.61 V)
fan1:       3994 RPM  (min = 2657 RPM, div = 2)
CPU Temp:    +65.0°C  (low  = +15.0°C, high = +75.0°C)  sensor = thermal diode
M/B Temp:    +50.0°C  (low  = +15.0°C, high = +55.0°C)  sensor = transistor

[root@workstation ~]#

Nicht nur die T-Com hasst mich...

andreas@dicp.de (andreas) — Tue, 13 Mar 2007 18:43:47 +0100

Nachdem ich ja schon ausgiebig meine Abenteuer mit der T-Com beklagte, musste ich heute ernüchtert feststellen, dass nicht nur die T-Com mich hasst. Nein, auch Cisco mag mich nicht.

Heute Nacht wurde der Access Concentrator in Stuttgart umgetauscht. Früher war ich an STGX42-erx, einer Juniper Networks E-Series, angeschlossen. Mittlerweile ist es ein Cisco 10000 Router mit der Performance Routing Engine 3.

Das Ergebnis ist deutlich:

Mar 13 17:37:29 rtr pppd[19032]: pppd 2.4.3 started by root, uid 0
Mar 13 17:37:29 rtr pppd[19032]: Using interface ppp0
Mar 13 17:37:30 rtr pppd[19032]: Connect: ppp0 <--> /dev/pts/0
Mar 13 17:37:30 rtr pppoe[19035]: PPP session is 63082
Mar 13 17:37:31 rtr pppd[19032]: CHAP authentication succeeded
Mar 13 17:37:31 rtr pppd[19032]: local  IP address 91.32.100.35
Mar 13 17:37:31 rtr pppd[19032]: remote IP address 217.0.118.57
Mar 13 17:50:01 rtr pppd[19032]: LCP terminated by peer
Mar 13 17:50:01 rtr pppd[19032]: Connect time 12.5 minutes.
Mar 13 17:50:01 rtr pppoe[19035]: Session 63082 terminated -- received PADT from peer
Mar 13 17:50:01 rtr pppoe[19035]: Sent PADT
Mar 13 17:50:01 rtr pppd[19032]: Sent 39902910 bytes, received 18850825 bytes.
Mar 13 17:50:01 rtr pppd[19032]: Modem hangup
Mar 13 17:50:01 rtr pppd[19032]: Connection terminated.
Mar 13 17:50:02 rtr pppd[19032]: Exit.

Man sieht also sehr schön, wie es eben nicht geht. :-(

"Nicht nur die T-Com hasst mich..." vollständig lesen

Nur eine schlechte Tat ist eine gute Tat

andreas@dicp.de (andreas) — Wed, 3 Jan 2007 20:29:00 +0100

Mission accomplished.

Damit BENQ nicht allzuviel Freude an der gekauften (SPUCK!)Siemens Handysparte hat war ich gerade so frei und habe mein gebraucht gekauftes Siemens S65 Mobiltelefon noch am Tag vor Ablauf der Garantie bzw. Gewährleistung reklamiert. Das Display ist verkratzt, die Taste 0 funktioniert nicht immer auf Anhieb und seit Verleihung meines Telefons letzter Woche fehlt auch die silberne Wippe an der Seite des Telefons auf Displayhöhe.
Damit es nicht allzuviel Stress bei der Reklamation gibt, noch vorher das Fullbackup eingespielt damit das Vodafone gebrandete Telefon auch in bescheidenem Vodafone Branding zurückkommt.

Nachdem ich dann auch einen auf überforderter Kunde, der keine Ahnung und hat doch nur noch kurz vor Geschäftsschluss beim vielen Gedräge sein Handy repariert haben will, gemacht habe wurde das Telefon dann auch angenommen und ich kriege in ein paar Tagen ein neues.
Da war der alte Siemens Vorabtausch Service wesentlich angenehmer und wurde zurecht besonders bei Geschäftskunden sehr geschätzt.

Sobald das neue Gerät dann da ist, wird es hier ein oder zwei Artikel zum Unbranden und Firmware-Modifizieren zum Abschalten lästiger Features geben.
Das rote Vodafone Branding ist echt das letzte.

My first hands-on OLPC experience

andreas@dicp.de (andreas) — Tue, 2 Jan 2007 18:01:35 +0100

At ~~this~~ last year's Chaos Communication Congress in Berlin there was a short presentation about the One Laptop Per Child system.

I couldn't make the talk itself but managed to take a closer look at the OLPC later on when it was on display at the Wikipedia booth.
My opinion of the device so far is mixed.
The software collection looks nice but still a bit rough about the edges.
The hardware in general definitely looks good. Small, portable and low-power. The display especially is really good looking and offers an enjoyable sharp display. I expected something a bit more low quality after following the swizzle mode blog post by Manu but was positivly surprised.
The keyboard however sucked!

I might be spoiled keyboardwise as I'm nearly exclusivly using IBM Model M Keyboards which feature distinct tactile feedback and I really detest the soft keyboards which are generally available today.

The OLPC keyboard however is something else. I haven't yet seen such a mushy keyboard in a notebook. The keys are quite flat with a very small keydrop of said 1mm. This would be acceptable if there would be some more resistance when depressing the keys. The BTest-1 System I tried however was so squashy I had to keep looking at the screen to check if the key I pressed actually was pressed.
In general the keyboard feels rotten which is a pity as the system would otherwise be very neat.

Snom 360 SIP Telefon an einer Elmeg ICT mit VoIP-VPN Modul

andreas@dicp.de (andreas) — Tue, 10 Oct 2006 01:14:26 +0200

Ich hatte ja zuvor schon ein wenig über das Zurücksetzen eines Elmeg VoIP-VPN Modules und wie über die NAT-Konfiguration für die Elmeg Anlage geschrieben.

Leider ergibt sich noch das unangenehme Problem, dass sich das Snom 360 SIP-Telefon nicht an der Elmeg Anlage anmelden kann. Die Fehlermeldung ist immer die selbe. Auf der Elmeg Telefonanlage findet sich folgende Logmeldung.:

iwu: [MSG] SIP: Registration reject:
 sip:810@192.168.1.250, guest 0, expires 60, location 2, cause AUTH REQUIRED

Eine genauere Analyse des SIP Verkehrs ergibt, dass das Telefon sich nicht an der Anlage anmelden kann, da die Digest-Authentication Informationen nicht stimmen.

Die Lösung für dieses Problem ist, beim Snom Telefon im "Identitäts Menü" für die entsprechende Leitung im "Sip-Reiter" die Unterstützung für "Langer SIP-Contact (RFC3840)" zu deaktivieren.

Anschliessend kann sich das Telefon sofort bei der Anlage registrieren.

Zurücksetzen eines Elmeg VoIP-VPN Gateway

andreas@dicp.de (andreas) — Fri, 7 Jul 2006 15:41:00 +0200

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.

"Zurücksetzen eines Elmeg VoIP-VPN Gateway" vollständig lesen

Spass mit der Rittal CMC-TC PUII

andreas@dicp.de (andreas) — Thu, 29 Jun 2006 14:15:00 +0200

[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.

"Spass mit der Rittal CMC-TC PUII" vollständig lesen

Bosse T315 auf Tonwahl umstellen

andreas@dicp.de (andreas) — Mon, 6 Feb 2006 17:11:22 +0100

Mara hatte das Telefon links gekauft, um es an einen VoIP Adapter anzuschliessen.
Das Funktionierte soweit auch gut, aber das Telefon war leider auf Pulswahl eingestellt, und da kein Handbuch dabei war, musste ich mal ein wenig suchen.

Das tolle am Internet ist ja, dass es für wirklich alles eine FAQ gibt. So auch hierfür. Auf FAQ für MFV Telefone wurde ich dann fündig.

Die Vorgehensweise um ein Bosse T315 von Pulswahl auf Tonwahl umzustellen ist also: "SET 1 1590 Wahlwiederholung 037 SET".
Also die Set Taste drücken (Pfeil der in das auf der Ecke stehende Quadrat zeigt), dann 1, dann 1590 und die Wahlwiederholungstaste. Dann 037 für MFV+Flash, oder 036 für MFV+Erde oder 033 für IWV+Erde und dann nochmal die Set Taste.
Fertig.