Change to a new DB server

1. Tis the day the WORKIT website moved to a new DB server, the shared MySQL server ... so we don't intrude on department MySQL server space. Requires a bit of recoding on my part to get the WORKIT website working with the new server.
   
2. Also, found that users can create duplicate entries with same username - that's a no-no. Need to fix this.
3. The Physics Machine Shop and I played phone tag today - we finally decided to meet on Thursday to finalize the hardware setup for the remaining baseline kits.

The insmod / modprobe hurdle

Today, I hit a brick wall with insmod/modprobe in installing/setting up AODV on the Linux kernel.

I was able to successfully compile the module, including the kernel object files. It appeared that the modpost compilation/linking worked perfectly as well.

However, a problem came up when running the start.sh script provided - it said that it could not find the "kaodv" module, which had been compiled in the current directory.

Perhaps it had not been loaded into memory properly. However, insmod /modprobe failed to find and load the module as well.

Long "voyage": modpost to work and compile

Ah... after weeks of hacking through kernel code and Makefiles, I am finally able to compile and run modpost , for compiling my kernel modules on Voyage Linux 0.4.

This is the story: I need to install some additional kernel modules for the WORKIT project on Voyage. All of the kernel modules pass step 1 of the Makefile, and they compile, but then I get the error:

Building modules, stage 2.
MODPOST 1 modules
/bin/sh: scripts/mod/modpost: No such file or directory

