Most browsers are quite liberal in what they accept, except for Safari/Konqueror. For some reason it doesn’t like it if a JavaScript file ends in .gz, it ignores the content-encoding and attempts to read the compressed data as JavaScript. The key to make it work is to create a new extension, for example .jgz and set the Content-Encoding for this extension to gzip AND to set the mime type of .js to text/javascript, not text/plain or application/x-javascript.

To recap, call the file script.js.jgz and make sure your webserver delivers it with the following options

Content-Encoding: gzip
Content-Type: text/javascript

Just include the file as usual

<script type="text/javascript" src="script.js.jgz"></script>

This has been tested with the following browsers

• Firefox 3.0/3.5
• Opera 10
• Internet Explorer 7
• Konqueror (webkit based, behaves like Safari)
• Google Chrome 3
• Epiphany

Apache

Put the following in a .htaccess file

AddType text/javascript .js
AddEncoding gzip .jsz

thttpd

Add jsz gzip to mime_encodings.txt and change the type for js in mime_types.txt to js text/javascript.

Update 10 Sep: The patches have been committed upstreams.
Update 9 Sep: working vboxnetadp and patchset sent upstreams.
Update: Re-written to use netgraph, now works on FreeBSD 7 and 8

Patches can be found at

http://www.shapeshifter.se/pub/patches/virtualbox/vbox-freebsd-netif-20090908.patch
http://www.shapeshifter.se/pub/patches/virtualbox/vbox-freebsd-vboxnetadp-20090908.patch
http://www.shapeshifter.se/pub/patches/virtualbox/vbox-freebsd-vboxnetflt-20090908.patch
http://www.shapeshifter.se/pub/patches/virtualbox/Config.kmk-20090908.patch
http://www.shapeshifter.se/pub/patches/virtualbox/src-VBox-HostDrivers-Makefile.kmk-20090908.patch

Additional patches to test with the 3.0.51.r22226 version in FreeBSD ports.

http://www.shapeshifter.se/pub/patches/virtualbox/Config.kmk-r22226-20090908.patch
http://www.shapeshifter.se/pub/patches/virtualbox/virtualbox-port-20090907.patch
http://www.shapeshifter.se/pub/patches/virtualbox/ConsoleImpl2.cpp.patch

Re-install VirtualBox through ports using the following commands

Apply/compile with
cd /usr/ports/emulators/virtualbox
make clean patch
mkdir work/virtualbox-3.0.51r22226/src/VBox/HostDrivers/VBoxNetFlt/freebsd
mkdir work/virtualbox-3.0.51r22226/src/VBox/HostDrivers/VBoxNetAdp/freebsd
patch < virtualbox-port-20090907.patch
patch -d work/virtualbox-3.0.51r22226/Config.kmk-r22226-20090908.patch
patch -d work/virtualbox-3.0.51r22226/ConsoleImpl2.cpp.patch
patch -d work/virtualbox-3.0.51r22226/src-VBox-HostDrivers-Makefile.kmk-20090908.patch
patch -d work/virtualbox-3.0.51r22226/vbox-freebsd-netif-20090908.patch
patch -d work/virtualbox-3.0.51r22226/vbox-freebsd-vboxnetadp-20090908.patch
patch -d work/virtualbox-3.0.51r22226/vbox-freebsd-vboxnetflt-20090908.patch
make install

In VirtualBox network settings, under "Bridged Adapter" you should now see your available network interfaces. Select the one connected to your network and boot your virtual machine. It should now be connected to your local network as any other machine.

Host only adapter mode can be used to create a virtual network with multiple guests, it creates a special vboxnetX adapter on the host. You'll have to do normal routing between this interface to get outside connectivity.

In addition to vboxdrv.ko you'll have to load vboxnetflt.ko and vboxnetadp.ko too.

kldload /boot/modules/vboxnetflt.ko
kldload /boot/modules/vboxnetadp.ko

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

1-wire: is a serial bus from Dallas Semiconductor/Maxim that only requires 1 data line, there are a number of cheap sensors and other devices for this bus. The strength of this bus is not its speed but that it supports large ranges (up to 300 meters).
Also, each 1-wire device has a permanent unique 64-bit serial number.

IPv6: Insanely large address space. It’s common to use a 64-bit netmask for site networks so that EUI-64 based addresses can be used for auto configuration. This leaves 64-bit for the node address – do you see where this is going now… :)

