Feb 16 11

Engineers from exodus intelligence demonstrated an awesome undocumented feature in Cisco Adaptive Security Appliance (ASA), remote code execution via UDP. This feature is implemented in the Cisco IKE feature set. The algorithm for re-assembling IKE payloads fragmented with the Cisco fragmentation protocol contains a bounds-checking flaw that allows a heap buffer to be overflowed with attacker-controlled data.

Find out more:

written by d45id \\ tags: , , , , , , ,

Nov 14 11

SpaceInvadersCisco Catalyst switching devices did not properly parse the „request system shell“ challenge response, which allows local users to obtain Linux root access by leveraging administrative privilege (see also CVE-2014-7990). Harrison Shlong use this to add the new Space Invaders feature to Catalyst switches

written by d45id \\ tags: , , , , ,

Sep 10 30

Heute bin ich einmal wieder in die Situation gekommen das IOS aus dem ROMMON wieder herzustellen. Da ich so was nicht gerade alle Tage mache und daher etwas in das Grübeln gekommen bin nutze ich gleich die Gelegenheit um das ganze etwas zu dokumentieren.

Die Wiederherstellung funktioniert entweder via XModem oder TFTP. Ich erläutere hier lediglich die TFTP-Varainte.

  • Ersten LAN-Port des Routers mit dem Netzwerk verbinden
  • Setzen folgender Variablen im ROMMON:

rommon 1 > IP_ADDRESS=192.168.1.100
rommon 2 > IP_SUBNET_MASK=255.255.255.0
rommon 3 > DEFAULT_GATEWAY=192.168.1.1
rommon 4 > TFTP_SERVER=192.168.1.69
rommon 5 > TFTP_FILE=c870-adventerprisek9-mz.124-11.XJ4.bin

  • Wiederherstellung starten

rommon 6 > tftpdnl

IP_ADDRESS: 192.168.1.100
IP_SUBNET_MASK: 255.255.255.0
DEFAULT_GATEWAY: 192.168.1.1
TFTP_SERVER: 192.168.1.69
TFTP_FILE: c870-adventerprisek9-mz.124-11.XJ4.bin
Do you wish to continue? y/n:  [n]:  y

Receiving c870-adventerprisek9-mz.124-11.XJ4.bin from 192.168.1.69 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
File reception completed.
File flash:/c870-adventerprisek9-mz.124-11.XJ4.bin already exists.
Deleting flash:/c870-adventerprisek9-mz.124-11.XJ4.bin before creating new file with same name.
Writing flash:/c870-adventerprisek9-mz.124-11.XJ4.bin
Write operation will take approximately 108 to 324 seconds

  • IOS booten

rommon 7 > boot
Booting flash:/c870-adventerprisek9-mz.124-11.XJ4.bin
Self decompressing the image : ################################################################################################################## [OK]

  • Fertig

written by d45id \\ tags: , , , ,

Aug 10 24

The following commands I present are  only tested with the Cisco 1700, 2600 and ISR Series

Step 1: Boot the router and interrupt the boot sequence as soon as text appears on the screen.

Press „Ctrl-Break“

rommon 1 >

Step 2: Change the configuration register to ignore contents of NVRAM

rommon 1 > confreg 0x2142

rommon 2 >

Step  3: Reload the router.

rommon 2 > reset

Step 4: Enter privileged mode. (Do not enter setup mode!)

Router>enable

Router#

Step5: Copy the startup configuration into the running configuration.

Router#copy startup-config running-config

…<output cut>…

rt1#

Step 6: Change the password

rt1#configure terminal

rt1(config)#enable secret new

Step 7: Reset the configuration register back to its default value.

rt1(config)#config-register 0x2102

rt1(config)#

Step 8: Save the configuration

rt1#wr

Building configuration …

[OK]

rt1#

Step 9: Verify the configuration register.

rt1#show version

…<output cut>…

Configuration register is 0x2142 (will be 0x2102 at next reload)

rt1#

Step 10: Reload the Router

rt1#reload





written by d45id \\ tags: , , , ,

Jul 10 14

Ich habe mich gerade etwas mit den verschiedenen Typen der Password-Verschlüsselung des Cisco IOS auseinander gesetzt und möchte im folgenden die verschieden Typen kurz darstellen, sowie an einem kleinen Rechenbeispiel zeigen wie „sicher“ so ein Type 7 Passwort wirklich ist.

Typ 0:
besagt, dass es sich hierbei um ein unverschlüsseltes Passwort handelt. Mit dem Typ 0 wird auch das Plain-Text-Password eingegeben.

Typ 5:
hierbei handelt es sich um ein kryptografisch gesichertes Passwort. Dieses wird durch ein MD5-Hash-Verfahren berechnet und kann ich wieder zurückgerechnet werden. Im Cisco IOS kommt dies z.B. beim enable secret oder username xxx secret zum Einsatz.

Ein kurzer Blick ins IOS:

test-router(config)#enable secret ?
0      Specifies an UNENCRYPTED password will follow
5      Specifies an ENCRYPTED secret will follow
LINE   The UNENCRYPTED (cleartext) ‚enable‘ secret

