PacketFence - Support - ISSUES

0001059: move 'static' methods out of pf::SNMP into a util module

when they have no state or side effects with the object, they just take up memory into each objects and our switch objects are probably already big enough

among good candidates are:
- getBitAtPosition
- modifyBitmask
- createPortListWithOneItem
- reverseBitmask
- ...

Sending those of to pf::util would clutter this module I think, so may I suggest a new pf::SNMP::util ?

0001058: get rid of pf::SNMP::connectMySQL and associated $this->{_mysqlConnection}

It is no longer used anywhere and the next major release is a great opportunity to remove that dead code.

Don't forget that pfsetvlan does the connection (even though it is unused) so you need to remove that code too.

0001050: Force DHCP to send DHCPNACKs to client that juste changed VLAN that insist on getting an invalid IP

Problem description:

In /var/log/messages you see errors like:

dhcpd: DHCPREQUEST for from via eth1: unknown lease .

This will happen with some devices when they are moved from a production VLAN into a registration or isolation VLAN in a non IP-Helper setup. The device will do it's REQUEST with the prod IP and the dhcpd will say unknown because it's not under it's authority.

By default ISC's dhcpd will not reply with a DHCPNACK to allow several dhcp servers to co-exist on the same LAN without NACKin' each other. This is not the usual PacketFence setup so we can be more aggressive on NACKin' the clients.

To solve the problem, we need to deny production scopes

For example, add the following to /etc/dhcpd.conf:

subnet 192.168.0.0 netmask 255.255.255.0 {
pool {
range 192.168.0.1 192.168.0.255;
deny all clients;
}
}

where production network is 192.168.0.0/24.

A proper implementation would be to alter the dhcpd.conf template so it will automatically generate such a config.

See http://www.isc.org/files/auth.html [^] for details.

0001057: registration.maxnodes is not enforced the same way on the captive portal and in pfcmd manage register

registration.maxnodes is not enforced the same way on the captive portal and in pfcmd manage register. This leads to a strange situation like the captive portal accepted you but when trying to register you generate an error in the log and you stay in registration VLAN.

Sep 01 21:49:27 register.cgi(0) DEBUG: got (1, 0) from authenticate() call (pf::web::web_user_authen
ticate)
Sep 01 21:49:27 register.cgi(0) INFO: calling /usr/local/pf/bin/pfcmd 'manage register 00:21:86:9e:a
b:f8 "douche" pid="1",user_agent="Mozilla 5.0  X11; U; Linux i686; en-US; r
v:1.9.0.8  Gecko 2009033100 Ubuntu 9.04  jaunty  Firefox 3.0.8",vlan="66"' (pf::web::
web_node_register)
Sep 01 21:49:28 pfcmd(0) ERROR: maxnodes met or exceeded - registration of 00:21:86:9e:ab:f8 to douc
he failed (pf::node::node_register)
Sep 01 21:49:28 pfcmd(0) INFO: VLAN isolation is enabled and manage_register is part of adjustswitch
portvlanreasons (main::generate_switchport_vlan_assignment)
Sep 01 21:49:28 pfcmd(0) INFO: 00:21:86:9e:ab:f8 is currentlog connected at 10.42.0.101 ifIndex 1001
8 in VLAN 65 (main::generate_switchport_vlan_assignment)

changing in node_register():
-my $owned_nodes = pf::person::person_nodes($pid);
+my $owned_nodes = node_pid($pid);

0001056: editing a node category with spaces in it's name fails

Category name is not put in parenthesis, thus editing it using web interface fails miserably (adding works OK).

Sample:

Error: Problems executing 'PFCMD node view category=VLAN5 - swetry order by mac asc limit 0,25'

Command not understood. (pfcmd grammar test failed at line 214.)

Error: Problems executing 'PFCMD node count category=VLAN5 - swetry'

Command not understood. (pfcmd grammar test failed at line 214.)

0001055: deleting a node breaks paging

When a node is deleted, the paging buttons disappear and plain message "(25 results)" with no navigation buttons is displayed under the node listing.

0001054: locationlog's port is not always relevant to humans

We show this port in the node lookup information but it's not always relevant to humans. But even worse, it the Cisco 3550's case they are like interchanged in an non-obvious way (48 is 19, 19 is 21, 21 is 48, etc.) which causes confusion among users.

I suggest a new mandatory interface call: getHumanReadablePort that would do the right thing per switch and maybe default to ifIndex + "might not be accurate" in pf::SNMP.

Then, in there, we could do what we want, dot1d, ifDescr, ifName, etc.

Add the mandatory interface to a new SNMP switch interface test.

0001053: restart code needs to be more aggressive if a daemon doesn't kill quickly enough

