One that confuses users switching over from FreeBSD and Linux is that OpenBSD's implementation of WPA is in the kernel, there is no wpa_supplicant userland component.

As jggimi mentioned, in order to utilize the kernels software WPA support, drivers must first support it.

The 4.4 release was the first that offered WPA-PSK/WPA2-PSK but it didn't support every wireless chipset in the tree, 4.5 has come a long way since then.. so presumably more drivers will support it come May.

What's funny is that I've only ever used FreeBSD as a RAID server for some file storage. I've always used OpenBSD for my routing and firewalls.

I've typically found that the general idea of setting something up is pretty much the same across *nix's, with the main differences being
a) where the file is stored (/etc, /etc/hostapd, etc)
and b) some slight changes in command name (sfdisk or fdisk) and parameters.
Obviously I was very wrong in this case!

I've done WEP configuration only once before, and it was years ago, and I can't honestly remember whether it was on FreeBSD or OpenBSD. Since I was more than likely just toying around for geekpoints, and considering my confusion now, I'm guessing it was on FreeBSD.

It really never occured to me that OpenBSD would include the encryption in the kernel - it makes sense to do so, and I'm really glad that they did. Hopefully when I get a chance to toy around again tonight with the -current v4.5 I d/led and installed yesterday I'll be able to get this thing working with no problems.

At the very least, WEP encryption for the moment would be nice, just to let me know that I'm on the right track!

I agree that it should, but you never know. It may not even be ifconfig that causing the hang, it could be wpa-psk. It's something that's supposed to be supported, which to me means that they've tested it successfully. I just need to duplicate what they did, which may mean going back to an i386 architecture.

Atheros has come out recently with a number of variations on the same chip family which ath(4) does not currently support. If you post the output of dmesg(8), then we might be able to diagnose whether or not your particular chip will support WPA or not, but as others that already stated, OpenBSD 4.5 will be released 1 May.

Didn't have much time to test anything out last night unfortunately. Just had a chance to re-run my ifconfig with the wpapsk parameter specified like I thought it should be, and got the same issue - just a system freeze with no errors. Hopefully I'll have some time to poke at it more tonight.

It's hard to tell what's going on with ath from the man page or announcements. And looking through the CVS logs in src/sys/dev/ic/ar52* doesn't help. One has to try it. And so far, it doesn't appear to work.

It's hard to tell what's going on with ath from the man page or announcements. And looking through the CVS logs in src/sys/dev/ic/ar52* doesn't help. One has to try it. And so far, it doesn't appear to work.

You sir, are unfortunately correct. Of course, I was having problems with WEP as well, but that I may have just been fat-fingering something.

Now that's interesting... Why is it using inet and not ifconfig? And I need to specify the nwid after hostap? Logically it makes sense, but why do I need to use inet directly and not ifconfig?

Apparently hostap mode on wireless networks is not controllable via ifconfig. It needs to be handled by inet directly. And this means that you must create a hostname.if file with the parameters, and do

Code:

# sh /etc/netstart

to get the interface up. Here's my final hostname.ath0 (nwid and wpa-psk obfuscated, obviously)

I suspect you are reading "inet" & thinking inetd(8). "inet" is used to differentiate the following address as an IPv4 address. IPv6 addresses are denoted by "inet6". For more information, see ifconfig(8) & Section 6.2:

...the command directly to ifconfig results in a system freeze. The only way I can get it to work without a freeze is through the hostname.ath0.

Please consider taking the time to organize as much information as possible to create a formal (complete) problem report to the developers. Information on what is considered relevant, necessary, & informative can be found at the following link:

This site is independent of the project proper. Developers affiliated with the development of OpenBSD are not (generally) aware of discussions here, so any abnormal behaviour discussed here needs to be formally submitted in terms of problem reports if such problems are/can be resolved.

As mentioned previously, there are a certain number of recent Atheros chipsets which are similar to what was referenced in the creation of ath(4) but not entirely the same. I have seen one properly identified in dmesg(8) output which then crashes the kernel in -current upon scanning for available access points. Not that this identifies what you are encountering, but for the developers to resolve such problems, they need as much useful information as possible.