A long search for modpost lead me to find that modpost is used for compiling modules, and is part of the kernel development tools (sorry, missing the link for that post, and couldn't find it again on Google - tells you how exotic this modpost is.)

After a lot more trial and error - which included downloading and trying to recompile the Voyage Linux kernels - I found two posts today that helped immensely in coming to the last step:

• No modpost directory - Linux Forums : helped me realize how to build the modpost (but it was referencing the wrong directory; on my Voyage Linux, the code is at /lib/modules/2.6.20-486-voyage/build)

But I got the exact same error message as in the forum post: unrecognized command line option "-m".

I copied the makefile command, removed the -m directive, and tried compiling again and got a "missing elfconfig.h" error message and other errors dependent on that.

A search for "elfconfig.h" led me to a post of the Linux kernel mailing list about missing elfconfig.h which hints at running "make modules" and "make scripts".

Running those two commands on the /lib/modules/2.6.20-486-voyage/build directory solves the problem - it creates the elfconfig.h (!) file and compiles modpost. (Expect this to take a while - it makes all modules and scripts.)

CCNC BonAHA paper + iptables save

Sorry, been missing a week since I was finishing up my BonAHA paper for CCNC 2009 ... along with finalizing the BonAHA SourceForge website to be ready for the paper submission.

I also discovered that for some reason, my iptables configuration outlined in And Linux is now a wireless AP router doesn't have each time I shutdown or reboot ... which means that I have to reenter it each time.

The usual way I find this out is by trying to connect a laptop to the AP to test it ... only to find that I am not able to access the Internet through it (I get an IP address fine, meaning DHCP works.)

And running "iptables-save" doesn't work either ... so apparently, I have to find another way to save the iptables configuration for the box.

Setting up a Linux AP: Bridge vs. router

Now that I have DHCP and DNS set up, the last thing I need to do is set up the WORKIT box to act as a complete AP by bridging the wireless (LAN) and wired (WAN) connections.

I naively followed linux.com's instructions on setting up a wireless AP by bridging the connections.

I was surprised to see that it completely broke the DHCP/DNS/gateway system I had set up - my wireless client instead picked up the IP address (DNS and DHCP) from the department's regular network. And my "gateway" (the WORKIT AP) had "disappeared", since I was not being assigned an IP address from it and was not on its internal network (10.0.0.x) that I had set up.

What had happened? I finally realized I had set up Linux on the WORKIT AP as a glorified wireless bridge (think switch/hub), not a router!

What I now need to do is set up Linux to act as a gateway, so the WORKIT AP acts completely as a full AP.

A little more search leads to YoLinux's article on setting up a Linux gateway and on Linux Journal as well. Basically, this involves a little fiddling around with iptables...

Installing Kernel AODV for Linux

I attempted to install the "Kernel AODV" kernel module today for the WORKIT AP. Progress was relatively smooth till the last step of the make process, which called "modpost" to create the kernel module.

As expected, there were some issues with my header include files, so had to change the Makefile and include the following lines:

CFLAGS += -I/usr/include/
CFLAGS += -I/usr/include/linux/
CFLAGS += -I/home/linux-2.6.20.1/include

(the last one is the custom directory where I untarred the kernel source.)

In addition, I also had to copy the following files from the kernel source directory:

• irq_regs.h
• device.h
• pda.h

to /usr/include/asm, since the compiler was complaining that they were missing.

After moving all the files, the compilation went smoothly and produced all the .o files; however, it is now stuck at the last step of actually making it a kernel module using "modpost". More information coming soon.

Resolving compile problems with PSU's MAR - include directories and postgresql-dev

Today I attempted to install PSU's Multiple Access Router component for WORKIT. However, I found that I had to set up the include directories in the makefile in order to get the component to compile.

These are the lines I added to the CONFIGURE that is used by the Makefile to get it to work:

CFLAGS += -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include/
CFLAGS += -I/usr/include/c++/4.1.2/
CFLAGS += -I/usr/include/c++/4.1.2/i486-linux-gnu/
CFLAGS += -I/usr/include/linux/

In addition, I also had to install the Postgresql-dev package since it complained of "libpq-fe.h" missing. I installed it using:

apt-get install postgresql-dev

I did have to change one setting that was causing a conflict with the INCLUDE directories for the root Makefile. This file was /dotconf/Makefile, and I commented the following line:

# CFLAGS =

dnsmasq now working as DHCP server as well

Now I have dnsmasq working as a DHCP server as well.

In my configuration, I added the following lines:

dhcp-range=ath0,10.0.0.10,10.0.0.250,24h
dhcp-leasefile=/var/tmp/dnsmasq.leases
dhcp-authoritative
# Gateway
dhcp-option=3,10.0.0.1
# DNS
dhcp-option=6,10.0.0.1

and dnsmasq is now able to serve up DHCP addresses on the fly to clients.

dnsmasq now works for DNS requests - after initial "query refused"

For a long time, I was having a problem where dnsmasq refused to respond to DNS requests and gave an error message "query refused".

At first I thought that it might have been because dnsmasq wasn't running or not binding to the proper port, but after using "netstat -ap" and running "dnsmasq -d", it was obvious that dnsmasq was running and able to receive the queries.

So why wasn't dnsmasq failing to do IP lookups and interact with the upstream DNS servers? Even though from most documentation (such as on Debian and ubuntu.wordpress.com) suggests that a simple apt-get would do the trick?

Anyway, I found that my /etc/resolv.conf had only 127.0.0.1 listed as its nameserver, and dnsmasq was using this as its resolv.conf . I looked around to see if I could find another file that the resolvconf binary was generating that had the actual nameservers, and I found this file: /etc/resolvconf/run/interface/eth0

I change a line in /etc/dnsmasq.conf to read:

resolv-file=/etc/resolvconf/run/interface/eth0

And hey presto, it worked!

Network (eth0) automatically gets IP address using DHCP now

I recently ran into a strange problem with the Voyage/Soekris box, where the box would not get the IP address using DHCP on bootup, even with the network cable plugged in. However, when I manually reset the networking (using ifdown/ifup eth0 or /etc/init.d/networking restart), it would work properly.

This was strange, as it had been working fine all along, and I had the /etc/network/interfaces set up as follows:

auto eth0
iface eth0 inet dhcp

After prolonged searching on the Internet, I found two entries on Ubuntu forums:

• No more automatic dhclient on bootup
• Network not connecting automatically on boot

that helped, but didn't quite work in my case.

I finally added a line to the /etc/network/interfaces file to make it read like this:

auto eth0
iface eth0 inet dhcp
pre-up ifconfig eth0 up

and then, hey presto, the network card now picks up an IP address automatically on boot.

Fixing dnsmasq problems on Soekris/Voyage Linux

(Sorry, my research blogging has been intermittent - but it does affect my documentation, so I am trying to be consistent about it.)

This morning, I needed to look at the DNS and DHCP servers on the Soekris box - somehow, it wasn't working perfectly.

The problem started when I first tried to install dhcpd (the DHCP server) last year without realizing dnsmasq had already been installed - and without knowing what dnsmasq is. After some frustrating error messages and doing some Google searches for dnsmasq and dhcpd, I finally found out more about how they work.

This article gives a good overview of how to set up dnsmasq.

Updates: LightPeers, WORKIT, Spring semester

A few updates since my last blog post, and this is a quick summary:

1. I finally discovered a related work to BonAHA called LightPeers. LightPeers appears to be a PhD dissertation done in Denmark, and the aim of the project is the same: develop a robust application framework for mobile P2P or ad-hoc applications. There are a few differences between BonAHA and LightPeers, but the basic concept is the same.
2. I got the WORKIT MIPClient finally working and able to connect to a wireless AP! Yay! Now to get it connected to the WORKIT AP and test its connectivity to that system.
3. Almost at the end of the Spring semester now. That's good and bad ... because I'll be tied up for the next two weeks with project demos, TA grading and reports ...
   

Photos of Soekris net5501 in Demarctech ODE-8585 Enclosure

At long last, I have photos of the Soekris net5501 in a Demarctech ODE-8585 enclosure.

This Soekris board is currently running Voyage Linux.

Thanks go to George at Columbia Univ's Physics Machine shop for putting this together.

Drill Bushings from McMaster-Carr for WORKIT Soekris

Hi, I'm back after a long while ... decided to continue using my Blogspot account for work related blogs, while the CS@CU wiki can remain as a wiki for official documentation.

Today, I was looking at finding ways of getting washers/bushings to seal off the Demarctech hardware that encloses our Soekris net5501 box. Talking to George at the machine shop indicates that McMaster-Carr would be the best source of such bushings.

I think I am looking for the items under :
Machining and Clamping > Drill Jig Bushings > Drill Bushings and Liners > Drill Bushings for Soft Materials

More to come soon ... as soon as I figure out exactly what I need.