Here's a situation that happened at a client:

- a restart is issued in a high-load situation
for some reason, one daemon stays stuck and didn't finish (in our case one of the pfdhcplistener)
- the rest of the systems restarts but because that daemon is hung, the restart of the daemons of the same type (pfdhcplistener) is delayed indefinitely.

Another `pfcmd service pfdhcplistener restart` fixed it but it took days to realized that (IP to MAC stopped working).

Our restart code should handle that situation and start being more aggressive if it waited longer than 1 minute (for ex.).

Logs provided below.

0001052: pf::SNMP not properly initialized or configuration parsing problem?

This happened to me twice this week and it's very odd.

Aug 26 11:01:22 pfsetvlan(1) INFO: secureMacAddrViolation trap received on 192.168.1.67 ifIndex 1017
 for 90:e6:ba:70:e7:4b (main::handleTrap)
Aug 26 11:01:22 pfsetvlan(1) DEBUG: opening SNMP v1 read connection to 192.168.1.74 (pf::SNMP::conne
ctRead)
Aug 26 11:01:22 pfsetvlan(1) TRACE: SNMP get_request for sysLocation: 1.3.6.1.2.1.1.6.0 (pf::SNMP::c
onnectRead)
Aug 26 11:01:26 pfsetvlan(1) ERROR: error creating SNMP v1 read connection to 192.168.1.74: No respo
nse from remote host '192.168.1.74' (pf::SNMP::connectRead)
Aug 26 11:01:26 pfsetvlan(1) TRACE: SNMP get_table for extremeVlanIfVlanId: 1.3.6.1.4.1.1916.1.2.1.2
.1.10 (pf::SNMP::Extreme::_getVlanTagLookupTable)
Aug 26 11:01:26 pfsetvlan(1) TRACE: SNMP get_table for extremeFdbMacFdbTable: 1.3.6.1.4.1.1916.1.16.
1 (pf::SNMP::Extreme::getAllSecureMacAddresses)
Aug 26 11:01:26 pfsetvlan(1) TRACE: SNMP get_table for extremeFdbMacFdbStatus: 1.3.6.1.4.1.1916.1.16
.1.1.5 (pf::SNMP::Extreme::getAllSecureMacAddresses)

In plain english:
- even though trap comes from 1.67, the first read attempts are made on 1.74 by this same thread. There's no explanation for that behavior. The first time it happened to me it was the opposite situation, a trap from 1.74 and read attempts on 1.67..

PacketFence was restarted right before the new test on both occurrence..

What's going on?

0001051: radiusd restarted by PacketFence

Based on the current way we want to tackle 0001028, we will need to restart radiusd whenever the switch configuration changes.

See http://github.com/alandekok/freeradius-server/blob/v2.1.x/raddb/sql.conf [^] for details:
# Clients will ONLY be read on server startup. For performance
# and security reasons, finding clients via SQL queries CANNOT
# be done "live" while the server is running.
#

This bug is to track this change.

0001010: several SOAP issues

I experienced weird SOAP problems the other day. I was in a rush so I tried several things to fix it.

Original error:

Application failed during request deserialization: no element found at line 1, column 0, byte -1.

I pulled in: perl-LWP-UserAgent-Determined
I got rid of perl-SOAP-Lite-0.711 and installed perl-SOAP-Lite-0.710.08-1 instead.

At this point, no more deserialization problems but still 500 Internal Server Error issues.

Then I think the problem was the print statement in node_modify (performed by auto-registration).

I also got rid of the eval block around the radius call in pdp.cgi. Thats where things started to work again.

Not sure what mix of these fixed it but it was done in that order so I should try to reproduce first then go with various iteration of the topic.

One bad thing about all this is that error reporting was ridiculously missing. I had to sniff traffic to get a clue of what was going on.

0001027: freeradius needs to be configured manually

To make the world a better place, PacketFence should automatically configure radius.

This is a meta-bug that tracks individuals tasks.

I looked at cpan or webmin to find perl modules to manipulate the files but I haven't found anything. There was one module to handle the client file but it was not maintained.

0001028: adding radius clients needs to be performed from the command line

