iwm0: no link ........... sleeping

[pieguy]

I'm attempting to connect to wifi with the following commands in OpenBSD 6.0 but receive "wm0: no link ........... sleeping."

ifconfig iwm0 nwid "NetworkName" wpakey "password"
dhclient iwm0

I'm using an Intel 3160 chip and have loaded the firmware into /etc/firmware. iconfig iwm0 displays:

iwm0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
	lladdr a0:88:69:b5:58:97
	index 1 priority 4 llprio 3
	groups: wlan
	media: IEEE802.11 autoselect (autoselect mode 11b)
	status: no network
	ieee80211: nwid ""

I see known networks with "ifconfig iwm0 scan.". What should I check?

[jggimi]

Hello, and welcome!

I will guess that either "password" is incorrect, "NetworkName" is incorrect, or there is no DHCP server available.

Of these, misrepresenting the WPA key is the most commonly seen problem. In particular, if your key is not an ASCII passphrase but is a hexadecimal string (base 16 binary), it must include leading 0x characters and must not be escaped by quotes.

To eliminate keys as the problem, you can temporarily provision an open access point.

[pieguy]

I don't believe the problem is name or password. What might be wrong with dhcp?

Am I correct that successfully running "ifconfig iwm0 scan" means everything necessary for my wifi chip is done? I ask this as in Linux I need to compile support into the kernel.

I also assume "ifconfig iwm0 up" is necessary before executing:

ifconfig iwm0 nwid "NetworkName" wpakey "password"
dhclient iwm0

[jggimi]

In OpenBSD, NIC drivers are all included in the kernel. There is nothing to add. For WiFi NICs, WPA/WPA2 encryption with pre-shared keys is "built in" if the hardware supports it, which the Intel 7000/8000 series does.

For normal operation, the "up" command is not needed, as dhclient(8) will bring the interface up in order to communicate over it.

I previously recommended testing with an open access point. If you are unable to do so, here is a test you can try with a closed access point:

Step 1: configure the ESSID ("nwid") and WPA/WPA2 pre-shared key ("wpakey").

Example with an ASCII passphrase:

# ifconfig iwm0 nwid "some WiFi network" wpakey "my private key"

Example with a hex passphrase:

# ifconfig iwm0 nwid "some WiFi network" wpakey 0x1274d5c165005f43

At this point, there has been no communication so the ifconfig(8) status output will show "no network".

Step 2: Bring up the network interface, without sending any packets.

# ifconfig iwm0 up

If the correct ESSID and passphrase were used, within some seconds the NIC should be able to train to the Access Point, and the ifconfig(8) output will show both the correct channel and the network as "active".

If the ESSID cannot be connected, the NIC will neither train to the channel nor will it show the network active.

Here is an example of ifconfig(8) output with my rtwn(4) NIC, after configuring the ESSID and passphrase, but not running dhclient(8):

$ ifconfig wlan
rtwn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    lladdr ec:55:f9:c6:f9:40
    index 2 priority 4 llprio 3
    groups: wlan egress
    media: IEEE802.11 autoselect mode 11g (OFDM54 mode 11g)
    status: active
    ieee80211: nwid "nondescript black Escalade" chan 8 bssid d8:5d:4c:bd:fb:08 -32dBm wpakey <not displayed> wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip

[shep]

Ultimately, most users like their preferred interface to come up automatically at boot.

From $ man iwm

EXAMPLES
The following example scans for available networks:

# ifconfig iwm0 scan

The following hostname.if(5) example configures iwm0 to join network
``mynwid'', using WPA key ``mywpakey'', obtaining an IP address using
DHCP:

nwid mynwid
wpakey mywpakey
dhcp

[scottro]

Just a guess, as this happened to me, is your wireless network hidden? If so, can you unhide it and see if the card then works?
(I found with an iwm0 card, in a yoga2, that it wouldn't work on hidden networks--and possibly an iwN as well, but it's so long since I changed it I have forgotten if it was iwn or iwm.)

[jggimi]

And, there are WiFi features of the hardware which are not available with OpenBSD's driver. The iwm(4) man page states:

CAVEATS
     802.11n operation is currently limited to data rates MCS 0 to MCS 7.

     The iwm driver does not support any of the 802.11ac capabilities offered
     by the adapters.  Additional work is required in ieee80211(9) before
     those features can be supported.

[pieguy]

Originally Posted by scottro

