On 01/05/15 19:43, Stefan Sperling wrote:
This shows a scan.
I don't see an association in there. You should also see WPA handshake
on a successfull connect messages since your network uses WPA.
In any case this should allow you to see exactly when the driver gets
and drops link. These messages are also logged to /var/log/messages.
Ok, I set debug during boot and managed to capture a handshake. This is
the dmesg from the time when run0 becomes available. This is all boot
only, no ifconfig commands or dhclint were issued manually after login.
I am not a network expert, but is it possible that it takes too long to
establish a connection (for whatever reason)? If so, is there a
possiblity to tell the driver to try getting a connection for a longer
time? The following shows that run0 gets a connection/handshake, but
after the "no link........... sleeping". And why would it try getting
and successing getting a connection after it is supposingly "sleeping"?
run0 at uhub4 port 3 "Ralink 802.11 n WLAN" rev 2.00/1.01 addr 3
run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address
80:1f:02:9a:22:c2
uhidev0 at uhub4 port 7 configuration 1 interface 0 "CM Storm Keyboard
-- QuickFire XT" rev 1.10/1.04 addr 4
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub4 port 7 configuration 1 interface 1 "CM Storm Keyboard
-- QuickFire XT" rev 1.10/1.04 addr 4
uhidev1: iclass 3/1, 2 report ids
uhid0 at uhidev1 reportid 1: input=6, output=0, feature=0
uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0
uhidev2 at uhub4 port 8 configuration 1 interface 0 "Razer DeathAdder"
rev 2.00/1.00 addr 5
uhidev2: iclass 3/1
ums0 at uhidev2: 7 buttons, Z dir
wsmouse0 at ums0 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd1: 228933MB, 512 bytes/sector, 468856433 sectors
root on sd1a (55de1489e9df9f8c.a) swap on sd1b dump on sd1b
run0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 167 mode 11a
run0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 169 mode 11a
run0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 171 mode 11a
run0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 173 mode 11a
run0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 1 mode 11g
run0: received beacon from 9c:97:26:8c:69:b5 rssi 41 mode 11g
run0: end active scan
run0: sending auth to 44:32:c8:34:24:18 on channel 44 mode 11a
run0: received auth from 44:32:c8:34:24:18 rssi 23 mode 11a
run0: sending assoc_req to 44:32:c8:34:24:18 on channel 44 mode 11a
run0: received assoc_resp from 44:32:c8:34:24:18 rssi 23 mode 11a
run0: received msg 1/4 of the 4-way handshake from 44:32:c8:34:24:18
run0: sending msg 2/4 of the 4-way handshake to 44:32:c8:34:24:18
run0: associated with 44:32:c8:34:24:18 ssid "clumsy5" channel 44 start
6Mb short preamble short slot time
run0: received msg 3/4 of the 4-way handshake from 44:32:c8:34:24:18
run0: sending msg 4/4 of the 4-way handshake to 44:32:c8:34:24:18
And here the messages (plese note that this seems to capture messages
from previous boots as well - only the last ones (time approx 19:58) are
from the current boot):
# cat /var/log/messages | grep run0
Jan 5 19:13:33 openbsd /bsd: run0: begin active scan
Jan 5 19:13:33 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 3 mode 11g
Jan 5 19:13:34 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 4 mode 11g
Jan 5 19:13:34 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 5 mode 11g
Jan 5 19:13:34 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 6 mode 11g
Jan 5 19:13:35 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 7 mode 11g
Jan 5 19:13:35 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 8 mode 11g
Jan 5 19:13:35 openbsd dhclient[31856]: run0 down; exiting
Jan 5 19:14:12 openbsd dhclient[21862]: run0 down; exiting
Jan 5 19:14:29 openbsd /bsd: run0 detached
Jan 5 19:14:29 openbsd dhclient[31397]: run0 receive_packet failed:
Input/output error
Jan 5 19:14:29 openbsd dhclient[31397]: run0 departured; exiting
Jan 5 19:14:45 openbsd /bsd: run0 at uhub3
Jan 5 19:14:45 openbsd /bsd: run0: MAC/BBP RT3572 (rev 0x0223), RF
RT3052 (MIMO 2T2R), address 80:1f:02:9a:22:c2
Jan 5 19:15:58 openbsd dhclient[30457]: run0 down; exiting
Jan 5 19:41:20 openbsd dhclient[13907]: run0 down; exiting
Jan 5 19:41:43 openbsd dhclient[22931]: run0 down; exiting
Jan 5 19:42:41 openbsd dhclient[27354]: run0 down; exiting
Jan 5 19:51:39 openbsd dhclient[2017]: run0 down; exiting
Jan 5 19:57:36 openbsd dhclient[11134]: run0 receive_packet failed:
Input/output error
Jan 5 19:57:36 openbsd /bsd: run0 detached
Jan 5 19:57:48 openbsd /bsd: run0 at uhub4
Jan 5 19:57:48 openbsd /bsd: run0: MAC/BBP RT3572 (rev 0x0223), RF
RT3052 (MIMO 2T2R), address 80:1f:02:9a:22:c2
Jan 5 19:58:57 openbsd /bsd: run0 at uhub4 port 3 "Ralink 802.11 n
WLAN" rev 2.00/1.01 addr 3
Jan 5 19:58:57 openbsd /bsd: run0: MAC/BBP RT3572 (rev 0x0223), RF
RT3052 (MIMO 2T2R), address 80:1f:02:9a:22:c2
Jan 5 19:58:57 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 167 mode 11a
Jan 5 19:58:57 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 169 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 171 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 173 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: sending probe_req to
ff:ff:ff:ff:ff:ff on channel 1 mode 11g
Jan 5 19:58:58 openbsd /bsd: run0: received beacon from
9c:97:26:8c:69:b5 rssi 41 mode 11g
Jan 5 19:58:58 openbsd /bsd: run0: end active scan
Jan 5 19:58:58 openbsd /bsd: run0: sending auth to 44:32:c8:34:24:18 on
channel 44 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: received auth from 44:32:c8:34:24:18
rssi 23 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: sending assoc_req to
44:32:c8:34:24:18 on channel 44 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: received assoc_resp from
44:32:c8:34:24:18 rssi 23 mode 11a
Jan 5 19:58:58 openbsd /bsd: run0: received msg 1/4 of the 4-way
handshake from 44:32:c8:34:24:18
Jan 5 19:58:58 openbsd /bsd: run0: sending msg 2/4 of the 4-way
handshake to 44:32:c8:34:24:18
Jan 5 19:58:58 openbsd /bsd: run0: associated with 44:32:c8:34:24:18
ssid "clumsy5" channel 44 start 6Mb short preamble short slot time
Jan 5 19:58:58 openbsd /bsd: run0: received msg 3/4 of the 4-way
handshake from 44:32:c8:34:24:18
Jan 5 19:58:58 openbsd /bsd: run0: sending msg 4/4 of the 4-way
handshake to 44:32:c8:34:24:18
Hard to tell from over here.
Have you ever tested with a different AP in a different environment?
The tiny USB dongle antennas could be too weak for your environment
e.g. due to interference from other radio sources.
Sometimes small changes in positioning can make a difference. I have a
tiny urtwn(4) USB dongle which connects if I lean forward on my couch but
doesn't connect when I sit back and relax :( I settled on not using this
device rather than moving the couch.
No, not with a different AP, but with different settings (2.4GHz, 5GHz,
20/40 MHz channel width, different channels). And both of my Thinkpads
with wpi supported chips get a connection to the same AP perfectly, and
really fast (running OpenBSD -current i386, haven't tried amd64 though).
I have a desktop PC meaning it doesn't move at all - and we hardly have
any earthquakes here in Austria :)
And the distance from adapter to AP is less than a meter. IMHO perfect
conditions for functional wireless networking
And when I boot into Ubuntu, both wireless adapters work perfectly, so I
don't think it's a hardware thing.
For 5Ghz on USB your options are limited to run(4), rum(4), uath(4), otus(4).
I have a rsu(4) USB dongle (Conrad N150) with a little screw-on
omni-directional antenna. That usually works where other USB or built-in
wifi cards don't. I don't believe the driver makes a crucial difference,
it's the antenna. This device is 2.4Ghz only though.
For built-in PCI, hunt down a supported athn(4) or iwn(4) card (see the
man page for model and chip names).
An athn suppored PCIe chip is already on the way for my OpenBSD wireless
AP to-be. It is one of the few chips with AP support + dual band which
is currently available.
