Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-28 Thread Sallee, Jake 
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 [lmu...@inverse.ca]
Sent: Wednesday, September 23, 2015 3:36 PM
To: packetfence-users@lists.sourceforge.net
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
lmu...@inverse.ca<mailto:lmu...@inverse.ca>  ::  
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 
<jake.sal...@umhb.edu<mailto:jake.sal...@umhb.edu>> 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.0 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))
    00.. = Differentiated Services Codepoint: Default (0x00)
    ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable 
Transport) (0x00)
   Total Length: 81
   Identification: 0x (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 [lmu...@inverse.ca]
Sent: Wednesday, Septem

Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-28 Thread Louis Munro 

On Sep 28, 2015, at 14:47 , Sallee, Jake  wrote:

> 
> 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.



Hi Jake,

Just to be sure, there is nothing at all going out from that server on port 
3799? 
Not even going to the wrong IP for the controller or AP?

Could you show me the switches.conf's section for that AP? 

Try changing the loglevel to the httpd.portal and httpd.webservices to “DEBUG”. 
That should give us additional insight into what is going on.

Regards,
--
Louis Munro
lmu...@inverse.ca  ::  www.inverse.ca 
+1.514.447.4918 x125  :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence 
(www.packetfence.org)

--
___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-23 Thread Louis Munro 
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
lmu...@inverse.ca  ::  www.inverse.ca 
+1.514.447.4918 x125  :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence 
(www.packetfence.org)

On Sep 22, 2015, at 11:06 , Sallee, Jake  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
> 
> 900 College St.
> Belton, Texas
> 76513
> 
> Fone: 254-295-4658
> Phax: 254-295-4221
> 
> --
> ___
> PacketFence-users mailing list
> PacketFence-users@lists.sourceforge.net
> 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=/4140___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-23 Thread Sallee, Jake 
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.0 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))
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable 
Transport) (0x00)
Total Length: 81
Identification: 0x (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

900 College St.
Belton, Texas
76513

Fone: 254-295-4658
Phax: 254-295-4221

From: Louis Munro [lmu...@inverse.ca]
Sent: Wednesday, September 23, 2015 9:00 AM
To: packetfence-users@lists.sourceforge.net
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
lmu...@inverse.ca<mailto:lmu...@inverse.ca>  ::  
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 
<jake.sal...@umhb.edu<mailto:jake.sal...@umhb.edu>> wrote:

Hello all!

Weird one h

Re: [PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-23 Thread Louis Munro 
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
lmu...@inverse.ca  ::  www.inverse.ca 
+1.514.447.4918 x125  :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence 
(www.packetfence.org)

On Sep 23, 2015, at 16:07 , Sallee, Jake <jake.sal...@umhb.edu> 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.0 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))
> 00.. = Differentiated Services Codepoint: Default (0x00)
> ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable 
> Transport) (0x00)
>Total Length: 81
>Identification: 0x (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
> 
> 900 College St.
> Belton, Texas
> 76513
> 
> Fone: 254-295-4658
> Phax: 254-295-4221
> 
> From: Louis Munro [lmu...@inverse.ca]
> Sent: Wednesday, September 23, 2015 9:00 AM
> To: packetfence-users@lists.sourceforge.net
> 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 r

[PacketFence-users] PF sending out SNMP De-Auth when set to RADIUS

2015-09-22 Thread Sallee, Jake 
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

900 College St.
Belton, Texas
76513

Fone: 254-295-4658
Phax: 254-295-4221

--
___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users