Hi Ludovic,
I'll do my best with the Use Case. Let me know if you don't understand.
- OpenWRT AP has two SSIDs. SSID A and SSID B. Both of these SSIDs
communicate with the freeradius server and packetfence to determine the
role of the node.
- User A connects to SSID A and is applied the role "Staff" and put into
VLAN 50.
- User A disconnects to SSID A and connects to SSID B. Packetfence sees
that user is registered with the "Staff" role and returns VLAN 50.
- Something happens here that completely breaks networking for the SSID.
The AP itself does not lose networking and nodes are still able to see and
connect to the SSID, but the node receives an immediate deauth and a self
assigned IP. All other nodes are also unable to receive networking. If Wifi
is restarted on the AP, networking works again.
This behavior only happens when there are multiple SSIDs that could
potentially host the same VLAN.
I do not have any hostapd logs, but here is the log on the OpenWRT AP when
it happens:
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 RADIUS: VLAN ID 50
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 IEEE 802.11: authenticated
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 RADIUS: stopped accounting session 588F75DB-00000078
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 IEEE 802.11: associated (aid 12)
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.460000] device vlan50
entered promiscuous mode
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.460000] breth0.50: port
1(vlan50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.470000] breth0.50: port
1(vlan50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.480000] breth0.50: port
1(vlan50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.480000] device wlan0.50
entered promiscuous mode
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.490000] breth0.50: port
2(wlan0.50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.490000] breth0.50: port
2(wlan0.50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.500000] breth0.50: port
2(wlan0.50) entered forwarding state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.520000] device wlan0.50
left promiscuous mode
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.520000] breth0.50: port
2(wlan0.50) entered disabled state
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.530000] device vlan50
left promiscuous mode
Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.540000] breth0.50: port
1(vlan50) entered disabled state
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 RADIUS: starting accounting session 588F75DB-00000078
Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 WPA: pairwise key handshake completed (RSN)
Tue Jan 31 15:27:50 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 IEEE 802.11: disassociated
Tue Jan 31 15:27:50 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 RADIUS: stopped accounting session 588F75DB-00000078
Tue Jan 31 15:27:51 2017 daemon.info hostapd: wlan0-1: STA
a0:99:9b:1a:7e:51 IEEE 802.11: deauthenticated due to inactivity (timer
DEAUTH/REMOVE)
Hope this helps. Let me know if you would like any more information. I was
able to replicate this on all of my openwrt access points.
Regards,
Chris
On Thu, Feb 9, 2017 at 1:41 PM, Ludovic Zammit <[email protected]> wrote:
> Hello Chris,
>
> Can you describe a detailed use case?
>
> Can you also post the hostapd error that you encounter?
>
> Thanks,
>
> Ludovic [email protected] :: +1.514.447.4918 <(514)%20447-4918>
> (x145) :: www.inverse.ca
> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
> (http://packetfence.org)
>
>
>
>
> Le 7 févr. 2017 à 11:51, Chris Abel <[email protected]> a écrit :
>
> There has been a bug with the hostapd.sh script that packetfence provides.
> I've posted about it before, but I'm curious if there is any work on
> resolving it? When 2 SSID's are configured and a node connects to both
> SSIDs and put into the same vlan, networking breaks and they are given a
> self assigned IP.
>
> Here is my set up:
>
> 1 hidden SSID for company owned devices
> 1 public SSID for BYOB or company owned devices
>
> Here is what is supposed to happen: If a company owned device/node
> connects to the public SSID, PF will recognize that is is registered with
> the "staff" role. It is then assigned to be part of the staff vlan...
> Because the staff vlan is also assigned to any node that is connected to
> the hidden SSID, the networking will completely break and the unifi/Openwrt
> AP will require wifi to be restarted in order for nodes to connect to it
> again.
>
> I am wondering if there is any work on correcting this or if there has
> been any work on a chaos calmer build for packetfence and if it corrects
> this bug.
>
> Thanks,
> Chris
>
>
>
>
> IMPORTANT NOTICE: This message and any attachments are solely for the
> intended recipient and may contain confidential information, which is, or
> may be, legally privileged or otherwise protected by law from further
> disclosure. If you are not the intended recipient, any disclosure, copying,
> use, or distribution of the information included in this email and any
> attachments is prohibited. If you have received this communication in
> error, please notify the sender by reply email and immediately and
> permanently delete this email and any attachments.
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org <http://slashdot.org>!
> http://sdm.link/slashdot_______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
--
Chris Abel
Systems and Network Administrator
Wildwood Programs
2995 Curry Road Extension
Schenectady, NY 12303
518-836-2341
--
IMPORTANT NOTICE: This message and any attachments are solely for the
intended recipient and may contain confidential information, which is, or
may be, legally privileged or otherwise protected by law from further
disclosure. If you are not the intended recipient, any disclosure, copying,
use, or distribution of the information included in this email and any
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and immediately and
permanently delete this email and any attachments.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
