Hardware's hard facts

We just bought some toys to do a Tamias test deployment. We started small with just 15 nodes made of :

• A Barebone chassis that has motherboard, CPU, chipset and loads of integrated stuff we won't use : the Shuttle XS36V
• A 1TB 2.5" hard disk from Samsung
• A 2GB RAM stick from Elixir (unrelated to the card game, for you french readers)

Now, the law of large numbers predicts that for millions of hardware pieces, a few of them will be faulty. I was really interested to see how lucky we would be with the Tamias hardware, and here is the result for the case of not so large numbers :

Part	Qty bought	Qty faulty	Remark
Shuttle XS36V	15	2	Won't boot from USB key, but installs from USB CD
Samsung 1TB HDD	15	0	so far so good
Elixir 2GB RAM	15	2	1 won't P.O.S.T., 1 fails during Debian install

So that's it, 13% failure for RAM. I was expecting 1 failure and hoping for zero... The motherboard could be rated at 0% failure because it actually works, but we had to boot from a USB CD. I would have to check if the BIOS release is the same as the other 13 pieces, but since we got it to work, we decided not to RMA them. Memory was RMAd and replaced swiftly, Memtest86 (using debian memtest86+ packages) has passed so we expect no problems here either...

FTDI USB driver woes on Debian LiveCD

Just a quick info that might be useful for some of you Xbee users. I wrote this little software to visualize and plot Xbee accelerometer data a while back.

Now, my brother tried to use it, and since he is not into Linux at the moment, I prepared a LiveCD for him using the Debian Live project. The reason why I did that is because the python program needs wxpython which is not included in the default Debian LiveCD.

The problem is that the kernel currently used (at the time of build: started Mon, 05 Mar 2012 20:21:01 -0600 and ended Mon, 05 Mar 2012 20:52:50 -0600) includes a buggy driver for the FTDI USB kernel driver. Details about the bug can be found here :
http://comments.gmane.org/gmane.linux.usb.general/44150

and changes needed to any python software (including my own xviz) that wants to work around this bug, so that you don't need to replace the kernel or rebuild the liveCD, are to look for a line like this:

 self._port = serial.Serial(self._comport, 9600)

and add a rtscts= parameter like this:

 self._port = serial.Serial(self._comport, 9600, rtscts=1)

This tells the driver to open the serial port using RTS/CTS flow control, which actually disables it, because the driver inverts both states, duh.

Debian, IPv6 and ... Java ?

Today is the first time for me to talk about Debian. It has been my favorite Linux flavor for quite some time now. I would say at least ten years, when compiling stuff became less fun and more painful, or my spare time ran out. I don't know exactly.

But whatever the cause, I ditched compiling everything in favor of the flexibility (and frustrating nature at times) of a packaging system. At that time, RPM did not prove better than Slackware's plain .tar.gz packaging and although dselect could be stubborn at times, it soon got better with apt-get and friends.

Let's add IPv6 to this landscape.

Howto get a list of network interfaces in Linux, part 3

Here we are, this is the ultimate post from these series. Thanks both previous posts, we are now able to get a list of interfaces using any language from shell script to whatever language which can speak ''sockets''.

However, as we could realize earlier, the ioctl-based method does not work exactly the way we want, because it does only report IP enabled devices. So if you want to deal with network interfaces before they start running, you are stuck with the /proc method. There must be another way. Remember that man netdevice we did last week. They mentioned netlink... What are those ?

Netlink sockets are sockets from the AF_NETLINK family. Being sockets, they are used to communicate between two addresses. The fun part is, netlink communications are local. And they usually (in the most simple scenario) link a user process with the kernel, especially the networking stack of the kernel.

Howto get a list of network interfaces in Linux, part 2

Welcome back, networkers !

Now, we are able to loop over all network interfaces within a shell script. How about we do it in C ? Let's make a first attempt using syscalls, shall we ? The alert reader already guessed that like all major things, there will be three parts (talking about major things, Google suggests me that there are three little pigs, stooges, musketeers. But Rs beat them all with 3 billion hits, what an ignorant fool I was, to not even know about RRR).

So, whenever it comes to system and kernel stuff, system calls are your friends, and thus we naturally turn to ioctl and friends, in order to find out more about the network interfaces. A quick "man ioctl"  reveals that there is a manual page that knows them all ioctls. So, let's summon it right away by doing "man ioctl_list".  Now that you have it in front of your eyes in it's full glory, you will just trust me and use SIOCGIFCONF to know about network interfaces. Because that manual page was rather obscure, wasn't it ?

Howto get a list of network interfaces in Linux, part 1

Hi folks,

Today we are going to become a little bit more technical. Some of you might wonder how to get a list of the network interfaces. For our first part, we are going to consider the shell script case.

Little disclaimer first, I am not an expert at shell-scripts at all, my abilities are limited to understanding the random scripts I encounter during my daily use of Linux on my computers, and writing the occasional script that saves some time when having to automate some boring tasks (converting a few gigs of  videos is boring).