I don't mean to be a pest, but is there any more information that you might
need? This seems like basic functionality that others would want working as
well.
On Fri, Feb 10, 2017 at 4:09 PM, Chris Abel <[email protected]>
wrote:
> 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 <(518)%20836-2341>
>
--
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