Yes..I’ve built a device that assigned each 1-wire device it’s connected to its own IPv6 address. Why? you ask, mostly because I can.

Hardware

As mentioned above, the device is based on an AVR ATmega644. It has 64KB of flash memory for program code and 4KB of RAM. It’s running on its built-in oscillator at 8MHz. The ENC28J60 Ethernet chip is connected to the AVR using SPI. The rest of the hardware is mostly for power distribution and management.

The PCB was manufactured by BatchPCB, cheap service but a bit slow turn-around time.

Unfortunately I screwed up the SPI connection but I managed to fix that with some green wires (or black wires in this case). You’ll note them in the picture above.
I also intended to run the AVR at 5V and the ethernet chip at 3.3V. This is what the quad AND-gate in the upper right
corner was for, but since I screwed up the SPI routing it’s disconnected and the whole circuit is running at 3.3V.
The ENC28J60 can only run at 3.3V, the AVR has a range from 2.8-5V and 1-wire should be ran at 5V but works at 3.3V. Hence the need for TTL voltage translation.

As for the 1-wire devices I had implemented a bus master in software that generated the require waveforms. It worked great up to about 10-15 meters. Any cable length greater than that refused to work.
This was a bit unexpected and without an oscilloscope it was more or less impossible to figure out where and how the signals got mangled. So I simply got a DS2480 1-wire line driver that generates the required signals in hardware with more precise timing.

Add-on board with a 1-wire master

This required an add-on board and because I didn’t want to wait for a new PCB I used a 2.54mm prototype board. With the DS2480 only available in SOIC8 packages it required some “creative” soldering :).
The DS2480 required 5V, thus It had to get its own power supply and also required level translation on the UART line between this device and the AVR. I choose an approach using MOSFETs and a few resistors for this (the TO92 packages in the picture above). This turned out to work really good and I think I’m going to use this for the SPI level translation in the next revision of the board.
The wire leaving the board on the left side leads to the 1-wire sensor devices.

The add-on board is extremely ugly. But hey, it works.

Future improvements for the next revision

• Use of external crystal at 16MHz instead of internal 8MHz clock.
• Use MOSFETs for 3.3-5 V translation. Need to test it at 16MHz before manufacturing a PCB though.
• Obviously fix all PCB errors :)
• All SMD parts (resistors and voltage regulators) to shrink PCB size even more.
• Better power distribution. I was a bit too conservative with the decoupling capacitors resulting in some weird power problems (fixable with some caps)
• Create a real add-on board

I’ll publish the PCB CAD files when the next revision is complete.

Software

The only small IPv6 stack I know of is the uIPv6 stack in the Contiki operating system created by Adam Dunkel et al. This is unfortunately only available together with Contiki and not as a stand alone package as the originally uIP (IPv4) stack.

Contiki is a great operating system, but when you only have 4KB of RAM it becomes a bit heavy weight. So I broke out the uIPv6 stack from Contiki and made it run stand alone and ported in to AVR. I also ported the web server application from Contiki and made it run on AVR. As I wanted to use multiple IPv6 addresses I also had to add support for IP aliases to the uIPv6 stack.

Since the uIPv6 was integrated with Contiki it used the Contiki process model which it self is based on “proto-threads” (another thing invented by Adam Dunkel). I felt that this didn’t fit so I turned all processes into a polling mode instead. So one has to call a set of polling functions from the main application loop or from timers.

The other major parts of the code are drivers for ENC28J60, DS2480 and DS1820.

Software

1-wire devices

30 second polling interval with auto-discovery of new devices.
Each device is assigned its own IPv6 address, requires a /64 network to be available.

Webserver

Integrated web server makes it possible to visit each address. An XML file with the latest sensor reading is returned. An “age timestamp” is also provided which makes it possible to determine how old the reading is.

Currently, with 5 1-wire devices connected it uses about 3KB of RAM.

• Source code
• uIPv6 port

In-action

I only have temperature sensors connected at the moment. If you happen to have an IPv6 capable connection you can access the sensors through a web browser.

2001:16d8:ffe5:002:2894:eaf6:100:0c7
2001:16d8:ffe5:002:28c1:b4f6:100:035
2001:16d8:ffe5:002:2809:aef6:100:0ca
2001:16d8:ffe5:002:28c5:a5f6:100:058
2001:16d8:ffe5:002:2813:caf6:100:050

