A bit late, but here is the first beta of the Option HSDPA driver for FreeBSD 8. It’s more or less completely rewritten and there are some visible changes to the interface.

Because ucom(4) has matured it can now be utilized instead of mucking around directly with the TTY layer. This results in that the device names in /dev has changed and are now longer called /dev/HSO*, instead they follow the standard ucom names of cuaU*.

The new USB stack attach USB devices per USB interface instead of per USB device, so it’s possible to get both a cuaU0 and cuaU1 device (instead of just cuaU0.0 and cuaU0.1). The number of found serial ports can be read through sysctl.

The packet interface is now exposed as a raw interface instead of emulating an Ethernet device (I seriously wonder why I did that…).

The driver switches automatically from install-cd mode to modem mode, there is no longer any need for manual switching through devd. Please remove the option-icon.conf file from your /usr/local/etc/devd directory.
This can be disabled by setting hw.usb.uhso.auto_switch to 0

And last, I’ve renamed the driver to uhso to reflect its USB nature.

Download: uhso-20091122.tar.gz – Add support for iCON 505, fix probing of devices with dynamic number of interfaces, add new custom attach messages based on the port type.

Download: uhsoctl-beta-20090820.tar.gz – uhsoctl connection utility, similar to old hsoctl

Download: uhso-beta-20090812.tar.gz – Minor bug fix and reworked sysctl nodes.

Download: uhso-beta-20090723.tar.gz – No longer PTP interface (completely useless), fixed (hopefully) CDC notification on modem port, added several new device IDs. Thanks to Iain Hibbert for this!

Download: uhso-beta-20090722.tar.gz – Bug fixes that should improve RX speed.

Download: uhso-beta-20090720.tar.gz

If you own an Option device, please leave a comment (or send a mail) with its full name and USB device ID.

I’m particularly interested in the following devices iCON 031, iCON 210, iCON 315, iCON 322, iCON 401, iCON 431, iCON 451, iCON 452, iCON 505.

If you’re running FreeBSD 8 and own an Option device, please mail me the output of

usbconfig -u X -a Y dump_device_desc
usbconfig -u X -a Y dump_all_config_desc

where X and Y (5 and 2 below) can be obtained through usbconfig

# usbconfig
...
ugen5.2: <Globetrotter HSDPA Modem Option N.V.> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON

This driver has been tested with a Globesurfer iCON 7.2, iCON 255, iCON 505

Quick setup for manual connection
uhsoctl works as before!

Look up the serial ports

# sysctl dev.uhso
dev.uhso.0.netif: uhso0
dev.uhso.0.type: Network/Serial
dev.uhso.0.ports: 2
dev.uhso.0.port.control.tty: cuaU0.0
dev.uhso.0.port.control.desc: Control
dev.uhso.0.port.application.tty: cuaU0.1
dev.uhso.0.port.application.desc: Application
...
dev.uhso.1.type: Serial
dev.uhso.1.ports: 1
dev.uhso.1.port.diagnostic.tty: cuaU1
dev.uhso.1.port.diagnostic.desc: Diagnostic

Open /dev/cuaU0.0 in a terminal application, for example minicom. Issue the following commands to establish a connection.

AT+CPIN="1234" # Your PIN
OK

AT_OWANCALL=1,1,1
OK

AT_OWANDATA=1
_OWANDATA: 1, 95.209.79.126, 0.0.0.0, 80.251.201.177, 80.251.201.178, 0.0.0.0, 0.0.0.0, 72000

If you haven’t configured a PDP context with your providers APN, please see the hso page.

Configure the interface and set a default route

# ifconfig uhso0 95.209.79.126
# route add default -interface uhso0

The most competent console tool for this in FreeBSD is probably Mpd5. It’s quite easy to work with but you’ll need to get all the details right otherwise it just won’t work.

The following mpd.conf configuration file worked for me and allowed me to successfully connect to a Windows VPN. One of the keys were to disable EAP, this particular VPN server just plain refused to work with it enabled

default:
    load vpn
vpn:
    create bundle static B1
    # Create a default route (use a net/mask to create specific routes)
    set iface route default
    # Script to execute on connect (custom routes etc)
    # set iface up-script /usr/local/etc/route-up.sh
    # Accept any IP-address
    set ipcp ranges 0.0.0.0/0 0.0.0.0/0
    # Microsoft Point-to-Point Compression, only enable if you have a really fast machine
    # set bundle enable compression
    set ccp yes mppc
    set mppc yes e40
    set mppc yes e56
    set mppc yes e128
    create link static L1 pptp
    set link action bundle B1
    # Replace with you credentials or use the mpd.secret file
    set auth authname USERNAME
    set auth password SECRET
    set link max-redial 0
    set link mtu 1460
    set link keep-alive 20 75
    # Hostname/IP of the VPN server
    set pptp peer vpn.example.com
    set pptp disable windowing
    set link no eap

