With Romain Kuntz, I maintain UMIP Linux MIPv6/NEMO daemon. In January 2010, I was provided a SIM card provisioned on an IPv6 APN, which allowed me to add an IPv6 interface to my N900 ;-)
This also gave me some additional incentive to work on the port of UMIP for the N900.
I will not enter the usual details of the port here as it was pretty straightforward on that aspect and you can grab the sources on my N900 repository to look at the content of its 'debian' folder.
But I encountered two specific problems which are IMHO worth mentioning here:
gprs0 interface has a specific type
UMIP has to be aware of the specific type of interface it is configured to use (for instance to know the length of hardware addresses and how to derive interface identifiers).
Anyway, the Nokia N900 gprs0 interface (associated with the PDP Context) was of an unknown type: ARPHRD_PHONET_PIPE (821). Adding support was a matter of 5 additional lines of code.
Note that I decided to consider such interfaces as tunnel interfaces (you need to mark them as Tunnel in UMIP configuration and handle address configuration on your own), even though the GGSN is answering my RS messages with RA ones. The reasons are that
- the PDP Context information is available locally and the associated exchange is performed in all cases by the mobile. There is no need to exchange additional traffic with the GGSN via RS/RA.
- the PDP Context information contains a specific address to be installed on the interface
I took a look at RFC 3316 and even though it is expected that the cellular host will process received RA, it seemed unlikely that Mobile Operator would provide /64 to every client (even though this is what I actually get ;-) ).
I would be happy to discuss the topic if you happen to have more clue.
sb_gcc_wrapper does not handle -isystem
UMIP uses local headers to handle the fact that some system or kernel headers do not contain all the required structures (among other thing):
umip-0.4/src$ ls -R ../include ../include/: libnetlink.h linux netinet ../include/linux: xfrm.h ../include/netinet: icmp6.h in.h ip6.h ip6mh.h packed_icmp6.h
Marking ../include as a directory to be used to search for header files is done in Makefile.am file using the -isystem:
umip-0.4/src$ head Makefile.am ## Process this file with automake to produce Makefile.in AM_CFLAGS = -Wall -Wextra -Wpointer-arith -Wreturn-type -pedantic -std=gnu99 AM_CPPFLAGS = -isystem ../include AM_YFLAGS = -d
GCC -isystem command line option has the associated documentation (GCC 4.4):
-isystem dir Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with "=", then the "=" will be replaced by the sysroot prefix; see --sysroot and -isysroot.
The "special treatment" applied to system header files includes the removal of warning for those headers as there may be specific but valid reason for the use of specific "warning-generating" constructions.
The thing is that -isystem is not transparently handled under Scratchbox environment: sb_gcc_wrapper internally uses -isystem to include system headers and prevent inclusion of local headers (ours from ../include) to happen.
Workaround: I decided to workaround the problem by using -I instead of -isystem in Makefile.am. This results in additional warning but does the job.