In a 802.1x, Mac Authentication or Mac Address Bypass context, the switches that communicates with PacketFence need to be added to a freeradius clients (or user don't remember) flat file.

This should be automatically done based on what is in switches.conf and a new radius shared secret parameter should be added in switches.conf.

0001034: Our freeradius module is not aware of EAP's success or failure

Any action we make in our radius module will be triggered over 802.1X no matter if EAP is successful or not. This means that an unauthenticated user can insert itself in locationlog, etc. even if he doesn't have the right credentials.

Not critical but let me give you an example where this is a problem:

Auto-registration of successfully authenticated devices. Since we can't tell if EAP was successful or not, we will always auto-register a device trying to do dot1x and in certain setup he could fall-back to MAB and be considered registered! That's bad!

0001047: missing dependency Authen::Radius for authentication::radius (conf/authentication/radius.pm)

As reported on the mailing list, radius authentication fails out of the box because the required module is not pulled in by our RPM spec file.

Authentication will fail with: "cannot validate credentials at this time.".

Try to compile the module will reveal the problem:

# perl -c conf/authentication/radius.pm
Can't locate Authen/Radius.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at conf/authentication/radius.pm line 37.

As a workaround you can install the module manually:
# yum search perl-Authen-Radius

0001049: provide a %%client-range%% variable for apache templates

This would be useful when we want to give captured users access to something specific on the PacketFence server even if they are not in the registration / isolation VLAN. So far we hardcode such values in a per-client way. Bad for network changes.

Looking at the proper variable to use, here's trapping.range description.

#
# trapping.range
#
# Comma-delimited list of address ranges/CIDR blocks that PacketFence will monitor/detect/trap on.
# Gateway, network, and broadcast addresses are ignored.

Implementation:

trapping.range would need to be translated in a format compatible with the output of pf::util::get_internal_nets()

- pf::config would populate a global
- a new sub under pf::util would output it in a %%internal-nets%% compatible fashion
- pf::services would populate the template tag by calling the new function

0001048: Proxy-support for pfcmd update ...

The update mechanism (pfcmd update...) for DHCP fingerprints and IEEE OUI's could have a way to handle a proxied access to the Internet.

We are using LWP::UserAgent internally and this can be configured to use a proxy easily.
http://search.cpan.org/~gaas/libwww-perl-5.836/lib/LWP/UserAgent.pm [^]

We would need to add parameters in pf.conf to make it clean.

0001046: Switch (aka network devices) add/edit dialog revamp

There is too much information to fill-in and most of it is optional based on the switch type and operation mode.

For example, all access parameters could be regrouped:
- SNMP (based on version)
- htaccess (renamed to XML-RPC, SOAP or Web Services?)
- cli...

Also when you chose SNMPv1 or 2c, all other v3 only parameters could be hidden.

All the various VLAN information under another tab, etc.

0001044: pfsetvlan is memory hungry (217Mb on a normal, inactive setup)

There is definitely something grossly inefficient in there. A little run in the debuger could give us a clue.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                
                    
 2760 root      15   0  480m 217m 1104 S  0.0 43.3   0:02.45 pfsetvlan

0001045: extension points for pf::web and cgi-bin files

These files changes a lot from install to install due to customization. And the RPM upgrade process wipes them clean.

We should provide an extension point ability like we do for pf::vlan and pf::radius (in trunk). And our templates subsystem should be improved to better cope with change and future upgrades.

0001040: PHP errors when clicking on NODE

Error: Problems executing 'PFCMD node view all order by mac asc limit 0,25'

/usr/local/pf/bin/pfcmd line 2004 (0000001) Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/bin/pfcmd line 2004. at /usr/local/pf/bin/pfcmd line 2004 main::print_results('node_view_all', 'all', 'orderby', 'order by mac asc', 'limit', 'limit 0,25') called at /usr/local/pf/bin/pfcmd line 1872 main::command_param('node') called at /usr/local/pf/bin/pfcmd line 173 main::__ANON__() called at /usr/local/pf/bin/pfcmd line 203

0000965: Admin Portal - Granular Access Control

I had a client request that for their PF installation that some staff only have access to certain areas of the Admin portal.

The Network administrator desired total access for their staff. And, that help-desk staff only need access to the Node pages to register company laptops and and deal with daily operational issues.

Richard Danielli
President, eSubnet

0001032: Interface between nessus and packetfence needs improvement

Right now, we run the CLI nessus client by hand and perform only file existence validation.

Several cases were experimented that we could handle with some regexp and status checking.

Maybe there's an API or another approach that is recommended.

Or, being pragmatic here, maybe we should provide a CLI nessus scan test in addons/ that would exercise the right piece of code and send everything to STDOUT so people can troubleshoot by themselves.

0001043: no documentation for configuration files outside of pf.conf / pf.conf.defaults

Find a way to provide documentation for these that match the features of the documentation.conf approach which are:

- parsable and outputable by the CLI
- parsable and outputable by the Web interface

0000874: pfcmd_vlan should log at the same place as everyone else

making wireless a lot harder to troubleshoot because deassociate traps leave no clue to what happened

solution: port bin/pfcmd_vlan to use conf/log.conf like everyone else!