Save it to a file, say mpd.conf in /usr/local/etc/mpd.conf and simply run mpd5 mpd.conf and with some luck you’ll be connected the the VPN.

The order of the statements are important. As they only apply to the current selected link (create link) or bundle (create bundle). Keep this in mind when editing.

Windows logon name

If you’re connecting to a Windows network you’ll probably need to use “DOMAIN\\username” as the authname (with the quotes and double backslash).

Firewall and NAT issues

The PPTP protocol is far from ideal. If you’re behind NAT chances are you won’t be able to do multiple PPTP connections to the same VPN server from within your LAN.

You’ll also need to allow the GRE protocol through, with Free/OpenBSD pf (packet filter) the following line is enough (you still won’t be able to do simultaneous connections to the same server though)

pass out on $ext_if proto gre from ($ext_if) to any keep state

Replace $ext_if with your external network interface.

The driver is available for download together with instructions at the hso page. Please report successes and failures.

I was just about to send them another mail when I stumbled on fprint, a GPL based fingerprint abstraction layer that includes reversed engineered drivers for the UPEK devices. The drivers live in user land and the USB bus is accessed through libusb which already is ported to FreeBSD. So, getting a more stable support for fingerprint devices than the binary-only UPEK drivers should only be a matter of porting this library to FreeBSD.

Woho…no more BioAPI-hell (worst. library. ever.). I’m not yet motivated enough to do a port myself, maybe if I get some more free time.

Update: Apparently they did a release, but two people have reported problems with Undefined symbol “GuiCallback”.  I’ll take a look and see if I’m able to use it. At least the beta driver I was given worked, but I never tested it together with the PAM module.

The driver is called hso for now (same name as the linux driver). The card is not a “normal” 3G-modem in the sense that it’s not simply a serial-over-USB card. Instead it has several serial channels that accept the normal AT interface (signal strength, SMS, etc) and in addition to that a IP packet interface to which one reads and writes raw IP packets. The card is exposed through a simulated Ethernet device.

hso0: flags=1088c3<UP,BROADCAST,RUNNING,NOARP,SIMPLEX,MULTICAST,NEEDSGIANT>
   metric 0 mtu 1500
        ether 40:0c:e3:69:11:00
        inet 83.178.12.92 netmask 0xffffffff broadcast 83.178.12.92
        inet6 fe80::420c:e3ff:fe69:1100%hso0 prefixlen 64 scopeid 0x5

Currently it’s a bit annoying to setup a connection as it requires that one first opens a serial channels and issue AT_OWANCALL to create a connection and AT_OWANDATA to get the ip-address and nameservers and then manually configure the interface. It would be nice if this could be automated by the driver with the interface is brought up, however that would require the driver (and thus kernel) itself to read from its own serial channel…bit hackish but maybe it works

Finally, the output from the very first connections. This is a ping from my workstation to the computer connected through the card.

fli@nexus> ping 83.178.12.92
PING 83.178.12.92 (83.178.12.92): 56 data bytes
64 bytes from 83.178.12.92: icmp_seq=0 ttl=56 time=446.203 ms
64 bytes from 83.178.12.92: icmp_seq=1 ttl=56 time=332.321 ms

And this is from the computer connected with the card

fli@genesis> ping ping.sunet.se
PING ping.sunet.se (192.36.125.18): 56 data bytes
64 bytes from 192.36.125.18: icmp_seq=0 ttl=248 time=287.708 ms

I ended up rewriting most of the record database and I think I’ve ironed out most bugs now, and it now follows the variable system (which in turn follows the system state). Here is a sample mdnsd.conf that creates a resource with the name “hostname”.local (where hostname is the actual hostname of the machine), in case this name is already in use, it fall backs to “hostname-ifname”.local. To this rrset it will claim/announce A records for all IPv4 addresses configured on this interface, it also claims/announces AAAA records for all configured IPv6 addresses. It also announces matching PTR records for each A/AAAA record, this introduced a new feature that allows the resource data of a record to be a “pointer” to an existing rrset name. This allows the PTR records to follow whatever name that’s configured on the A/AAAA records.

