From owner-freebsd-wireless@FreeBSD.ORG Sat Jan 4 05:07:41 2014 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81E68F22; Sat, 4 Jan 2014 05:07:41 +0000 (UTC) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 693271249; Sat, 4 Jan 2014 05:07:41 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id s0457eYZ053933; Fri, 3 Jan 2014 21:07:40 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <52C7971C.7020909@rawbw.com> Date: Fri, 03 Jan 2014 21:07:40 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: hostapd prints errors like this: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: No such file or directory References: <52C6A33C.4030300@rawbw.com> <52C70D01.1070906@rawbw.com> <52C718B3.2030302@rawbw.com> <52C71A1B.5070707@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-wireless X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 05:07:41 -0000 On 01/03/2014 12:29, Adrian Chadd wrote: > Try ifconfig ath0 ether .. 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