test-router(config)#username test secret ?
0     Specifies an UNENCRYPTED secret will follow
5     Specifies a HIDDEN secret will follow
LINE  The UNENCRYPTED (cleartext) user secret

Typ 6:
Dieser Typ kommt z.B. bei der Verschlüsselung von Pre-Shared-Keys bei IPSec zum Einsatz:

test-router(config)#crypto isakmp key ?
0  Specifies an UNENCRYPTED password will follow
6  Specifies an ENCRYPTED password will follow

Diese Passwörter werden durch eine AES-Verschlüsselung gebildet.

Typ 7:
Dieser Type wird durch service password-encryption zusammen mit “normalen” Passwörtern (enable password, username … password, Line-Passwörter) gebildet:

test-router(config)#enable password ?
0      Specifies an UNENCRYPTED password will follow
7      Specifies a HIDDEN password will follow
LINE   The UNENCRYPTED (cleartext) ‚enable‘ password

test-router(config)#username d45id password ?
0     Specifies an UNENCRYPTED password will follow
7     Specifies a HIDDEN password will follow
LINE  The UNENCRYPTED (cleartext) user password

Der Algorithmus, der hinter dieser Verschlüsselungsmethode steht ist sehr trivial und lässt sich dazu auch noch sehr leicht zurück rechnen. Des weiteren kann von der Länge des verschüsselten Passwortes die Länge des Klartext-Passwortes festgestellt werden:

test-router(config)#enable password c
test-router(config)#do sh run | i enable password
enable password 7 0508
test-router(config)#enable password ci
test-router(config)#do sh run | i enable password
enable password 7 045802
test-router(config)#enable password cis
test-router(config)#do sh run | i enable password
enable password 7 13061E01
test-router(config)#enable password cisc
test-router(config)#do sh run | i enable password
enable password 7 0822455D0A
test-router(config)#enable password cisco
test-router(config)#do sh run | i enable password
enable password 7 14141B180F0B
test-router(config)#

Hier lässt sich sehr schon feststellen, dass dieser Typ ein minimale Länge von zwei Zeichen besitzt und sich das verschlüsselte Paswort mit jeden weiteren Zeichen um zwei Hex-Zeichen verlängert.

Daraus folgt:

(„Länge des verschlüsselten Passwort“ – 2 ) / 2 = „Länges des Klartext-Passwort“

In einem kleinen Rechenbeispiel möchte ich darstellen, wie sich das Passwort zurück rechnen lässt:

enable password 7 111D0C0D18081E58

Das Typ7-Password ist 16 Zeichen lang, das Klartext-Password muß also (16-2)/2=7 Zeichen lang sein.

Zerlegung des Type7-Passwords:
Das Password wird in Blöcke à zwei Zeichen zerlegt:

11 – XOR-Offset
1D – das erste Zeichen
0C – das zweite Zeichen
0D – das dritte Zeichen
18 – das vierte Zeichen
08 – das fünfte Zeichen
1E – das sechste Zeichen
58 – das siebte Zeichen

Ermittlung der XOR-Werte:
Die Entschlüsselung enthält eine Reihe von xor-Operationen. Diese werden mit Werten der im IOS vorgegebenen xor-Tabelle ausgeführt:

0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f,
0x41, 0x2c, 0x2e, 0x69, 0x79, 0x65, 0x77, 0x72,
0x6b, 0x6c, 0x64, 0x4a, 0x4b, 0x44, 0x48, 0x53,
0x55, 0x42, 0x73, 0x67, 0x76, 0x63, 0x61, 0x36,
0x39, 0x38, 0x33, 0x34, 0x6e, 0x63, 0x78, 0x76,
0x39, 0x38, 0x37, 0x33, 0x32, 0x35, 0x34, 0x6b,
0x3b, 0x66, 0x67, 0x38, 0x37

Die erste Zahl im Typ7-Password ist 11, an der 12. Stelle beginnen die 7 xor-Werte: 0×69, 0×79, 0×65, 0×77, 0×72, 0x6b, 0x6c

Ermittlung des Passwortes:
Nun verknüpfen wir diese Werte fleißig miteinander und lesen das Hex-Ergebnis in einer ASCII-Tabelle ab um so das Passwort zu erlagen:

0x1D xor 0x69 = 0x74
0x0C xor 0x79 = 0x75
0x0D xor 0x65 = 0x65
0x18 xor 0x77 = 0x6F
0x08 xor 0x72 = 0x7A
0x1E xor 0x6b = 0x75
0x58 xor 0x6c = 0x34

0x74 = t
0x75 = u
0x68 = h
0x6F = o
0x7A = z
0x75 = u
0x34 = 4

Damit ist das Klartext-Password “tuhozu4” ermittelt.

written by d45id \\ tags: , , , , , , , , ,

Feb 10 19

In einem vergangen Artikel habe ich beschrieben, wie man Debian auf einer NSLU2 über den Installer installiert. Da diese Methode jedoch auf Grund der geringen CPU Leitung der NSLU2 zeitaufwändig ist dokumentiere ich im folgende einen schnelleren Installationsweg.