I also rewrote most of the packet construction. Previously I wrote the raw packets directly when a rrset/qset was added, this however led to problems with the DNS name compression code when records where added “out-of-order”. Therefore, instead of writing the raw packets directly, I introduced an abstract type struct mdns_{rrset,qset} {} which holds the resource data for a record. Basically one acquires a rrset/qset object, fills it with the resource data and adds it to the packet, but instead of writing it to the packet buffer it’s simply added to a list. The raw packets is created from this list first when mdns_pkgchain_finalize() is called, this also has the neat side effect that packet construction becomes quite light weight (and thus, should speed up parsing of received packets as response construction becomes lighter) and the last heavy weight finalize step is moved into the output queue (which will run in a separate thread).

To avoid large malloc()/free() overhead when acquiring rrset/qset objects I also added an “object allocator” which allocates various types of fixed sized objects that the daemon requires, when an used object is released back to the allocator it does not immediately free the used memory, instead it simply puts it on a free list for further use, memory is reclaimed when an object hasn’t been used for a certain amount of time.

There is even more technical mumbo-jumbo (an multicast output aggregation queue, probing/announcing restarts on affected records when system state changes, etc) but let’s see mdnsd in action instead. The daemon is running with the sample configuration file, my FreeBSD machine hostname is “nexus”, let’s demonstrate it with a ping from a Mac OS X machine.

Welcome to Darwin!shiva:~ fli$ ping nexus.local.PING nexus.local (192.168.1.100): 56 data bytes64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=0.285 ms

And, what did mdnsd say

mdnsd: pkgprocess: Packet received peer=192.168.1.98, port=51909, if=em0mdnsd: pkgprocess: type=query, questions=1, answers=0, authority=0mdnsd: process_query: question for nexus.local., type=1, unicast=0, legacy=1mdnsd: process_query: Found nexus.local. in database, responding

and the tcpdump output

12:23:44.049848 IP (tos 0x0, ttl   1, id 16358, offset 0, flags [none],  proto: UDP (17), length: 57)  192.168.1.98.50636 > 224.0.0.251.5353:  38575+ A? nexus.local. (29)12:23:44.050858 IP (tos 0x0, ttl 255, id 59663, offset 0, flags [none],   proto: UDP (17), length: 73) 192.168.1.100.5353 > 192.168.1.98.50636:   38575*- 1/0/0 nexus.local. A 192.168.1.100 (45)12:23:44.051052  IP (tos 0x0, ttl 255, id 59664, offset 0, flags [none],  proto: UDP (17), length: 67) 192.168.1.100.5353 > 224.0.0.251.5353:  0*- [0q] 1/0/0 nexus.local. A 192.168.1.100 (39)

There is two responses, one unicast and one multicast, the unicast response was sent because the client needed it and the multicast response was sent because it was “long” time since we last multicasted this record.

What’s very funny is that Mac OS X doesn’t seem to have integrated their resolver library with their responder, and thus does not benefit from opportunistic caching when simply resolving names, they even do legacy type queries (the term used in the specs). The machine runs Mac OS X 10.4.9.

Darwin shiva.int.shapeshifter.se 8.9.0 Darwin Kernel Version 8.9.0:Thu Feb 22 20:54:07 PST 2007;root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc

I could continue and show some neat tcpdumps from the probe/announce steps, but that would probably only get boring, so let’s call it a post shall we. Now I’m going to continue with the last large piece of the puzzle which is the local client side that actually enables applications to use the daemon.

I’ve finished of several quite large subsystems in mdnsd, including the cache and the record database (which is used for self-claimed records). This means that it’s able to receive and cache records, and able to read self-claimed records off a configuration file and add them to its database.

The configuration file is quite simple, while still being flexible enough to allow more advanced configurations, it’s however a bit different from a regular DNS configuration as the namespace in mDNS is quite flat.
This is a sample that claims a A record, AAAA record and PTR records for each address;

# A zone is only a way to avoid duplicate typing,
# one could have skipped it and simply
# used $(hostname).local. as the rrset.
zone "local." {
# A rrset holds a name and one or more resources, a
# resource type can hold multiple data sets
rrset "$(hostname)" {
alt = "$(hostname)-$(ifname)";
# This is a resource for the IN type A with the data set to $(ifaddrs4)
res A { data = "$(ifaddrs4)"; }
res AAAA { data = "$(ifaddrs6)"; }
}
}
rrset "$(ifaddrs4)" {
res PTR { data = "$(hostname).local."; }
}
rrset "$(ifaddrs6)" {
res PTR { data = "$(hostname).local."; }
}