Just a guess, as this happened to me, is your wireless network hidden? If so, can you unhide it and see if the card then works?
(I found with an iwn0 card, in a yoga2, that it wouldn't work on hidden networks.)

Golly, to my great surprise unhiding the network worked. So hopefully reporting our experience might save others time. Your report certainly helped me.

But, is whoever's responsible for the iwm0 driver aware of this? If not, as I'm new to OpenBSD, how do I make them aware?

I assume other chips can recognize hidden networks with OpenBSD.

[jggimi]

See http://www.openbsd.org/report.html for guidance on bug reporting. There are a number of developers involved with WiFi support and WiFi NIC drivers, and this apparently affects at least two of the drivers.

[ocicat]

Originally Posted by pieguy

But, is whoever's responsible for the iwm0 driver aware of this? If not, as I'm new to OpenBSD, how do I make them aware?

As jggimi states, by filing a complete bug report, information will eventually get to the right person.

Be aware that this site has no official ties to any of the *BSD projects. This is an independent site maintained by people who support the efforts of the various *BSD projects, but none of us have affiliations with the projects other than being users ourselves.

As for OpenBSD in particular, there are project developers who read these forums on occasion & respond as they see fit, but this site is not maintained or supported by the OpenBSD project in any manner.

[pieguy]

Originally Posted by jggimi

And, there are WiFi features of the hardware which are not available with OpenBSD's driver. The iwm(4) man page states:

CAVEATS
     802.11n operation is currently limited to data rates MCS 0 to MCS 7.

     The iwm driver does not support any of the 802.11ac capabilities offered
     by the adapters.  Additional work is required in ieee80211(9) before
     those features can be supported.

I've little knowlege of this. Does anyone know whether the 802.11ac caveat covers hidden networks?

[jggimi]

No. 802.11ac is an extension of the WiFi standard. What you and scottro refer to as "hidden" is not related.

A "hidden" WiFi network is one that does not broadcast its Service Set ID ("wireless network name"), so it is not shown in lists of broadcast SSIDs. This is an example of "security by obscurity." However, the network itself is not actually hidden, as the Access Point still broadcasts a beacon, and the SSID is transmitted in plaintext in all association traffic between clients and the Access Point.

https://blogs.technet.microsoft.com/...ireless-ssids/

"Security by obscurity" is never a best practice, and this particular form is a poor obscuration.

[pieguy]

I thought I'd post an update. I submitted a bug report and received a developer reply in about an hour (in my book that's dang impressive). I was given a patch to modify iwm and compiled a new kernel (with the help of jggimi).

The patch didn't fix the problem, but gave the developer information and he's looking at a solution. But the point is OpenBSD proved quite open to acknowledging the problem and a solution. Again, I'm impressed.

I was aware hiding a network doesn't fully hide or protect a network. I use the term "Hidden" as that's the checkbox label in my cable modem setup.

On my box, 'ifconfig wlan0 scan' displays my network name even if I have hidden checked. However, I believe some network managers don't. And my guess is Windows doesn't. So if I can choose to not broadcast my network name to some systems I'll do so 10 times out of 10. I just prefer it.

[jggimi]

Access Points broadcast a type of signal called a Beacon frame. The Beacon frame includes the SSID, which is a variable length field. When you "hide" the SSID, it is just not included in the Beacon frame.

But the Beacon is still broadcast.

[scottro]

As hidden is (or at least was) the Linksys wireless router default, it can be a nuisance if say, visiting a non-technical friend's house and wanting Internet access. So, hopefully the bug will get fixed.

[pieguy]

Originally Posted by jggimi

But the Beacon is still broadcast.

Indeed, I should have said displayed.

[jggimi]

I haven't inspected these frames in detail to determine they set the field to a byte length of zero or not, but I expect that's the case. The tcpdump(8) tool shows Beacon frames with "hidden" SSIDs as empty. An example from a neighbor's AP:

12:86:8c:76:03:f6 > ff:ff:ff:ff:ff:ff, bssid 12:86:8c:76:03:f6: 802.11: beacon, ssid (), rates, ds, tim, country, erp, xrates, htcaps, htop, 127:8

When any device associates with that AP, the SSID will be sent in the clear. Which is why these aren't actually hidden.

[IdOp]

I'm unable to test this, and pretty much out of my depth here, but it seems worth throwing out an idea: What if you used ifconfig(8)'s bssid flag to specify the Access Point's MAC, instead of --- or perhaps along with(?) --- the nwid flag? Conceivably this could tell the driver what AP you want even when the network name isn't advertised in the beacon?

[scottro]

Just tried it on my yoga2 with no luck. The syntax that didn't get an error was ifconfig iwm0 nwid whatever bssid 00:11:22:33 and so on, wpakey whatever. However, it didn't get a connection

[IdOp]

Thanks for trying and reporting scottro .