I've managed to setup Zenoss Core 2.3.0 on FreeBSD 7 without too many issues. I'm now trying to test out SNMP traps but I'm having no luck with zentrap.

Zenoss is being hosted in a jail (and has access to creating raw sockets, if that matters). Zentrap starts successfully and can be seen listening on port 162 with netstat. Using tcpdump I'm able to see the SNMP trap passing through:

snmptrap -v 2c -c public 10.10.10.10 '' 1.3.6.1.4.1.2021.991 1.3.6.1.2.1.1.6 s "Test Device"

(taken from admin pages) results in

13:58:10.084780 IP 10.10.9.9.52219 > 10.10.10.10.162:  V2Trap(81)  .1.3.6.1.2.1.1.3.0=113646036 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2021.991 .1.3.6.1.2.1.1.6="Test Device"[|snmp]

zentrap.log (-v 10):

2008-12-10 13:55:12 DEBUG zen.ZenTrap: run
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Connecting to localhost:8789
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Logging in as admin
2008-12-10 13:55:12 INFO zen.ZenTrap: Connected to ZenHub
2008-12-10 13:55:12 DEBUG zen.ZenTrap: setting up services EventService
2008-12-10 13:55:12 DEBUG zen.ZenTrap: chaining getInitialServices with d2
2008-12-10 13:55:12 DEBUG zen.ZenTrap: callback after getting service EventService
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Calling connected.
2008-12-10 13:55:12 DEBUG zen.ZenTrap: connected
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Sending event {'severity': 0, 'component': 'zentrap', 'agent': 'zentrap', 'summary': 'started', 'manager': 'localhost', 'device': 'localhost', 'eventClass': '/App/Start'}
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Sending event {'severity': 0, 'component': 'zentrap', 'agent': 'zentrap', 'summary': 'zentrap started', 'manager': 'localhost', 'device': 'localhost', 'eventClass': '/App/Start'}
2008-12-10 13:55:12 INFO zen.ZenTrap: started
2008-12-10 13:55:12 INFO zen.ZenTrap: fetching default RRDCreateCommand
2008-12-10 13:55:12 INFO zen.ZenTrap: getting threshold classes
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Loading classes ['Products.ZenModel.MinMaxThreshold']
2008-12-10 13:55:12 INFO zen.ZenTrap: getting collector thresholds
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zeneventlog cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zenmodeler cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zenperfsnmp cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zenping cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zenprocess cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.thresholds: Updating threshold ('zenwin cycle time', ('localhost', ''))
2008-12-10 13:55:12 DEBUG zen.ZenTrap: Sending event {'manager': 'localhost', 'timeout': 180, 'device': 'localhost', 'eventClass': '/Heartbeat', 'component': 'zentrap', 'agent': 'zentrap'}

I have also tried adding 'trapsink localhost' to /usr/local/etc/snmp/snmpd.conf and then restarted snmpd, but that is not reported by zentrap either.

Does anyone have any ideas that could help me locate the problem?

Edit: Well, I've managed to track down the issue myself and everything seems to be working well now, though I'd like to more details about the specific cause, if anyone can provide insight

In zentrap.py we have the following check on line 118:

if transport.family != socket.AF_INET: return

transport.family was 528 for me where socket.AF_INET is 2. Commenting out the check allowed zentrap to function properly. Is this related to sockets being rewritten when passed to jails? What is 528 exactly? Maybe this should be documented for FreeBSD installs?