(If you don’t have IPv6 you should get it, or you can view graphs based on the sensor values at lindberg.tl instead).

Carefully crack the case open using a knife. You can be quite rough at the PS/2 end of the casing as this part will be
removed anyway. Don’t destroy the USB side of the casing as this part will be reused for our adapter casing later on.

Once opened you should basically have a USB-connector connected to a PS/2 connector covered in hot glue/plastic wrapped in a thin-foil like material (for shielding). Remove the wrapping and cut away the PS/2 connector with a knife.

Now, carefully remove the remaining plastic. Don’t worry about the soldered wires but make sure that you don’t damage the pins on the USB connector. You should end up with something like this.

Do the same with another USB-PS/2 adapter so that you basically end up with two USB connectors.
Bring out your soldering iron and de-solder the remaining wires from the connectors.

Place the connectors back-to-back and turn one of them 180 degrees so that it becomes “up-side-down”. If you don’t do this you’ll end up connecting the pins in the wrong way.
To make the pins touch each other you’ll have to bend them roughly 30-45 degrees. Solder the pins together.

Cut out a piece of wire and solder it to the casing off each connector. You can use the existing solder points used for the shielding/ground or create a new. Some flux will help a lot here.

That’s it for the connector. Next up is to creating a new casing using the existing casings. Unfortunately I forgot to take pictures of this process.
Take on pair of the two cases, take one of the two pieces and place the USB-USB adapter inside it . Make a mark on the casing approximately in the middle of where the soldered pins meet.
Cut at this point and do the same for the same half of the other case. Just do a rough cut and file the pieces until the adapter fits. Once the bottom fits, do the same for the top part using the bottom pieces as a template.

Place it in the new casing and pour some hot glue over it to make it steady. Glue the top on and it’s complete.

USB-USB female adapter in action.

Will it be as good as a commercial adapter? probably not. Will it effect data transmission? probably (depending on how good the solder joints are). Cheaper than a commercial adapter? yep (assuming you already have the parts needed and don’t factor in the labor :))

The system clock is based around a 32kHz clock crystal and one of the 8-bit timers provided by the AVR, it is possible to use the CPU frequency as a timer base as long as it’s a nice, dividable, frequency.
To be able to provide a stable 1 Hz clock but still have sub-second precision we divide 1 second into an arbitrary number of
system ticks. To minimize CPU usage the tick counter should be increased at each interrupt, this means that the number of
ticks per second we we choose determines our interrupt frequency and timer resolution.
How to choose number of ticks? It all depends on your required resolution, if you only want a 1 second resolution a tick and a second becomes equal.

The AVR timer is a 8-bit register that simply counts at the rate of its clock source. The clock source can be either the CPU
clock or an external oscillator, the clock source is also subject to a prescaler to further decrease the frequency.
The timer then generates an interrupt on overflow and/or when it hits a pre-configured value.
Since its a 8-bit timer, we have a maximum of 256 cycles before an interrupt is generated, a smaller interval can be achieved by using the comparator match to generate an interrupt at a specific value.

This example is creating a 1/32 second resolution timer (32 ticks per second) using an external 32768 Hz watch crystal.
comp is the comparator value, to avoid re-arming it with different values it should be limited to 128 or 256, otherwise it has to be changed at each interrupt.

The following to equations can be used to calculate either comp or the prescale value.
prescale is limited by the target device, but common values are powers of 2 (8,32,64,128,256,1024).

Using 128 as the comp value and inserting the other values into equation 2 yields the following prescaler

So, a prescaler of 8 gives us two interrupts per 256 cycles, one at 128 and one at 256 (overflow). Using 256 as comp would yield a perscaler of 4 but the target device I used didn’t have a TS/4 prescaler.

Complete source code for a 1/32 (or 31.25ms) second resolution timer for the ATmegaxx4 using Timer 2 and a 32kHz watch crystal connected to the pins TOSC1 and TOSC2.
Requires AVR libc.

#include <avr/io.h>
#include <avr/interrupt.h>
 
typedef uint32_t clock_time_t;
static clock_time_t global_system_ticks = 0;
 
