jda / jungleauth Goto Github PK

What steps will reproduce the problem?
1. Add SM to MySQL
2. Connect SM
3. Make a change to a record in SQL. 

What is the expected output? 
  The expected behavior is freebam monitor MySQL for changes and  notify the AP of the change. 

What do you see instead? 
  Nothing changes. When I reboot the SM the change still does not happen. It seems I need to restart freebam, then reboot the SM to see te change.


What version of the product are you using? freebam-0.1 
On what operating system? Linux 2.6.32 perl 5.10.1 

Please provide any additional information below.

I have done some pcaps from prizm to an AP and noticed prizm notifies the AP 
when something changes. 

Is this a feature that is not implemented in freebam? 

What steps will reproduce the problem?
1. Remove SM from auth database
2. Let SM try to register overnight
3. Add SM to auth database
4. Out of range errors appear in AP Registration Failure log

What is the expected output? What do you see instead?
I expect the SM to register to the AP. 

Write a test client that can:
1. Test our understanding of protocol against a official server
2. Be used as a check in Nagios to ensure a server is operating correctly
3. Speed up development by sending automated tests - no need for Canopy 
equipment

What steps will reproduce the problem?
1. Enable airlink encryption on AP
2. Watch AP crash/not work

What is the expected output? What do you see instead?
SM is expected to register. Instead the AP crashes or SMs do not register.

What version of the product are you using? On what operating system?
Canopy 400 on SW 8.4.2

What steps will reproduce the problem?
1. Point an AP at jungleauth that has 20+ client SMs registering to it


When I point APs at jungleauth (basicserver-acceptall.pl for example) it
will only successfully register 10 SMs, the remaining SMs it will
continuously attempt re-authentication every couple seconds indefinitely -
they never are allowed to connect.


APs running firmware 9.5.  Tests with my own custom smauth.pl daemon
utilizing NET::Canopy::BAM and with basicserver-acceptall.pl, both exhibit
the same problem.


I have not yet tried with several such APs at once, but I have tried with
one such AP (38 active SMs) and another light-load AP with 2 clients - in
that scenario on the AP with two clients they both connect, on the AP with
38 clients only 10 connect, the remaining 28 SM's authentications are
endlessly re-attempted.

j

What steps will reproduce the problem?
1. SM registers with sequence number 0
2. Reboot SM
3. SM does not register when AP sends a sequence number other than 0

What is the expected output? What do you see instead?
Expected: SM registers. Result: SM does not register.

Note that this is only a problem with the packet processing module. The
proof of concept server successfully handles re-registration.