First: Make sure the complete build environment comes from within one source. For example from MacPorts. You will need following packages:

• arm-elf-binutils
• arm-elf-gcc
• automake
• autoconf

Second: Make sure your $PATH variable includes the executable of your build environment. For MacPorts this is usually /opt/local/bin. The path for MacPorts executables should be before the path of the native Mac OS X executables to make sure MacPorts executables are used:
mort:osmocon martin$ echo $PATH
/Library/Frameworks/Python.framework/Versions/2.7/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin


Thats it. You now should be ready to compile your osmocom.

To get started with the RAVEN Kit and Contiki I had to install a new firmware on theRZUSBstick and the AVR Raven. Basically both devices are intended to be programmed using their JTAG interface. But JTAG programmer are rather expensive and I do not own a JTAG programmer, therefore I had to use the devices ISP port. You need an ISP programmer you can hook up your PC – I use the myAVR MK2 programmer, but in general you can use any other JTAG programmer that is compatible with avrdude.

The Raven has soldering points for ISP, unfortunately the RZUSBstick has not. You can find a quite good post by Michal Ossmann that explains how to connect ISP to the RZUSB – you basically have to soldier some wires directly onto the pins of the microcontroller. This is tricky, advanced soldering skills are required.

As soon a you finish soldering you can hook up the wires to your ISP. I downloaded the binary release of Contiki to flash it on the devices. The firmware is in ELF format which contains both, EEPROM and FLASH of the firmware in one file. Avrdude does not support this format, therefore the ELF file must be split into EEPROM part and the FLASH part as explained on gonium.net. For example the ravenlcd firmware:

# export NAME=ravenlcd_3290
# avr-objcopy -R .eeprom -R .fuse -R .signature -O ihex $NAME.elf $NAME.hex
# avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $NAME.elf $NAME.eep

After that you can use avrdude to flash the FLASH part and the EEPROM part separately:

# avrdude -p m3290p -c avr911 -P /dev/ttyUSB0 -U flash:w:ravenlcd_3290.hex -B10
# avrdude -p m3290p -c avr911 -P /dev/ttyUSB0 -U eeprom:w:ravenlcd_3290.eep -B10


You have to repeat these steps for webserver6.elf and ravenusbstick.elf.

For setting up your IPv6 network interface and radvd on the host the RZUSB is connected you can follow the tutorial on the Contiki Webpage.

If everything works it should look like this: Pinging AVR Raven!!

Till now I didn’t had the time to take a closer look on this. Anyway for unbricking your dongles have a look at this post. I used the SPI interface and a Bluetooth Casira Development board to unbrick the dongle. Unfortunately you need the quite expense develpment board and the software to fix the dongle, but in theory it should be possible to fix this with homebrew software and hardware.

If a have some free time during the next month I will take a closer look on this topic.

See you next weekend!

Basically you just have to configure your interface on your PC to have the IP-Address 192.168.1.2 (or any other address within 192.168.1.0/24) and then you either can access the Viking’s HTTP or telnet server via 192.168.1.1.

With the web interface running on the HTTP server you can configure basic things like switching your bridging modem into a router. The basic configurations options you have for every DSL router. Anyway more interesting is the telnet interface. With the help of it you can get many more informations about your DSL connection. I found a preliminary command reference for the Viking chip set family which seems to contains many commands you can use to get some more informations out of your modem/router/bridge.


martin@kovalski:~$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

UpIntrlvd UpFast DownIntrlvd DownFast
AS0(kbps): - - - -
AS1(kbps): - - - -
LS0(kbps): - - - -
LS1(kbps): - - - -
RValue : - - - -
$


Anyway… now that you are able to get some informations out of your DSL modem/router. I actually like my OpenWrt based router…. damn…

…. writing this I just realized that this whole problem might not be related to my broadband provide – you remember, I just wanted to figure out why my connection was so slow before I tried to mess around with my modem – but to the not configured QOS settings of my so beloved OpenWrt router. Before I went to Dortmund my router got a little software update. Check, confirmed. QOS disabled.

… now that I have my whole bandwidth back… what was the point… right: I love my OpenWrt router. So I like to keep the bridge configuration but want to be able to access the DSL modem/router/bridge from within my local network behind my OpenWrt router. Therefore I have to adjust the firewall configuration a little. First make sure, that your modem and your router are not in the same subnet. I decided to configure my router to be 192.168.2.1/24 and the modem to stay as 192.168.1.1/24.

Now, the adjustment of the router’s firewall:


martin@kovalski:~$ ssh root@192.168.2.1
root@192.168.2.1's password:

_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (7.09) -----------------------------------
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
---------------------------------------------------
root@SRB178:~# ifconfig eth0.1 192.168.1.2 up
root@SRB178:~# iptables -t nat -A postrouting_rule -o eth0.1 -d 192.168.1.1/24 -j MASQUERADE
root@SRB178:~# iptables -A forwarding_rule -i br-lan -o eth0.1 -p tcp --dport 80 -d 192.168.1.1 -j ACCEPT
root@SRB178:~# iptables -A forwarding_rule -i br-lan -o eth0.1 -p tcp --dport 23 -d 192.168.1.1 -j ACCEPT


First configure your WAN interface. Then the firewall: The first rule is to masquerade the traffic from 192.168.2.0/24 as 192.168.1.2. The modem/router does not know anything about the 192.168.2.0/24 network. It will receive the requests out of the network but does not know where to send them back.
The other two rules are to allow the forwarding of traffic from the internal network to the modem/router on port 80 (http) and 23 (telnet).

If you want to get the informations easier than manually telnet into the modem and send the commands you can also use the fancy DSL-Modem Tool. There are several versions of this tool for different modems, but basically they all seem to use telnet to gather the informations.

By the way, the user name and password for accessing my modem were:
User: alice@13184 password: hnto$mgmt@lice
This is the default configuration of my broadband provider Alice.

kthxbye.

A little device with the size of a lighter which you plug into a cellular phone and sucks out all it’s user data. Right now, it only supports Samsung and Motorola phones, but I think it should be no problem to support other cellular phone brands like Nokia oder Sony Ericsson.