Vorbereitung der Installation
Das OS soll später auf meiner alten 8589MB großen USB-Festplatte laufen. Dieser muss daher für die Verwendung als erstes vorbereit werden:

Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000bf3de

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1           9         72261   83  Linux
/dev/sda2              10         259     2008125   83  Linux
/dev/sda3             260        1044     6305512+   5  Extended
/dev/sda5             260         291      257008+  82  Linux swap / Solaris
/dev/sda6             292        1044     6048441   83  Linux

Wichtig: Aufgrund des verwendeten Debian Images ist es wichtig das zur Installation das oben beschriebenen Partitionierungsschema verwendet wird.

Anschließend noch die einzelnen Partionen formatieren:

# mkfs.ext2 /dev/sda1
# mkfs.ext3 /dev/sda2
# mkfs.ext3 /dev/sda6
# mkswap /dev/sda5

Nun die Root-Partion mounten:

# mount /dev/sda2 /mnt

Anschließend einen Mountpunkt für die /boot Partion erstellen und diese ebenfalls mounten:

# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Nun das Lenny herunterladen. Das Betriebssystem liegt als komprimiertes (bzip2) Archiv vor, dies erspart die langwirgie Installation. Das Archiv wurde erstellt von Martin Michlmayr und wird auch von ihm gepflegt.:

# cd /mnt
# wget http://people.debian.org/~tbm/nslu2/lenny/base.tar.bz2

oder

# wget http://www.tr0n.net/download/base.tar.bz2

Jetzt wird dieses Archiv nach /mnt entpackt:

# tar xvjf base.tar.bz2

Sobald fertig altes Archiv löschen um Speicherplatz zu sparen:

# rm base.tar.bz2

Nun noch alles aushängen und Platte abziehen

# cd /
# umount /mnt/boot
# umount /mnt

Flashen der neuen NSLU2

  • Das Gerät ausschalten und USB-Geräte abziehen.
  • In den Upgrade-Modus versetzen.
  • Restknopf auf der Rückseite gedrückt halten, Gerät anschalten und warten bis die oberste Diode (Ready/Status) die Farbe auf rot wechselt. Nun den Restknopf wieder loslassen. Die Diode blinkt nun rot/grün.
  • Heruntergeladen Firmware installieren.

upslug2 -i di-nslu2.bin

  • NSLU2 startet nach erfolgreiche Installation neu.
  • FERTIG

Nacharbeit
mit NSLU2 via ssh Verbinden (Benutzername root / Passwort root)

Root Passwort ändern

# passwd

Neue SSH-Keys generieren
Aus Sicherheitsgründen solltet ihr die vorhanden Hostkeys löschen und neue generieren

# rm /etc/ssh/ssh_host*
# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N „“
# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N „“

System updaten

# apt-get update && apt-get dist-upgrade

Reboot

# init 6

written by d45id \\ tags: , , , , ,

Feb 10 18

Introduction
The standard kernel that you build for the NSLU2 requires that the Slug be modified to provide a serial port so that you can interact with the Slug during the boot process and to log in. This page will show you how to boot your Slug into NetBSD using only an ethernet connection. The strategy is to configure and build the kernel so that it automatically finds and mounts the root disk through DHCP and NFS without requiring that we type in the location of the root drive through the serial port. The root disk is a modification of the typical setup that allows an insecure telnet login to the NetBSD kernel running on the NSLU2. Once logged in, you can set up a username and password, enable ssh, and close out the insecure telnet connection.

The command line instructions that follow are for a Linux system using bash. They should be pretty much the same for another *nix system, except for the differences due to the shell.

Get the source code

To get the source code (current):

$ mkdir ~/net
$ export CVS_RSH=“ssh“
$ export CVSROOT=“anoncvs@anoncvs.NetBSD.org:/cvsroot“
$ cd ~/net
$ cvs checkout -A -P src

“/!\ The CVS address didnt work for me. I used: export CVSROOT=“anoncvs@anoncvs.se.NetBSD.org:/cvsroot /!\“

This will create a directory ~/net/src with the source tree in it.

See the section below (“Versions that are known to work“) to get an older version of NetBSD-current that should build and boot correctly. This section also has an update for changes to “build.sh‘‚.

Build the kernel

Note: The procedure shown here works for versions of NetBSD before about August 5, 2008. See the section below “(Versions that are known to work)“ for changes to the three “build.sh“ command lines.

First, build the tools.

$ cd ~/net/src
$ ./build.sh -m evbarm -a armeb tools

You need to get the Intel proprietary firmware for the NSLU2 ethernet controller. Follow the instructions at this location: <~/net/src/sys/arch/arm/xscale/ixp425-fw.README.> After building the firmware as described in the readme file, copy the file “IxNPEMicrocode.dat” to the directory ~/net/src/sys/arch/arm/xscale (the same directory as the README).

NOTE: Versions 3.0 and later of the Intel firmware “’don’t“‘ work. Use version 2.3.2 or 2.4.

We’ll build three versions of the kernel, though only one will be used here. The other two kernels will be used when we move from mounting NetBSD using an NFS root to a disk drive connected to one of the USB ports. Add a configuration file, NSLU2_ALL, with the configuration for the three kernels. This file goes in the same directory as the standard NSLU2 configuration file. Note that we’re including the standard file in our configuration file.