(It’s supposed to be white spaces in there but they seem to disappear)

This also demonstrates the quite nifty variable systems that is in place. A variable will be expanded to one or more lines of data, this data is context aware, which means that putting $(ifaddr4) as a rrset name will result in a in-addr.arpa-domain while setting $(ifaddr4) as a resource data on a IN resource will encode it into a regular (binary) ip-address.
On our imaginary host foobar with the interface foo0, which has two ipv4 addresses (10.0.0.1, 10.0.0.2) and one ipv6 address (fe80::20a:5eff:fe5c:f5d7), the above configuration would result in the following;

foobar.local. IN A 10.0.0.1
foobar.local. IN A 10.0.0.2
foobar.local. IN AAAA fe80::20a:5eff:fe5c:f5d7
1.0.0.10.in-addr.arpa. IN PTR foobar.local.
2.0.0.10.in-addr.arpa. IN PTR foobar.local.
7.d.5.f.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.a.5.e.f.f.f.e.5.c.f.5.d.7.ip6.arpa. IN PTR foobar.local.

The records will automatically adjust to any changes to the interface configuration.

Any settings that should only be set on a specific interface can be wrapped inside a interface “foo0″ {} statement.
Note how one configuration line expands into several real records.

Next up will be some sort of output queue and routines to send responses (packet construction routines are already in place in the low-level stack).

I’ve been toying and experimenting with different data structures to represent the domain name cache in mdnsd.

These are the structures I’ve seriously considered

• Radix tree/trie – It’s attractive to do lookup in O(k), but with a key length of 255 bytes (utf8) the tree would be huge, 2040 bits. Not sure it would be effective even with all the compression techniques in the book.
• Splay tree (self-balancing binary tree), scales well but key comparisons must be strcmp().
• Hash table, well obviously fast but there could be scaling problems as collisions become lager.
• “Chained” hash table – Use the fact that domain names are separated in labels (label1.label2.tld) and use one hash table on each level.

Very early on I also considered skip lists, but a test showed that it didn’t beat the splay tree, so it got ditched. Radix tree were also ditched as I believe it will be quite hard to make it effective for such large keys.

I measured the performance of the three remaining structures using 1000000 random domain names, the numbers are an average of 10 runs. Code compiled with -O2, tests performed on a Pentium M 1.7Ghz. “add” refers to the time it took to insert 1000000 entries, and “find” refers to the time it took to find those 1000000 entries.

• Splay tree (sys/tree.h), add 4.90300 seconds, find 3.3907 seconds
• “Chained” hash table, add 7.62640 seconds, find 1.38780 seconds
• Hash table, add 2.19680 seconds, find 1.04970 seconds

The reason the chained hash table has such a bad add time is mainly because of malloc() call overhead in the hash table initiation for each level, there is code to reduce malloc overhead (pre-allocating a large chunk and splitting it) but it’s not enough. The hash table is self-growing and will double in size when any bucket hits a threshold number of collisions, experiments showed that up to about 10 collisions per bucket was reasonable. The tests above that included a hash table had a maximum hash table size of 131072 buckets, obviously by increasing the max size (trading memory for speed) you get better performance.

My initial doubts that a hash table would scale bad were not true, 1000000 entries is A LOT more than what the mdnsd responder will ever cache in practice, and because it’s self-growing it won’t waste a lot of memory. I guess I’ll use a hash table then.

The stack provides an abstract interface to the underlying sockets, it takes care of multicast group memberships, buffer management, packet creation and parsing. The interface is the same both for IPv4 and IPv6 which was one of the main requirements. As for DNS names the interface uses wide characters (wchar_t) only and properly encodes/decodes to UTF-8 (just as the specification says), this means that one should be able to use exotic characters natively (such as smörgåsbord.local) without punny-encoding. Oh, and it also does optimal dns name compression in the packets.

All my initial tests shows that the stack itself works well and it’s able to parse all packets my Mac OS X client is sending. I’ve also been running it together with network fuzzer (zzuf) while spewing packets on it, haven’t crashed this far (famous last words) . In addition to this I have a few static test cases I’m going to put it through, which it should support, at least in theory that is. I also plan to run it through gprof to see if there are any dead-obvious sections that could be optimized.

But, all in good time. Now I’m gonna disappear for a while and take care of some school stuff.

There are some initial information about the project on the FreeBSD wiki, I’ll try to keep it updated as time goes. The main priority is to get the responder running and to create a clean client API.

I already have some code, I just need to get the hang of perforce so I can submit it