ifconfig's new 'join' parameter

[beavers]

I am loving ifconfig's recently added 'join' parameter in -current, but having a slight bit of trouble using it from my hostname.if file. Of the networks I regularly visit, there's one in particular where I like to use a random MAC.

/etc/hostname.iwn0:

join "Guest_Wireless" lladdr random
join "linksies" wpakey "0123456789abcdef"
join "network not found" wpakey "fedcba9876543210"
join "WNET5" wpakey "Super secret passphrase!"
dhcp
up

However, this randomizes my MAC on _all_ of the networks I join, not just that specific one. (I've also tried changing the order of the join statements, to no effect.) Should I be achieving this some other way?

[jggimi]

The new join option is part of IEEE 802.11 provisioning syntax, which does not include lladdr. You'll have to use a different mechanism -- such as a shell script -- to connect to that network.

[beavers]

Where's a good place to put that so it runs before /etc/netstart?

[jggimi]

Consider: once you alter the MAC address with ifconfig()'s lladdr, the change remains in effect until you reboot or the command is re-issued. You do not want your MAC address randomized if you want repeatable leases on your three standard networks. It should not run before netstart(8).

Run a script to set the MAC address to random, set the SSID, and initiate a DHCP client session when you take your laptop to the untrusted network. Use "join" in hostname.iwn0 only for the three networks where you are able to use the hardware MAC address.

This script can be manually executed, or you could perhaps automate this in an rc.local(8) script, which would be run by rc(8) as a last step, if the script exists. If automated, your script could use ifconfig() to scan for "Guest_Wireless" and if found proceed to issue the appropriate SSID provisioning with ifconfig() and request IP address, routing, and DNS with dhclient(8). If manually executed, it only needs to issue ifconfig and dhclient commands, without any logic.

[beavers]

Originally Posted by jggimi

You do not want your MAC address randomized if you want repeatable leases on your three standard networks.

My only concern is that I don't want the MAC transmitted at all if I'm near that particular untrusted network -- would a (failed) connection attempt from netstart transmit anything during association that contains my real hardware lladdr?

Originally Posted by jggimi

This script can be manually executed, or you could perhaps automate this in an rc.local(8) script, which would be run by rc(8) as a last step, if the script exists. If automated, your script could use ifconfig() to scan for "Guest_Wireless" and if found proceed to issue the appropriate SSID provisioning with ifconfig() and request IP address, routing, and DNS with dhclient(8). If manually executed, it only needs to issue ifconfig and dhclient commands, without any logic.

Such a script is actually what I had been doing before "join" was added, so I've already got a little something ready to go! Will give it a shot from rc.local -- this look reasonable?

#!/bin/ksh

SSID=Guest_Wireless
IF=iwn0

ifconfig ${IF} scan | grep ${SSID} >/dev/null 2>&1
if [ $? -eq 0 ] ; then
        pkill -9 dhclient
        ifconfig ${IF} -inet -nwid -bssid down
        ifconfig ${IF} lladdr random
        ifconfig ${IF} | grep lladdr | awk '{print $2}'
        ifconfig ${IF} nwid ${SSID} up
        dhclient ${IF}
fi

[jggimi]

It looks like a reasonable script when reading it.

I'm not completely aware of all the ins and outs of 802.11 SSID association, but to my understanding the client *will* send out its MAC address in association request frames. This could be in response to SSID beacons, and also -- if my meager understanding is correct -- unsolicited in an association request frame to a "hidden" AP that does not issue beacons. If an unsolicited association request is for an SSID which is not present, no response is returned. But the request can be recorded. Tying a single workstation to multiple sessions (and therefore usage patterns) is the only significant value from "capturing" a MAC address for other than Ethernet connectivity and IP addressing -- that I can think of.

If you don't need repeatable leases from your trusted access points, then feel free to randomize your MAC address in hostname.iwn0, and provision all 4 networks with join, without an access script.

One last option is to develop support for lladdr "restoration" in ifconfig() with -lladdr, which does not exist. Then, you could attempt to update join functionality to add MAC address management options. OpenBSD gets features and functionality from people who believe something is missing, and then develop them, test them, and share them with the community. The tech@ mailing list is the most appropriate place to submit development diffs.

[jggimi]

Originally Posted by jggimi

... a "hidden" AP that does not issue beacons....

I'm wrong. These APs broadcast beacons without named SSIDs.

[beavers]

Well, now something completely unexpected is happening. I've been happily using the above script for the past few weeks, but suddently /etc/netstart is connecting to the guest WAP on its own, despite there being zero mention of it in /etc/hostname.iwn0!!! I removed my own script to confirm, and sure enough it fires right up and connects upon boot. WTF?

[jggimi]

To use join, nwid cannot be set. When not set, I believe it defaults to the empty string, which "...allows the interface to connect to any available access points." And I believe it will, if nothing in the join table matches, and there is an open network within range.

[beavers]

Interesting. Right now I have a single join statement in my hostname.if(5) file, for my home network. So that opens me up to automatically connecting to any open access point?? Or is it simply because at one point I had used a join statement with that open AP?....

ifconfig(8):

join id
             Add the network with NWID/ESSID id to the list of auto-join
             networks.  Information about such networks is retained, such that
             configured interfaces can automatically switch to such networks
             as necessary.

Right now, $ ifconfig iwn0 joinlist only shows the single AP from my hostname.if file.

[TronDD]

The manpage read like:

'join' will only connect to listed networks.

'nwid' with no network id specified will connect to any open network available.

So yes, you probably used a join for that network and it saved the info. You can remove it from the join list.

[jggimi]

The retention noted in the man page is in the active kernel. It doesn't survive shutdown, reboot, or removal with -join.

I noticed this symptom -- attaching to an open network -- myself, yesterday, while using a September 12 -current kernel. An AP had changed at a location I'd been to before, and I had changed the join list to use the new SSID. I misspelled the new SSID, and noticed I had attached to a nearby open network, as nothing in the join list matched. Once corrected, I attached to the proper SSID.

I do not know if this behavior is as-designed or if it is a bug. Since you state this was a recent change in operation, if a bug then perhaps it is a regression.

Edited to add: TronDD jumped in and notes this is not intended behavior, so I expect it is a bug.

[beavers]

I think you're right, this looks like a bug. I'm on a snapshot from the past week or so, and prior to that it worked as expected. If I'm reading it right, setting nwid to an empty string would cause this behavior per ifconfig(8), but having a _null_ nwid (by using join statements instead of nwid) should never cause it to connect to open APs.

[jggimi]

While looking through mailing lists to see if this has already been reported, I discovered a join example that sets the MAC address. It uses a trunk(4) to combine wired and wireless, and sets only the join table in the WifI NIC's hostaname.if(5) file, then sets the MAC address and calls dhclient(8) from the trunk's hostname.if.

https://marc.info/?l=openbsd-misc&m=153601042910538&w=2

If you don't need a static MAC address on any of your networks, I think you could use "lladdr random" in your hostname.if, underneath your join table, and eliminate your rc.local script.

Regarding the possible bug, this is the last commit that mentions nwid. I don't have time to revert and test it, unfortunately. Not for several weeks. All of my "free" time is currently committed.

https://marc.info/?l=openbsd-cvs&m=153652518425431&w=2

[beavers]

Just a quick followup on this, I ended up posting to misc. Turns out that join statements in -current are actively being worked on, and may produce unexpected results at this time. This will not be fixed in 6.4.

https://marc.info/?t=154110546100009&r=1&w=2