$ cd ~/net/src/sys/arch/evbarm/conf
$ echo ‚include „arch/evbarm/conf/NSLU2″‚ >NSLU2_ALL
$ echo ‚config netbsd-nfs root on npe0 type nfs‘ >>NSLU2_ALL
$ echo ‚config netbsd-sd0 root on sd0a type ffs‘ >>NSLU2_ALL
$ echo ‚config netbsd-sd1 root on sd1a type ffs‘ >>NSLU2_ALL
$ cat NSLU2_ALL
include „arch/evbarm/conf/NSLU2“
config netbsd-nfs root on npe0 type nfs
config netbsd-sd0 root on sd0a type ffs
config netbsd-sd1 root on sd1a type ffs

Now build everything. (Much appreciation to Iain Hibbert for his help in understanding build.sh and its numerous configuration variables!)

$ cd ~/net/src
$ ./build.sh -u -U -m evbarm -a armeb build
$ ./build.sh -u -U -m evbarm -a armeb -V KERNEL_SETS=NSLU2_ALL release

When finished, you’ll find all of the necessary files in ~/net/src/obj/releasedir/evbarm/binary/sets.

$ ls -la ~/net/src/obj/releasedir/evbarm/binary/sets/
total 116200
drwxr-xr-x 2 owner owner 4096 2008-03-07 10:22 .
drwxr-xr-x 5 owner owner 4096 2008-03-07 10:19 ..
-rw-rw-r– 1 owner owner 24189627 2008-03-07 10:21 base.tgz
-rw-rw-r– 1 owner owner 272 2008-03-07 10:22 BSDSUM
-rw-rw-r– 1 owner owner 366 2008-03-07 10:22 CKSUM
-rw-rw-r– 1 owner owner 33559987 2008-03-07 10:21 comp.tgz
-rw-rw-r– 1 owner owner 369051 2008-03-07 10:21 etc.tgz
-rw-rw-r– 1 owner owner 3233648 2008-03-07 10:21 games.tgz
-rw-rw-r– 1 owner owner 25920807 2008-03-07 10:19 kern-ADI_BRH.tgz
-rw-rw-r– 1 owner owner 1267036 2008-03-07 10:19 kern-IXM1200.tgz
-rw-rw-r– 1 owner owner 8615170 2008-03-07 10:19 kern-NSLU2_ALL.tgz
-rw-rw-r– 1 owner owner 2872331 2008-03-07 10:19 kern-NSLU2.tgz
-rw-rw-r– 1 owner owner 8455973 2008-03-07 10:22 man.tgz
-rw-rw-r– 1 owner owner 632 2008-03-07 10:22 MD5
-rw-rw-r– 1 owner owner 3318310 2008-03-07 10:22 misc.tgz
-rw-rw-r– 1 owner owner 1820 2008-03-07 10:22 SHA512
-rw-rw-r– 1 owner owner 274 2008-03-07 10:22 SYSVSUM
-rw-rw-r– 1 owner owner 3815709 2008-03-07 10:22 tests.tgz
-rw-rw-r– 1 owner owner 3073516 2008-03-07 10:22 text.tgz

The kern-ADI_BRH.tgz and kern-IXM1200.tgz are kernels for other ARM boards that are built automatically when you specify -m evbarm. We won’t use them.

Set up the NFS file system

To setup the NFS server, see http://www.netbsd.org/docs/network/netboot/nfs.html and http://www.netbsd.org/docs/network/netboot/files.html.
‚NOTE The instructions that follow are written for system configurations where the NFS/tftp/DHCP server is a different machine than your build machine. If they are the same system, then ignore the ssh and scp commands.

Log into the nfs server using ssh, and setup the NetBSD file structure:

$ sudo mkdir -p /export/client/root/dev
$ sudo mkdir /export/client/home
$ sudo touch /export/client/swap
$ sudo dd if=/dev/zero of=/export/client/swap bs=4k count=4k
$ sudo chmod 600 /export/client/swap
$ sudo mkdir /export/client/root/swap

Copy the necessary files from the build machine to the NFS system. On your build machine:

$ cd ~/net/src/obj
$ scp -r releasedir/evbarm/binary/sets nfsserver:/export/client

Build the NetBSD root file system on the NFS server:

$ cd /export/client/root
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/base.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/comp.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/etc.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/games.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/man.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/misc.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/tests.tgz
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/text.tgz

The next part is slightly more complicated for the two-system configuration. To make the /dev directory for the NFS file system, mount the NFS file system on your build machine:

$ sudo mount -t nfs nfsserver:/export/client/root /mnt/root
$ cd /mnt/root/dev

Then execute the MAKEDEV shell script from your build machine. Skip the mounting part if you use only one system.

$ sudo sh ./MAKEDEV -m ~/net/src/obj/tooldir.YOUR.SYSTEM.HERE/bin/nbmknod all

Save the original NetBSD /etc directory, just in case you would like to refer to it later:

