Date: Fri, 03 Jan 2014 21:07:40 -0800 From: Yuri <yuri@rawbw.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless <freebsd-wireless@freebsd.org> Subject: Re: hostapd prints errors like this: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: No such file or directory Message-ID: <52C7971C.7020909@rawbw.com> In-Reply-To: <CAJ-VmomHPHwOkNnFxmOKqyBssp0qiEh=80h7b%2BCgthW%2BnFfGpA@mail.gmail.com> References: <52C6A33C.4030300@rawbw.com> <CAJ-Vmok3=jiMW1%2B3Tg3Jk78BXTWDq6AHb3b5v%2BjDEjwJA6i3zQ@mail.gmail.com> <52C70D01.1070906@rawbw.com> <CAJ-VmomLRWvs1P=LM3LxQo-0oX18eYVGWHQzfhAoyiLvA7jiUw@mail.gmail.com> <52C718B3.2030302@rawbw.com> <CAJ-Vmo=xx3PyJHG4sEp7-HRc4ou43HvT8EkJT1YBB7M6_Ey26A@mail.gmail.com> <52C71A1B.5070707@rawbw.com> <CAJ-VmomHPHwOkNnFxmOKqyBssp0qiEh=80h7b%2BCgthW%2BnFfGpA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/03/2014 12:29, Adrian Chadd wrote: > Try ifconfig ath0 ether <x> .. why link? ifconfig(8) man page says: “ether” and “lladdr” are synonyms for “link”. And it actually doesn't make any difference. I verified that it is in fact the old MAC that is being looked up, here are two stacks of such failed check during the user disconnect event in the end: kernel`ieee80211_ioctl_delkey+0xa1 kernel`ieee80211_ioctl_set80211+0xac9 kernel`in_control+0x1fb kernel`ifioctl+0x803 kernel`kern_ioctl+0x106 kernel`sys_ioctl+0x157 kernel`amd64_syscall+0x5ea kernel`0xffffffff80b55677 libc.so.7`__sys_ioctl+0xc hostapd`bsd_set_key+0x129 hostapd`hostapd_wpa_auth_set_key+0x6d hostapd`wpa_remove_ptk+0x5b hostapd`wpa_auth_sm_event+0x64 hostapd`hostapd_notif_disassoc+0x8f hostapd`bsd_wireless_event_receive+0x28d hostapd`eloop_sock_table_dispatch+0x6c hostapd`eloop_run+0x1b7 hostapd`main+0x372 hostapd`_start+0xa1 ld-elf.so.1`free_tls+0x40 kernel`ieee80211_ioctl_delkey+0xa1 kernel`ieee80211_ioctl_set80211+0xac9 kernel`in_control+0x1fb kernel`ifioctl+0x803 kernel`kern_ioctl+0x106 kernel`sys_ioctl+0x157 kernel`amd64_syscall+0x5ea kernel`0xffffffff80b55677 libc.so.7`__sys_ioctl+0xc hostapd`bsd_set_key+0x129 hostapd`hostapd_wpa_auth_set_key+0x6d hostapd`wpa_remove_ptk+0x5b hostapd`sm_WPA_PTK_INITIALIZE_Enter+0x9d hostapd`wpa_sm_step+0x1da hostapd`hostapd_notif_disassoc+0x8f hostapd`bsd_wireless_event_receive+0x28d hostapd`eloop_sock_table_dispatch+0x6c hostapd`eloop_run+0x1b7 hostapd`main+0x372 hostapd`_start+0xa1 ld-elf.so.1`free_tls+0x40 Curiously, ieee80211_find_vap_node is also queried with the original MAC in the beginning of the connection, and this lookup succeeded for some reason (here are two stacks of this): kernel`ieee80211_ioctl_getwpaie+0x98 kernel`ieee80211_ioctl_get80211+0xb2 kernel`in_control+0x1fb kernel`ifioctl+0x803 kernel`kern_ioctl+0x106 kernel`sys_ioctl+0x157 kernel`amd64_syscall+0x5ea kernel`0xffffffff80b55677 libc.so.7`__sys_ioctl+0xc hostapd`bsd_wireless_event_receive+0x175 hostapd`eloop_sock_table_dispatch+0x6c hostapd`eloop_run+0x1b7 hostapd`main+0x372 hostapd`_start+0xa1 ld-elf.so.1`free_tls+0x40 kernel`ieee80211_ioctl_delkey+0xa1 kernel`ieee80211_ioctl_set80211+0xac9 kernel`in_control+0x1fb kernel`ifioctl+0x803 kernel`kern_ioctl+0x106 kernel`sys_ioctl+0x157 kernel`amd64_syscall+0x5ea kernel`0xffffffff80b55677 libc.so.7`__sys_ioctl+0xc hostapd`bsd_set_key+0x129 hostapd`hostapd_wpa_auth_set_key+0x6d hostapd`wpa_remove_ptk+0x5b hostapd`wpa_auth_sm_event+0x64 hostapd`hostapd_notif_assoc+0x128 hostapd`bsd_wireless_event_receive+0x1d7 hostapd`eloop_sock_table_dispatch+0x6c hostapd`eloop_run+0x1b7 hostapd`main+0x372 hostapd`_start+0xa1 ld-elf.so.1`free_tls+0x40 Since the new MAC address has been set on ath0 before AP was brought up, old MAC should never (IMO) appear in any lookups anywhere at all. So there is definitely a leak of the original MAC address somewhere. You probably know the code of hostapd, maybe you can see from these stacks where does hostapd get the original MAC from? Yuri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52C7971C.7020909>