/* ISR for the timer overflow */
ISR(TIMER2_OVF_vect)
{
    global_system_ticks++;
}
 
/* ISR for the comparator */
ISR(TIMER2_COMPA_vect)
{
    global_system_ticks++;
}
 
/* Return number of elapsed ticks */
clock_time_t clock_time()
{
    return (global_system_ticks);
}
 
/* Return number of elapsed seconds */
unsigned long clock_seconds(void)
{
    uint32_t tmp;
 
    TIMSK2 &= ~(1 << OCIE2A) | (1 << TOIE2);
    tmp = global_system_ticks / 32;
    TIMSK2 |= (1 << OCIE2A) | (1 << TOIE2);
    return (tmp);
}
 
void clock_init()
{
 
    /* Enable external oscillator (32 kHz crystal) connected to TOSC{1,2} */
    ASSR |= (1 << AS2);
 
    /* Reset timer */
    TCNT2 = 0;
 
    /* Set TS/8 prescaler, results in a 4096Hz clock */
    TCCR2B |= (1 << CS21);
 
    /* Compare at half counter value */
    OCR2A = 128;
 
    /*
     * Enable overflow and compare interrupt.
     * Triggers each 1/32 secs
     */
    TIMSK2 |= (1 << OCIE2A) | (1 << TOIE2);
}

Here is an Eagle PCB footprint I created for the MagJack (MJF13T36L-KF06B3GY-0808) from MoreThanAll sold by Sparkfun.

This one has been proven in production and it works, however you should double- (and triple-) check pin-outs and footprint of your device before sending a PCB for manufacturing using this part. Use at your own risk.

Magjack schematic

Magjack footprint

Download

morethanall_magjack.lbr

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.

I’ve been running DSPAM for a long time and the spam classification is great, unfortunately the maintenance tools are not as it turns out. This is the tale of why and more especially HOW I moved from the hash driver to the mysql driver as a backend for my DSPAM installation.

It all began a few days ago when the dovecot-antispam plugin all of a sudden refused to re-classify mails. This was all very weird because I was possible to re-classify mails from the command line, but the same mail/signature failed from the plugin.

After some debugging and messing with the plugin code I established that it successfully called dspam to re-classify the mail but dspam failed. Hm, maybe a permission problem then…nope. Same command with same permissions worked from the command line.

At this point I was really puzzled (and quite annoyed), the error made no sense. So I hacked the plugin to call dspam using a system call tracer (in this case truss which is shipped with FreeBSD) to produce a call trace of the dspam processes within the context of the plugin.

After comparing the outputs from a working case and a non-working case, one line stood out.

mmap(0×0,263332768,PROT_READ|PROT_WRITE,MAP_SHARED,4,0×0) ERR#12 ‘Cannot allocate memory’

For those who don’t speak truss. This means that the mmap() system call (map a content of file into memory) failed because of an out of memory condition.

WHY!? Well it obviously hit a built-in mmap limit as the system had a lot of free memory. It was not vm.max_proc_mmap (tried bumping it, didn’t work). vm.kmem_size_max is large (64-bit system) and the uid had unlimited resources (ulimit). I’m still puzzled by this.

As the title reveals I’m running DSPAM with the hash driver, why? mostly because it was the default back-end driver in DSPAM when I installed it (and I was young and naive).

Wonder why it hit the limit in the first place, a quick look in /var/db/dspam/data reveals that the hash database with tokens for this particular user had grown to ~250MB.

Why so big? DSPAM comes with a cleaning utility called dspam_clean to clean out unused data, I’ve been running this nightly to keep stuff neat and tidy. Well, here comes the fun part.

It turns out that dspam_clean doesn’t actually do anything when you’re running the hash driver, it just looks like its working and takes ages to execute. There is no mentioning of this in any user documentation I found. With the hash driver you’re supposed to run cssclean…only that this program doesn’t work either – unless you patch it. I found a patch dubbed “cssclean is a redheaded stepchild” sent to the (now defunct, and moved to sourceforge) dspam-dev@ list at nuclearelephant.com that took care of this. The patch missed an include (at least on FreeBSD) that caused it to crash on 64-bit platforms (64/32-bit pointer truncation). The whole patch is included at the bottom of the page.

To summarize it, the maintenance tools are virtually non-existing when using the hash driver.

Probably a good opportunity to convert to the mysql driver instead (as I’ve been meaning to do for the last year or so).

