We are using an OpenWRT 21.02.0 Hostapd client as a switch.
Our PF is Debian 11 with PF 11 on the most recent stable production build:
11.0.0+20211019052209+390787654+0011+maintenance~11.0+bullseye1
Our PF server is configured with management IP 10.2.1.2 and our switch
10.2.1.60 in the information shared below.
Both our switch group, and our switch have the disconnectPort and
coaPort specified as 3798, as show below from our switches.conf
[group Office_APS]
guestVlan=73
VoIPDHCPDetect=N
VoIPLLDPDetect=N
guestRole=default
type=Hostapd
VoIPCDPDetect=N
description=office test devices
deauthMethod=RADIUS
gamingRole=default
defaultVlan=73
isolationVlan=82
gamingVlan=73
RoleMap=Y
registrationVlan=81
radiusSecret=xxxx
always_trigger=1
*disconnectPort=3798coaPort=3798*
[10.2.1.60]
guestVlan=73
*disconnectPort=3798coaPort=3798*
defaultVlan=73
group=Office_APS
description=TEST-AP
gamingVlan=73
We can see our listener on 3798 on our hostapd client / switch.
~# netstat -tunap | grep 3798
udp 0 0 0.0.0.0:3798 0.0.0.0:*
1617/hostapd
Watching the packetflow, PF11 is still sending on 3799, despite being
configured to use 3798. It seems to be ignoring the configuration for
some reason. The result of not receiving the disconnect on the correct
port is that clients are not being disconnected from registration vlan.
11:51:48.021157 IP 10.2.1.60.58398 > 10.2.1.2.1812: RADIUS, Access-Request
(1), id: 0x21 length: 165
11:51:48.199840 IP 10.2.1.2.1812 > 10.2.1.60.58398: RADIUS, Access-Accept
(2), id: 0x21 length: 36
11:51:48.636694 IP 10.2.1.60.32955 > 10.2.1.2.1813: RADIUS,
Accounting-Request (4), id: 0x22 length: 183
11:51:48.772328 IP 10.2.1.2.1813 > 10.2.1.60.32955: RADIUS,
Accounting-Response (5), id: 0x22 length: 35
11:51:48.853940 IP 10.2.1.60.32955 > 10.2.1.2.1813: RADIUS,
Accounting-Request (4), id: 0x23 length: 225
11:51:48.856610 IP 10.2.1.60.32955 > 10.2.1.2.1813: RADIUS,
Accounting-Request (4), id: 0x24 length: 183
11:51:48.891889 IP 10.2.1.2.1813 > 10.2.1.60.32955: RADIUS,
Accounting-Response (5), id: 0x23 length: 35
11:51:48.894938 IP 10.2.1.2.22 > 10.2.1.5.32778: Flags [P.], seq 100:200,
ack 1, win 501, options [nop,nop,TS val 1817400362 ecr 1256487595], length
100
11:51:48.902378 IP 10.2.1.2.1813 > 10.2.1.60.32955: RADIUS,
Accounting-Response (5), id: 0x24 length: 35
11:51:53.204975 ARP, Request who-has 10.2.1.2 tell 10.2.1.60, length 28
11:51:53.205396 ARP, Reply 10.2.1.2 is-at 00:16:3e:dc:9d:fd (oui Unknown),
length 42
11:51:53.361125 ARP, Request who-has 10.2.1.60 tell 10.2.1.2, length 42
11:51:53.361213 ARP, Reply 10.2.1.60 is-at 50:d4:f7:6b:87:0e (oui Unknown),
length 28
*11:52:18.919296 IP 10.2.1.2.54653 > 10.2.1.60.3799: RADIUS,
Disconnect-Request (40), id: 0x31 length: 39*
Is it possible that the disconnect port is learned from something other
than the switch configuration, or is this possibly a bug in the radius
configuration and port enumeration.
Any insights here appreciated.
cheers,
ian
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
