Louis: You are correct, we assumed that was an SNMP de-auth request but it is not.
I did some more testing and we cannot see any RADIUS messages on any port other than access-request, access-accept, account-request, and accounting-response. Any ideas? Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________ From: Louis Munro [[email protected]] Sent: Wednesday, September 23, 2015 3:36 PM To: [email protected] Subject: Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS Hi Jake, That packet seems to be unrelated to disconnection. The OID is that of the system location. Can you run a tcpdump when you try to deauth a connection and see if there is anything send to port 3799 from the PF server? That would be a RADIUS disconnect request. Regards, -- Louis Munro [email protected]<mailto:[email protected]> :: www.inverse.ca<http://www.inverse.ca> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and PacketFence (www.packetfence.org<http://www.packetfence.org>) On Sep 23, 2015, at 16:07 , Sallee, Jake <[email protected]<mailto:[email protected]>> wrote: Louis! Hows it goin' buddy! Here is a pcap of the exchange between the aruba vcontroller and the PF server. I have more, but I didn't want to flood the list with superfluous data. ============================ Frame 12: 95 bytes on wire (760 bits), 95 bytes captured (760 bits) on interface 0 Interface id: 0 WTAP_ENCAP: 1 Arrival Time: Sep 23, 2015 14:51:58.385507208 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1443037918.385507208 seconds [Time delta from previous captured frame: 2.001426505 seconds] [Time delta from previous displayed frame: 2.001426505 seconds] [Time since reference or first frame: 210.240917362 seconds] Frame Number: 12 Frame Length: 95 bytes (760 bits) Capture Length: 95 bytes (760 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:udp:snmp] Ethernet II, Src: Dell_3c:49:eb (90:b1:1c:3c:49:eb), Dst: Cisco_92:58:bf (6c:20:56:92:58:bf) Destination: Cisco_92:58:bf (6c:20:56:92:58:bf) Address: Cisco_92:58:bf (6c:20:56:92:58:bf) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: Dell_3c:49:eb (90:b1:1c:3c:49:eb) Address: Dell_3c:49:eb (90:b1:1c:3c:49:eb) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 10.2.1.75 (10.2.1.75), Dst: 10.11.40.252 (10.11.40.252) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 81 Identification: 0x0000 (0) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0xfc48 [correct] [Good: True] [Bad: False] Source: 10.2.1.75 (10.2.1.75) Destination: 10.11.40.252 (10.11.40.252) User Datagram Protocol, Src Port: 58541 (58541), Dst Port: snmp (161) Source port: 58541 (58541) Destination port: snmp (161) Length: 61 Checksum: 0x3ea2 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Simple Network Management Protocol version: v2c (1) community: [REDACTED] data: get-request (0) get-request request-id: 1606903620 error-status: noError (0) error-index: 0 variable-bindings: 1 item 1.3.6.1.2.1.1.6.0: Value (Null) Object Name: 1.3.6.1.2.1.1.6.0 (iso.3.6.1.2.1.1.6.0) Value (Null) ============================ I did restart the PF services yesterday, still no luck. We have not made any customizations except the single line I mentioned earlier to enable wired mac auth, and that was made well after the upgrade to 5.3.1. Theoretically, we should be working with a very stock version of PF. Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU<http://WWW.UMHB.EDU> 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________ From: Louis Munro [[email protected]] Sent: Wednesday, September 23, 2015 9:00 AM To: [email protected] Subject: Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS Hi Jake, Yes, the Aruba are supposed to be compatible with both wired and wireless RADIUS auth. Official support for that should be in the next PF release actually. Are you sure the SNMP sent to the controller is for deauth? Can you tell us what OID is in the request? Also, if your system has been upgraded, are you sure the Aruba module you are using is the latest version? If you carried and old version through and upgrade (perhaps because it was customized) you may be seeing the old behaviour. The module is in lib/pf/Switches/Aruba.pm. Compare that (and lib/pf/Switches/Aruba/Controller_200.pm) to the latest official versions at https://github.com/inverse-inc/packetfence/blob/packetfence-5.3.1/lib/pf/Switch/Aruba.pm Regards, -- Louis Munro [email protected]<mailto:[email protected]> :: www.inverse.ca<http://www.inverse.ca> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and PacketFence (www.packetfence.org<http://www.packetfence.org>) On Sep 22, 2015, at 11:06 , Sallee, Jake <[email protected]<mailto:[email protected]>> wrote: Hello all! Weird one here. First things first: PF v5.3.1, with an Aruba 205H AP. The manufacturer ensures us that the devices are compatible with wired and wireless MAC auth so we have made a small adjustment to the module to return mac auth = true. Other than that, everything is stock. In the switch config the ap is set to RADIUS de-auth, but a packet cap shows PF sending SNMP and NOT RADIUS CoA. I have done a pfcmd configreload but no joy. This box is in production so I would really like to avoid bouncing all the services if I can. Anyone have any ideas? Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU<http://WWW.UMHB.EDU> 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ------------------------------------------------------------------------------ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
