Wrong MAC address - Possible Race Condition

[mgbowman]

Under the advanced tab of my VPN connection, I'm using the following Extra OpenVPN configuration

Code: Select all

lladdr 00:ff:12:34:56:78

This is so the server can tell from the DHCP request that it's is an OpenVPN client (similar to the way tun/tap works on windows). For more details, see my this post on my blog.

Now snooping the traffic on the server side I see the DHCP discovers and offers over and over again until Viscosity finally times out and assigns my client a link-local address (I think this is the behavior of OSX).

Code: Select all

root@server:~# tcpdump -i br0 udp port 67 or udp port 68
08:15:51.399361 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from be:66:8e:57:66:d0 (oui Unknown), length 300
08:15:51.399864 IP server.example.com.bootps > 10.15.1.143.bootpc: BOOTP/DHCP, Reply, length 324

The tap0 device on my mac...

Code: Select all

mac:~ mgbowman$ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   ether 00:ff:12:34:56:78
   inet 169.254.174.226 netmask 0xffff0000 broadcast 169.254.255.255
   open (pid 25800)

Obivously this is due to the MAC address mismatch: 00:ff:12:34:56:78 (the tap interface on my mac) vs be:66:8e:57:66:d0 (the MAC address in the DHCP discovers / offers)

Now the thing is if I quit Viscosity and restart, eventually the MAC address will match and everything works as expected. Hence I think this is a race condition with initializing the tap device and running DHCP on it.

Didn't know if you guys were aware of this (couldn't find anything).

Hope to see this fixed soon!

--mgbowman

Update #1

So I patched tuntaposx as a workaround. Maybe this could be included in Viscosity?

Code: Select all

--- src/tap/tap.cc.orig   2011-11-01 19:31:20.000000000 +0200
+++ src/tap/tap.cc   2012-06-07 09:04:47.000000000 +0300
@@ -94,8 +94,14 @@
    read_random(LLADDR(&lladdr), ETHER_ADDR_LEN);
 
    /* clear multicast bit and set local assignment bit (see IEEE 802) */
+   /* 
    (LLADDR(&lladdr))[0] &= 0xfe;
    (LLADDR(&lladdr))[0] |= 0x02;
+   */
+
+   /* OpenVPN 00:ff:xx:xx:xx:xx MAC address */
+   (LLADDR(&lladdr))[0] = 0x00;
+   (LLADDR(&lladdr))[1] = 0xff;
 
    dprintf("tap: random tap address: %02x:%02x:%02x:%02x:%02x:%02x\n",
          (LLADDR(&lladdr))[0] & 0xff,


Side note: I did set the bundle-id correctly to com.viscosityvpn.Viscosity.tap so that my patched tap.kext unloads when Viscosity exits.

[James]

Hi mgbowman,

Viscosity itself doesn't perform the DHCP back and forth, but rather waits until OpenVPN reports it has successfully changed the MAC address, and then Viscosity enables DHCP on the VPN interface and triggers Mac OS X to start DHCP discovery/negotiation.

I'd be reluctant to make such a patch to the TAP driver, and it will most likely take a lot of sys admins by surprise (many expect the current behaviour). However such a patch shouldn't even be needed if the MAC address changes is taking place correctly.

The only possible way I could see would how this could happen is that OpenVPN is reporting the MAC address change before it has actually taken place, meaning there could indeed be a race condition where Viscosity enables and kicks off DHCP while the old MAC address is still set. We certainly haven't had any other reports of this behaviour, and I haven't observed this, however I can't rule it out.

Is this reproducible for you? I.e. If we were able to include a few safety checks in the latest beta, would you be able to see if they eliminate the issue?

Cheers,
James

[hallelujah]

I have the same behaviour, it is not specific to viscosity, zith tunnelblick I have the same issue.
I already have created an bug ticket to the tuntaposx project.

[James]

Hi hallelujah,

Please see the following post:
viewtopic.php?p=2507#p2507

Cheers,
James