natd stopped working after Software Updates: Bogus VLAN injections?

Software Update installed three packages on the iMac today:

Safari 3.1 Update (Universal)
Security Update 2008-002 (Universal)
AirPort Extreme Update 2008-001

This machine (running 10.4.11, fully updated now) is my connection-sharing gateway the internet for my wife's MacBook, a Linux box and a TiVo unit.

Comcast ==(ethernet)== public-IP iMac ==(wireless)== private IP MacBook, Linux, TiVo

I ran my usual firewall + Internet sharing script after the mandatory reboot.
The iMac's broadband connection worked fine for local programs (Safari, ssh) but none of the machines with private IP addresses on the LAN could see the outside world. The machines on the home LAN could see each other fine -- ping, ssh, etc. Time to start testing!

When I pinged an external machine from the Linux machine, the DNS lookup succeeded after a delay, but it seemed that no ICMP responses came back. Actually, packet tracing with Wireshark showed that the responses had come in with an extra four-byte header field I had not seen before: something called "802.1Q Virtual Lan" inserted between the Ethernet II header and the Internet Protocol header. Sample packet dump (slightly edited):

--
No.: 20
Time: 00:04:56.746703
Source: 64.233.187.99
Destination: 192.168.1.2
Protocol: ICMP
Info: Echo (ping) reply

Frame 20 (102 bytes on wire, 102 bytes captured)
Ethernet II, Src: AppleCom_54:1b:30 (00:17:f2:54:1b:30), Dst: FirstInt_94:75:8f (00:40:ca:94:75:8f)
*802.1Q Virtual LAN*
*001. .... .... .... = Priority: 1*
*...0 .... .... .... = CFI: 0*
*.... 0000 0000 0000 = ID: 0*
*Type: IP (0x0800)*
Internet Protocol, Src: 64.233.187.99 (64.233.187.99), Dst: 192.168.1.2 (192.168.1.2)
Internet Control Message Protocol
--

Looking further back in the trace, it turned out that the DNS delay had the same oddity. The Linux machine sent out a request to the primary DNS server, got back an immediate response with the extra "802.1Q" field, waited 5 seconds, sent out a DNS request to the secondary server, got an immediate normal response (without "802.1Q"), then immediately used the returned numeric address for the pings. It's as if the Linux machine ignored the packet with the extra, interposed header.

I traced HTTP traffic to google.com and saw a similar pattern:
1. bogus 1st DNS response
2. delay
3. good second DNS response
4. sent HTTP SYN packet
5. got back HTTP SYN/ACK with extra "802.1Q" field
6. multiple retries of steps 4 and 5.

I suspect that one or more of the software updates is inserting this VLAN stuff into NAT-ed packets over Airport. The receiving machines drop the packets because they expect the Ethernet II header to be followed by the IP header, not 802.1Q data.

An old discussion thread ([VOIP VLAN using 802.1q frames causing massive dropped packets|http://discussions.apple.com/thread.jspa?threadID=378673#1833386]) talked about a similar problem.

Here are the NAT-related commands from my firewall script:
natd -u -dynamic -interface en0
/sbin/ipfw add divert natd all from not me to any via en0
sysctl -w net.inet.ip.forwarding=1

Question: is there a known workaround to get the MacOSX network drivers not to insert 802.1Q VLAN headers?
Thanks in advance!
--GCL