$ sudo cp -r /export/client/root/etc /export/client/root/orig.etc
$ cd /export/client/root/etc

Setup the various files in the exported etc so that the system will boot up and allow logins via telnet. The edit command is shown, along with the final file configuration, except for inetd.conf which is very long.

/export/client/root/etc/hosts

$ sudo nano hosts

# $NetBSD: hosts,v 1.7 2004/08/29 13:26:17 chs Exp $
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for „ifconfig“ and other operations
# before the nameserver is started.
#
#
::1 localhost localhost.
127.0.0.1 localhost localhost.
#
# RFC 1918 specifies that these networks are „internal“.
# 10.0.0.0 10.255.255.255
# 172.16.0.0 172.31.255.255
# 192.168.0.0 192.168.255.255
192.168.1.102 nfsserver # my NFS server
192.168.1.240 slug1 # my NSLU2

/export/client/root/etc/fstab

$ sudo nano fstab

#/etc/fstab
nfsserver:/client/swap none swap sw,nfsmntpt=/swap
nfsserver:/client/root / nfs rw 0 0

/export/client/root/etc/ifconfig.npe0

$ sudo nano ifconfig.npe0

inet client netmask 255.255.255.0 broadcast 192.168.1.255

/export/client/root/etc/inetd.conf

$ sudo nano inetd.conf

Change the two lines:

#telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a valid
#telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd -a valid

to

telnet stream tcp nowait root /usr/libexec/telnetd telnetd
telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd

/export/client/root/etc/rc.conf

$ sudo nano rc.conf

# $NetBSD: rc.conf,v 1.96 2000/10/14 17:01:29 wiz Exp $
#
# see rc.conf(5) for more information.
#
# Use program=YES to enable program, NO to disable it. program_flags are
# passed to the program on the command line.
#
# Load the defaults in from /etc/defaults/rc.conf (if it’s readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi

# If this is not set to YES, the system will drop into single-user mode.
#
rc_configured=YES
# Add local overrides below
#
sshd=YES
hostname=“slug1″
defaultroute=“192.168.1.1″
nfs_client=YES
auto_ifconfig=NO
net_interfaces=““

/export/client/root/etc/ttys

$ sudo nano ttys

# $NetBSD: ttys,v 1.5 2004/06/20 21:30:27 christos Exp $
#
# from: @(#)ttys 5.1 (Berkeley) 4/17/89
#
# name getty type status comments
#
console „/usr/libexec/getty default“ vt100 on secure
ttyp0 „/usr/libexec/getty Pc“ vt100 off secure
ttyE0 „/usr/libexec/getty Pc“ vt220 off secure
ttyE1 „/usr/libexec/getty Pc“ vt220 off secure
ttyE2 „/usr/libexec/getty Pc“ vt220 off secure
ttyE3 „/usr/libexec/getty Pc“ vt220 off secure
tty00 „/usr/libexec/getty default“ unknown off secure
tty01 „/usr/libexec/getty default“ unknown off secure
tty02 „/usr/libexec/getty default“ unknown off secure
tty03 „/usr/libexec/getty default“ unknown off secure
tty04 „/usr/libexec/getty default“ unknown off secure
tty05 „/usr/libexec/getty default“ unknown off secure
tty06 „/usr/libexec/getty default“ unknown off secure
tty07 „/usr/libexec/getty default“ unknown off secure

Setup the tftp, NFS, and DHCP servers

Now, setup tftp, NFS, and DHCP. On my Fedora 7 system, I use the following setup. Please note that the files shown below are believed to be correct, but if tftp, NFS, or DHCP isn’t working for you, try Googling “ howto”. Also, check your SELinux settings – mine were preventing the slug from attaching to the NFS files. Remember – the kern-NSLU2_ALL.tgz was copied to the NFS server /export/client directory in the previous section. (NB: It wouldn’t be a bad idea for somebody to add the settings required for a NetBSD system here.) As in the previous section, edit or create the files as necessary using nano or your favorite text editor.

