I may have figured out what is going on. packetfence + hostapd does not
like when you have 2 SSIDs on the same vlan. When one client disconnects
from one SSID and joins the other one, it will break the AP until you
restart wifi.
Previously I got around this by keeping my SSID's on different vlans. I
have one internal SSID for organization devices and one public SSID for
personal devices. If you were registered on the staff SSID and role and you
tried to connect to the public SSID, you would have had your role changed.
During the upgrade, something broke this and now my clients are returning
the role of Staff even when they connect to the public wifi, which causes
them to use the staff vlan and causes the hostapd AP to break.
So how can I force my nodes to unregister and reevaluate their access after
they connect to my public wifi?
Thanks,
Chris
On Tue, Jan 31, 2017 at 2:18 PM, Chris Abel <[email protected]>
wrote:
> I'm having trouble after recently making a large upgrade from packetfence
> 5.4 to packetfence 6.5. I have openwrt ubiquity access points that were
> working perfectly before the upgrade. Now the access points seem to work
> fine for a few minutes, but then stop working. When the access point is not
> working, the logread shows something like this:
>
> Tue Jan 31 15:27:46 2017 daemon.info hostapd: wlan0-1: STA
> a0:99:9b:1a:7e:51 RADIUS: VLAN ID 210
> 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 vlan210
> entered promiscuous mode
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.460000] breth0.210:
> port 1(vlan210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.470000] breth0.210:
> port 1(vlan210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.480000] breth0.210:
> port 1(vlan210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.480000] device
> wlan0.210 entered promiscuous mode
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.490000] breth0.210:
> port 2(wlan0.210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.490000] breth0.210:
> port 2(wlan0.210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.500000] breth0.210:
> port 2(wlan0.210) entered forwarding state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.520000] device
> wlan0.210 left promiscuous mode
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.520000] breth0.210:
> port 2(wlan0.210) entered disabled state
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.530000] device vlan210
> left promiscuous mode
> Tue Jan 31 15:27:46 2017 kern.info kernel: [79642.540000] breth0.210:
> port 1(vlan210) 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)
>
>
> You can see that the client is deauthed almost immediately after trying to
> connect. The client itself connects to the AP, but is given a self assigned
> IP. Manually setting the ip does not restore networking so I know that it
> is not put on a vlan.
>
> I get a lot of promiscuous mode changes and entered forwarding state logs
> when the AP is not working. When it is working, I don't see any of these.
>
> packetfence.log doesn't show anything out of the norm. It will show the
> client successfully is registered, get the role, and return the correct van
> to the AP.
>
> Here is my wireless configuration changes
>
> config wifi-device radio0
> option type mac80211
> option channel 11
> option hwmode 11g
> option path 'pci0000:00/0000:00:00.0'
> option htmode HT20
>
> config wifi-iface
> option device 'radio0'
> option mode 'ap'
> option ssid 'Public WiFi'
> option network 'lan'
> option encryption 'psk2'
> option key 'password'
> option auth_server '10.128.0.66'
> option auth_port '1812'
> option auth_secret 's3cr3t'
> option acct_server '10.128.0.66'
> option acct_port '1813'
> option acct_secret 's3cr3t'
> option dynamic_vlan '2'
> option vlan_file '/etc/config/hostapd.vlan'
> option vlan_tagged_interface 'eth0'
> option dae_secret 's3cr3t'
> option dae_client '10.128.0.66'
> option macfilter '2'
> option dae_port '3799'
> option nasid 'Ubiquiti'
>
> config wifi-iface
> option device 'radio0'
> option mode 'ap'
> option ssid 'Internal'
> option network 'lan'
> option encryption 'psk2'
> option key 'h1dd3n'
> option hidden '1'
> option auth_server '10.128.0.66'
> option auth_port '1812'
> option auth_secret 's3cr3t'
> option acct_server '10.128.0.66'
> option acct_port '1813'
> option acct_secret 's3cr3t'
> option dynamic_vlan '2'
> option vlan_file '/etc/config/hostapd.vlan'
> option vlan_tagged_interface 'eth0'
> option macfilter '2'
> option nasid 'Ubiquiti'
>
>
> I looked through the upgrade document and don't see anything about hostapd
> changes. Did the hostapd.sh file get updated recently that might have fixed
> this?
> --
> Chris Abel
> Systems and Network Administrator
> Wildwood Programs
> 2995 Curry Road Extension
> Schenectady, NY 12303
> 518-836-2341 <(518)%20836-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
