I just spotted an email on the FreeBSD Hackers mailing list asking for small open source projects for a few students to partake in. Of more interest was one of the replies. It had a list of url’s for the FreeBSD TODO lists that I hadn’t seen before. So if anyone is looking to contribute to the FreeBSD project in any way this would be a good place to start. There are a number of different areas within which you can participate and the TODO lists are quite a nice way to break things down so people can easily spot areas where their expertise could be useful.

Anyway here is the list of url’s thanks to Joel Dahl over at FreeBSD:

Networking
IPv6
Bsnmp
Jails
USB
SMP

I just had the need to enumerate a list of numbered bullet points in reverse order within a Latex document I am writing. I suppose this is a feature that isn’t hugely needed so it isn’t contained within the standard Latex feature set.

After a little searching I came across this style file which will create the \begin{revnumerate} environment which can be used to easily create a reversely enumerated list. An in depth description of how to use this style can be found here.

After my blog post yesterday regarding ndisc_get_neigh() I have made a little discovery that suddenly makes everything make sense.

I was not previously aware that Ethernet supported Multicast by default. When I think about it now it makes a lot of sense but I had previously ignored the possibility up until now.

Anyway the 33:33:00:00:00:01 MAC address that I was seeing reported and was thinking was garbage is actually a multicast address. IPv6 uses 33:33:xx:yy:zz:kk when sending multicast packets, where xx:yy:zz:kk are the lowest 32 bits of the IPv6 address.

This means that the MAC addresses I was getting were obviously correct all the time and now I understand what is going on I can filter out the Multicast packets and act on them separately. This also has the huge advantage of a kernel patch not now being required as I don’t need to use ndisc_get_neigh() any more. I can simply use skb->dst->neighbour->ha from the sk_buff passed to my code from the NETFILTER hook.

A fairly good set of slides explaining the main points of IPv6 multicast can be found here.

After trying to compile a new kernel in VMware I ran out of disk space and needed to resize the .vmdk disk. It is a fairly simple process and the following command does all the work for you if you:

vmware-vdiskmanager -x 12GB disk.vmdk
Obviously the new size of the disk can be set after the -x argument and the format for this can be found in vmware-diskmanager –help.

After this has been resized you will need to resize the partitions inside the VM. If you have a Linux Live CD to hand you can stick that in and boot up your VM. You need to be pretty quick and click inside the VM to be able to input commands ASAP. When you have done this hit escape in order to set the boot up sequence and tell it to boot from the CDROM.

When your live cd has fully booted load up gparted (or your own preferred choice of partition editors) and grow your main partition into the new free (unallocated) space. In my case I also had to delete the swap partition and move it but this will depend on each individual case.

After that is all done you should be able to reboot your VM with the new larger disk.

I am currently looking at a way to get the MAC address of the next hop of a packet within a kernel module. I had previously made the silly assumption that this should be relatively simple. Of course that turns out not to be the case.

After browsing the kernel source I came across the following function in net/ndisc.h:

static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, const struct in6_addr *addr)
This seemed perfect for what I wanted so I used it and got the following link error:

WARNING: "nd_tbl" [/path/to/source/np++.ko] undefined!
After a little digging I discovered that the list of neighbours (nd_tbl) stored by the kernel is not exported and therefore modules have no way to access it.

Since then I have tried a number of different approches (doing a rt6_lookup() and trying to obtain the MAC through that etc) but none of them have proved successful. The only glimmer of hope was that the sk_buff pointer I was being passed by the netfilter hook displayed the correct MAC address every now and again by using the skb->dst=>neighbour->ha variable. However most of the time it displays 33:33:00:00:00:01 for some reason.

I am going to continue digging around and see why it is not always being displayed properly through the sk_buff (I’m guessing this doesn’t always get properly set for some reason but considering it is 33:33:00:00:00:01 every time this is not a coincidence). If this method yields no results soon howver I think I will be left with the last resort option of having to supply a kernel patch with the NP++ code. This is a real pain as all the kernel patch will do is exprot the nd_tbl struct but it may have to be done.

If anyone knows of a workaround for this without patching the kernel I would love to hear it…

I have been doing some more kernel module coding and have been using the linked list implementation provided by list.h quite a bit recently as I have known in advance that the lists would only ever have a small amount of entries so looping through the list would not prove to be too much of a performance penalty.

For my latest problem however I have a list that could grow a bit larger in size so I made the decision to use a hash table instead of a linked list. I searched through the kernel source naively hoping there would be a neat generic hash table implementation included.. Alas there is not.

After a bit of searching I stumbled across uthash. This is a nice hash table implementation allowing you to basically put any struct into a hash table based on using one of the fields in the struct as the id. The included macro’s allow a string or an int to be used for the id as well which is quite useful.

So far it seems quite simple to use. All the functions are included in one header file wrapped us as macro’s so it is nice and easy to integrate with any project and it doesn’t rely on much to be included externally. In my case all the functions it does need are provided by the kernel so it was very simple to integrate. I will definitely be using this again in other projects in the future.

With a lot of the boxes I set up I write at least one custom script that needs to be run at boot time to configure a bunch of stuff for one reason or another.

The scripts themselves are irrelevant but making sure they run when the machine boots is obviously important.

It is a simple process but I often forget the command so it’s going on here. Create the script you want to run and plonk it into /etc/init.d/.

Now make the script executable.

chmod +x /etc/init.d/script.sh
Now that is done you need to inform the system that you have a new script that you want to be run on startup. On Ubuntu this is done as follows.

update-rc.d script.sh defaults
The defaults argument puts a link to the scripts start procedure at run levels 2, 3, 4 and 5. It also puts a link to the scripts stop procedure at run levels 0, 1 and 6. For more information on how to configure this more finely look at man(8) update-rc.d.