$ cd /export/client/root
$ sudo tar –numeric-owner -xvpzf /export/client/releasedir/evbarm/binary/sets/kern-NSLU2_ALL.tgz
$ cp *.bin /tftpboot
$ sudo chmod 666 /tftpboot/*bin

/etc/hosts

192.168.1.240 slug1
192.168.0.1 redboot
192.168.1.102 your_host_name #use your host address

/etc/hosts.allow

in.tftpd: 192.168.0.1
rpcbind: 192.168.1.240
lockd: 192.168.1.240
rquotad: 192.168.1.240
mountd: 192.168.1.240
statd: 192.168.1.240

/etc/xinetd.d/tftp

service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}

/etc/dhcpd.conf

ddns-update-style ad-hoc;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option domain-name-servers xxx.xxx.xxx.xxx; #Use your nameserver address
default-lease-time 2592000;
allow bootp;
allow booting;

#option ip-forwarding false; # No IP forwarding
#option mask-supplier false; # Don’t respond to ICMP Mask req

subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.110 192.168.1.189;
}

group {
next-server 192.168.1.102; # IP address of your TFTP server
option routers 192.168.1.1;
default-lease-time 2592000;
host slug1 {
hardware ethernet 00:18:39:a2:26:7c;
fixed-address 192.168.1.240;
option root-path „/client/root“;
}
}

/etc/exports

/export/client/root 192.168.1.0/255.255.255.0(rw,sync,no_root_squash)
/export/client/swap 192.168.1.0/255.255.255.0(rw,sync,no_root_squash)

Interrupting Slug bootup using telnet

Unless we modify the flash memory of the Slug, the normal boot process is to load RedBoot, wait a few seconds, then load a kernel and memory disk image from flash and execute it. This process can be interrupted if you install a serial port by typing a ^C within two seconds after seeing the following message appear on the serial port screen:

RedBoot(tm) bootstrap and debug environment [ROMRAM]
Red Hat certified release, version 1.92 – built 15:16:07, Feb 3 2004

Platform: IXDP425 Development Platform (XScale)
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x00000000-0x02000000, 0x000723a0-0x01ff3000 available
FLASH: 0x50000000 – 0x50800000, 64 blocks of 0x00020000 bytes each.
== Executing boot script in 2.000 seconds – enter ^C to abort

The good people at www.nslu2-linux.org have also documented a way to do the same thing with telnet. This means you can use telnet to interrupt the boot process and instruct the Slug to load an executable using tftp. Of course, the Slug will still revert back to the serial port as the login console, but the changes we made above will also allow you to login in as root using telnet. Note that this process requires two different telnet sessions, even though they are to the same device (in general, they will use two different IP addresses), since one is to RedBoot and the second will be to NetBSD.

There are several methods described for using telnet to interrupt RedBoot, which you can find at http://www.nslu2-linux.org/wiki/HowTo/TelnetIntoRedBoot. My personal preference is the one near the bottom of the web page entitled “C program using Berkeley Sockets”. Just copy the source code from the web page, paste it into a file (telnet_slug.c) using any editor, and compile. I had to add two header files, string.h and stdlib.h, to get the program to compile using Fedora 8 and gcc 4.1.2. The first three lines in my file look like:

#include <stodio-h>
#include <string.h>
#include <stdlib.h>

Then,

$ gcc telnet_slug.c -o telnet_slug

to compile the program. You also need to set your network configuration so that your computer can respond to the Slug when it starts up with IP address 192.168.0.1. For my Fedora 8 system, I use the following:

$ sudo /sbin/ifconfig eth0:1 inet 192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0

You’ll find other suggestions for other operating systems at the top of the aforementioned web page. Now, run the program before you power on the Slug and you should see:

$ ./telnet_slug
== Executing boot script in 1.950 seconds – enter ^C to abort
Telnet escape character is ‚~‘.
Trying 192.168.0.1…
Connected to 192.168.0.1.
Escape character is ‚~‘.
RedBoot>

What could be easier? Occasionally, the system trying to telnet into RedBoot will be a little too slow, so if you don’t see anything happening after a minute or so, try again. For reference, my Slug with the clock speed-up modification, takes 12 seconds from power on to the RedBoot prompt. Presumably, it will take 24 seconds if you have an older Slug without the modification.

Booting the Slug with NFS

Now, start up the NSLU2 and interrupt the boot process as described above:

$ ./telnet_slug
== Executing boot script in 1.960 seconds – enter ^C to abort
Telnet escape character is ‚~‘.
Trying 192.168.0.1…
Connected to 192.168.0.1.
Escape character is ‚~‘.
RedBoot> ip_address -h 192.168.0.2
IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1
Default server: 192.168.0.2, DNS server IP: 0.0.0.0
RedBoot> load -r -b 0x200000 netbsd-nfs.bin
Using default protocol (TFTP)
Raw file loaded 0x00200000-0x004a2ba7, assumed entry at 0x00200000
RedBoot> g
~

telnet> q
Connection closed.

$ telnet slug1
Trying 192.168.1.240…
Connected to slug1.
Escape character is ‚^]‘.

NetBSD/evbarm (slug1) (ttyp0)

login: root
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 4.99.54 (NSLU2_NFS) #0: Fri Feb 15 23:04:29 EST 2008

Welcome to NetBSD!

This system is running a development snapshot of the NetBSD operating system,
also known as NetBSD-current. It is highly possible for it to contain serious
bugs, regressions, broken features or other problems. Please bear this in mind
and use the system with care.

You are encouraged to test this version as thoroughly as possible. Should you
encounter any problem, please report it back to the development team using the
send-pr(1) utility (requires a working MTA). If yours is not properly set up,
use the web interface at: http://www.NetBSD.org/support/send-pr.html

Thank you for helping us test and improve NetBSD.
We recommend creating a non-root account and using su(1) for root access.
slug1#

The first time I booted the Slug using NFS, it took several minutes to setup up files and such, so be patient.

Using sysinst to install NetBSD onto a USB drive

If you’re new to NetBSD, you might feel more comfortable using the NetBSD installer to set up NetBSD on your USB thumb or hard disk. Everything you need was built during the kernel build steps above. The installer consists of five files; one is the executable and the other four are the installation messages in German, French, Spanish, and Polish. To use the installer, move it to the NFS server used above to boot up the NSLU2 and add the installation directory to the exported NFS directories in /etc/exports on the NFS server. Don’t forget to update the exports list.

$ cd ~/net/src/distrib/evbarm/instkernel/ramdisk/obj/work/
$ scp sysinst* nfsserver:/export/client/
$ sudo nano /etc/exports
$ sudo /usr/sbin/exportfs -ra

NFS server’s /etc/exports:

/export/client 192.168.1.0/255.255.255.0(rw,sync,no_root_squash)
/export/client/root 192.168.1.0/255.255.255.0(rw,sync,no_root_squash)
/export/client/swap 192.168.1.0/255.255.255.0(rw,sync,no_root_squash)

Boot up the slug as before, and mount the newly exported directory.

slug1# mkdir /mnt/inst
slug1# mount -t nfs nfsserver:/export/client /mnt/inst
slug1# ls -la /mnt/inst
total 18064
drwxrwxrwx 6 root wheel 4096 Mar 7 19:41 .
drwxr-xr-x 5 root wheel 4096 Mar 7 19:52 ..
drwxr-xr-x 2 root wheel 4096 Feb 26 21:53 home
drwxr-xr-x 3 500 501 4096 Mar 7 16:03 releasedir
drwxr-xr-x 20 root wheel 4096 Mar 7 16:05 root
-rw——- 1 root wheel 16777216 Feb 28 03:15 swap
-r-xr-xr-x 1 500 501 1571140 Mar 7 19:41 sysinst
-r–r–r– 1 500 501 23994 Mar 7 19:41 sysinstmsgs.de
-r–r–r– 1 500 501 23727 Mar 7 19:41 sysinstmsgs.es
-r–r–r– 1 500 501 23785 Mar 7 19:41 sysinstmsgs.fr
-r–r–r– 1 500 501 21140 Mar 7 19:41 sysinstmsgs.pl
drwxr-xr-x 2 root wheel 4096 Feb 26 21:53 usr

Make sure that NetBSD recognizes your USB drive.

slug1# dmesg | grep sd
sd0 at scsibus0 target 0 lun 0: disk removable
sd0: 3919 MB, 7964 cyl, 16 head, 63 sec, 512 bytes/sect x 8027793 sectors

Change to the directory with the installer and run it. You’ll see the following messages on your telnet terminal.

slug1# cd /mnt/inst
slug1# ./sysinst

Welcome to sysinst, the NetBSD-4.99.55 system installation tool. This menu-driven tool is designed
to help you install NetBSD to a hard disk, or upgrade an existing NetBSD system, with a minimum of work.
[…snip (Select your language preference)…]

+———————————————–+
¦ NetBSD-4.99.55 Install System ¦
¦ ¦
¦ ¦
¦>a: Install NetBSD to hard disk ¦
¦ b: Upgrade NetBSD on a hard disk ¦
¦ c: Re-install sets or install additional sets ¦
¦ d: Reboot the computer ¦
¦ e: Utility menu ¦
¦ x: Exit Install System ¦
+———————————————–+

First, select the utility menu option. From here, set up your network so that the installation program can generate the necessary files in /etc. When done, return to the install system menu and select the „Install NetBSD to hard disk“ option and follow the instructions. When you get to the third menu, select „Custom installation“. Then mark the following items “Yes”:

The following is the list of distribution sets that will be used.

Distribution set Selected
———————— ——–
a: Kernel (ADI_BRH) No
b: Kernel (INTERGRATOR) No
c: Kernel (IQ80310) No
d: Kernel (IQ80321) No
e: Kernel (TEAMASA_NPWR) No
f: Kernel (TS7200) No
g: Base Yes
h: System (/etc) Yes
i: Compiler Tools Yes
j: Games No
k: Online Manual Pages Yes
l: Miscellaneous Yes
m: Test programs Yes
n: Text Processing Tools Yes
o: X11 sets None
>x: Install selected sets

Continue with the normal installation. When asked for the location of the distribution files, select “Local Directory”.

Your disk is now ready for installing the kernel and the distribution sets.
As noted in your INSTALL notes, you have several options. For ftp or nfs,
you must be connected to a network with access to the proper machines.

Sets selected 7, processed 0, Next set base.

+————————-+
¦ Install from ¦
¦ ¦
¦ a: CD-ROM / DVD ¦
¦ b: FTP ¦
¦ c: HTTP ¦
¦ d: NFS ¦
¦ e: Floppy ¦
¦ f: Unmounted fs ¦
¦>g: Local directory ¦
¦ h: Skip set ¦
¦ i: Skip set group ¦
¦ j: Abandon installation ¦
+————————-+

Next screen:

Enter the already-mounted local directory where the distribution is located.
Remember, the directory should contain the .tgz files.

>a: Base directory /mnt/inst/releasedir
b: Set directory /evbarm/binary/sets
x: Continue

Make sure you enter a password for the root user, since we are going to use secure shell to login to the NSLU2. Once the installation is finished, NetBSD checks the file system to see if everything looks OK. Since we didn’t install a kernel to the disk, NetBSD will think that the installation is incomplete. You can ignore the warning message. Exit the installation, which unmounts the USB disk, and remount the disk. Edit the two files below, then reboot the NSLU2.

slug1# mkdir /mnt/d0
slug1# mount /dev/sd0a /mnt/d0
slug1# cd /mnt/d0/etc
slug1# vi rc.conf
slug1# vi ssh/sshd_config
slug1# reboot

Slug’s rc.conf:

# $NetBSD: rc.conf,v 1.96 2000/10/14 17:01:29 wiz Exp $
#
# see rc.conf(5) for more information.
#
# Use program=YES to enable program, NO to disable it. program_flags are
# passed to the program on the command line.
#

# Load the defaults in from /etc/defaults/rc.conf (if it’s readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi

# If this is not set to YES, the system will drop into single-user mode.
#
rc_configured=YES

# Add local overrides below
#
hostname=slug1.
defaultroute=“192.168.1.1″
sshd=YES

Slug’s ssh/sshd_config:

# $NetBSD: sshd_config,v 1.29 2008/01/28 13:57:02 christos Exp $
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

[…snip…]
PermitRootLogin yes
[…snip…]

After rebooting, use the method described above for interrrupting the boot process with telnet, assign the host ip address and use tftp to load the kernel ““’netbsd-sd0.bin““‘, which uses sd0a as the root drive. Remember, this is one of the three kernels we built earlier. You should be able to ssh to your Slug and login as root.

$ ./telnet_slug
== Executing boot script in 1.640 seconds – enter ^C to abort
Telnet escape character is ‚~‘.
Trying 192.168.0.1…
Connected to 192.168.0.1.
Escape character is ‚~‘.
RedBoot> ip_address -h 192.168.0.2
IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1
Default server: 192.168.0.2, DNS server IP: 0.0.0.0
RedBoot> load -r -b 0x200000 netbsd-sd0.bin
Using default protocol (TFTP)
Raw file loaded 0x00200000-0x004a2b9f, assumed entry at 0x00200000
RedBoot> g
~
telnet> q
Connection closed.
$ ssh root@slug1
Password:

Last login: Thu Mar 20 21:51:38 2008 from 192.168.1.105

NetBSD 4.99.55 (NSLU2_ALL) #0: Sat Mar 8 11:33:58 EST 2008

Welcome to NetBSD!

[…snip…]

Terminal type is xterm.

We recommend creating a non-root account and using su(1) for root access.

slug1#

Troubleshooting

Can’t format USB drive with sysinstall

On occasion, I’ve had trouble with sysinst failing to install to the USB drive. The symptom(s) seen most often is the slug hanging up when formatting the disk or untarring the distribution tarballs. I’ve had some success deleting the disklabel for the USB drive and then restarting sysinst. To do this (reference:  To clear the disklabels), exit the install system and enter at the root prompt:

dd if=/dev/zero of=/dev/sd0c bs=8k count=1

Then, restart the installer and try again. Of course, make sure you use the device that corresponds to the USB drive you want to work on.

Build error with some versions of Linux

With certain version of Linux (notably Fedora 7), I get an error that looks like:

checking for i686-pc-linux-gnu-gcc… cc
checking for C compiler default output file name… configure: error: C compiler cannot create executables
See `config.log‘ for more details.
nbgmake: *** [configure-gcc] Error 1

*** Failed target: .build_done
(more error output)

Try defining the following two variables, then follow the build instructions above:

$ export HOST_CC=/usr/bin/gcc
$ export HOST_CXX=/usr/bin/g++

You can find additional suggestions in ~/net/src/BUILDING.

Versions that are known to work

Since, at the time of this writing, you must use -current to get a version of NetBSD that will run on the Slug, you will occasionally find that the kernel doesn’t boot quite right. Don’t complain – that’s what -current is for. Here, we’ll try to keep track of the latest version of NetBSD that is known to build and boot correctly. You can get these versions by changing the CVS command line. To get an older version of NetBSD-current use:

$ export CVS_RSH=“ssh“
$ export CVSROOT=“anoncvs@anoncvs.NetBSD.org:/cvsroot“
$ cd ~/net
$ cvs checkout -D 20080420-UTC src

“’The script build.sh has changed since this article was first written. The following worked on August 23, 2008:“‘

export CVS_RSH=“ssh“
export CVSROOT=“anoncvs@anoncvs.NetBSD.org:/cvsroot“
cvs checkout -D 20080821-UTC src

“’Note:“‘ A checkout date of “20081215-UTC“ built and ran correctly.
“’Note:“‘ There have been some reported problems with the 20081215 build.

Get the NPE code from Intel, as above. Setup the kernel configuration files as above. Then, build as follows:

./build.sh -O ../obj -T ../tools -m evbarm-eb tools
./build.sh -O ../obj -T ../tools -U -u -m evbarm-eb distribution
./build.sh -O ../obj -T ../tools -U -u -m evbarm-eb -V KERNEL_SETS=NSLU2_ALL release

The files you’ll need are now in ~/net/obj/releasedir/evbarm/binary/sets.

Special thx to netbsd.se

written by d45id \\ tags: , , , , ,