Converting from the hash driver to mysql

There is a tool included with the DSPAM package called dspam_2sql, but of course this didn’t work properly either. Most important, it didn’t work with virtual users and just refused to run. Also timestamps on token data were ignored. I’ve hacked together a patch to fix theses issues, it’s available at the bottom of the page.

I first attempted to import non-cleaned data into the SQL database…big mistake. I aborted the progress when the token table had about 8 million entries (and weren’t even done with 1 user).

Quick recipe on how to do the conversion

First

• Grab the source package for dspam-3.8.0
• Download the patches at the bottom of this page

Patch and compile the sources

tar xzf dspam-3.8.0.tar.gz
cd dspam-3.8.0
patch -p1 < dspam_cssclean.patch
patch -p1 < dspam_2sql_virtuser.patch
cd src
make

The patched cssclean tools can be found in tools.hash_drv

Run tools.hash_drv/cssclean on all users (or users that receive a lot of mail). Backup your database (/var/db/dspam) first.

Example

tools.hash_drv/cssclean /var/db/dspam/user@domain.tld/user@domain.tld.css

You can check the number of entries with cssstat

Create a MySQL database and user for dspam, I’ve called mine dspam. The table defintions can be found in tools.mysql_drv

mysql -D dspam -u dspam -p < tools.mysql_drv/mysql_objects-speed.sql
mysql -D dspam -u dspam -p < tools.mysql_drv/virtual_users.sql

You should now have a database with tables and a cleaned hash database, the only thing left is to convert it. dspam_2sql will output SQL statements, just feed these into MySQL.

For example, the conversion can be done like this

tools/dspam_2sql | mysql -D dspam -u dspam -p

Beaware that it probably will take a lot of time.

You can convert one single user with

dspam_2sql –user=user@domain.tld

That’s it. Modify your dspam.conf to use the MySQL driver and restart dspam.

Performance

The MySQL driver IS slower than the hash driver. The processing time for a message with the hash driver was around 0.1-0.2 seconds on this hardware. The MySQL driver takes between 0.2-2 seconds for a message.

The slowdown is not a problem for me. Things like real database consistency (some of my users had duplicated tokens with the hash driver), better maintenance tools, easier manipulation of the data (and the benefits of my MySQL replication+backup configuration) makes it well worth it.

Patches

• dspam_cssclean – cssclean patch found on mailing list. Posted by Frank Cusack.
• dspam_2sql_virtuser – dspam_2sql patchset. Virtual user support etc.

The “Authenticated sender” is added when a user has been authenticated by the MTA through SASL and the directive smtpd_sasl_authenticated_header have been set to yes.  The header_checks directive takes a file containing a regular expression which rewrites the header data and removes sensitive information.

This all works well – with IPv4. The regular expression posted on the pages mentioned above does not take IPv6 addresses into account, I modified it slightly to accept both IPv4 and IPv6 addresses.

/^Received: from (.* \(\[?[-._[:alnum:]]+\]? \[([\.0-9]{7,15}|IPv6[\:a-fA-F0-9]+)\]\))(.*)
\(Authenticated sender: ([^)]+)\)(.*)(by mx1\.example\.com) \(([^)]+)\) with (E?SMTPS?A?) id
 ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.example.com (smtp-auth.example.com
 [127.0.0.1]) (Authenticated sender: hidden)$5$6 ($7) with $8 id $9 $10

Note that this should be one single line.

Put this in a file, for example /usr/local/etc/postfix/obscure_smtp_auth and add the following to your Postfix configuration (assuming you have SASL working).

header_checks = pcre:/usr/local/etc/postfix/obscure_smtp_auth
smtpd_sasl_authenticated_header = yes

The first header will now be rewritten, for both IPv4 and IPv6 clients and will look something like this.

Received: from smtp-auth.example.com (smtp-auth.example.com [127.0.0.1]) 127.0.0.1 (Authenticated sender: hidden)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for &lthostmaster@example.se>; Wed, 10 Dec 2008 16:31:51 +0100 (CET)

instead of

Received: from [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx:fedd:7914] (unknown [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx::fedd:7914])
	(Authenticated sender: someuser@example.com)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for  &lthostmaster@example.se>;  Wed, 10 Dec 2008 16:31:51 +0100 (CET)