Re: Call for testers: wireless module for bsnmpd(1)

Hi all,

Thanks for the feedback and comments.
I've uploaded an updated tarball at
http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100719-01.tar .

On Sun, Jul 11, 2010 at 8:23 PM, Gabor PALI <pgj_at_freebsd.org> wrote:
>
> A few comments:
>
> - I think there should be bsnmpd(1) instead of bsnmpd(8) in the NAME
> section of snmp_wlan(3).

Fixed in the latest sources.

> - It creates an "/usr/lib/snmp_wlan.so." file which seems a bit strange
> for me.

Yes, indeed - this weird naming happens when an bsnmp module is built
outside the source tree and SHLIB_MAJOR is not defined - the
<bsd.snmpmod.mk> file names a module based on
snmp_${MOD}.so.${SHLIB_MAJOR} - this should be resolved once the
module is made part of the source tree.

> - It produces the following on my machine:
>
> snmpd[3871]: SNMP wlan loaded wlan_wlan_acl module
> snmpd[3871]: send: Connection refused
> snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
> snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
> snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
> snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
>

This is because ioctl(wname, IEEE80211_IOC_MACCMD, ...) returns EINVAL
when no MAC ACL policy has been configured in the interface - should
be resolved in the latest sources.

>

On Wed, Jul 14, 2010 at 5:40 AM, Adrian Chadd <adrian_at_freebsd.org> wrote:
> Howdy!
>
> Compiling this on MIPS gives this error:
>
> Warning: Object directory not changed from original /usr/home/adrian/w/snmp_wlan
> cc -fpic -DPIC -O -pipe -EB -msoft-float -G0 -mno-dsp -mabicalls
> -DSNMPTREE_TYPES -g -I. -std=gnu99 -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign -c wlan_sys.c -o wlan_sys.So
> cc1: warnings being treated as errors
> wlan_sys.c: In function 'wlan_get_scan_results':
> wlan_sys.c:2221: warning: cast increases required alignment of target type
> wlan_sys.c: In function 'wlan_get_peerinfo':
> wlan_sys.c:2713: warning: cast increases required alignment of target type
> *** Error code 1
>

In the latest sources, I replaced the cast with memcopy's which shold
fix the errors, but I haven't tested it since I don't have a MIPS
platform to test. It'll be good to know the errors have been actually
fixed.

>

On Wed, Jul 14, 2010 at 6:16 AM, Adrian Chadd <adrian_at_freebsd.org> wrote:
> I've already emailed you about the alignment warnings.
>
> The returned error value is an SNMPv2 error (SNMP_ERR_INCONS_VALUE)
> which causes v1 requests to error out. Is it at all possible to return
> something valid if a v1 request is made?

The SNMP_ERR_INCONS_VALUE is only returned in responce to SET requests
when the value requested for SET is not valid - in such case if the
packet is SNMPv1 packet the SNMP agent should itself replace any
SNMPv2 error code with a corresponding SNMPv1 code (e.g
SNMP_ERR_BADVALUE should be returned instead of
SNMP_ERR_INCONS_VALUE); could you please specify your agent config and
what exact client command and aparameters are you issueing to produce
the problem.
>
> snmpwalk'ing to inspect what -is- returned fails, even when querying in v2 mode:
>
> BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nRIFS."wlan0" = INTEGER: false(2)
> BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nShortGI."wlan0" = INTEGER: false(2)
> BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" = INTEGER: disabled(1)
> Error in packet.
> Reason: (genError) A general failure occured
> Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0"
>
> The daemon logs errors when features aren't supported by the
> underlying driver (eg querying TDMA stats on a non-TDMA interface.)
> This may hide any actual underlying issues.

This shouldn't be the case - the module reads each wlan parent
capabilities and a relevant setting is only attempted in the kernel,
only if the parent/wlan iterface capabilities indicate it is
supported. I'm trying to test it on my system, but I don't see a
problem. Again, could you please specify your kernel config, hardware
wireless card, FreeBSD vsersion and the commands that you're running
to create the problem.

>
> It isn't immediately clear which parameters are related to station and
> which are related to hostap. Eg, wlanIfaceBeaconMissedThreshold. Is
> that the station threshold or the AP threshold? Would it be worthwhile
> creating separate branches for different stat types (station, ap, TDMA
> AP, dot11n stuff, etc, etc?) rather than whacking it all together in
> one tree?
>

The description of each object (and specifically under the
wlanIfaceConfigTable table) in the BEGEMOT-WIRELESS-MIB.txt specifies
whether the relevant object is meaningfull for interfaces in station
or ap mode. I've thought about splitting the configuration in separate
tables, but then there seven modes, not only station and host ap, and
many objects are relevant for interfaces operating in any mode, so I
decided to keep them in a common table.

> I've not seen binary string indexing values on tables before. Eg:
>
> BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'...$..'.61 =
> STRING: 0:11:24:c7:e4:3d
> BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'..#2'.'.219 =
> STRING: 0:23:32:27:fc:db
> BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'...$..'.61 =
> INTEGER: 2
> BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'..#2'.'.219
> = INTEGER: 1
>
> Is that going to be portable to different utilities? Some of the code
> I've seen (and written!) expect numeric table indexes rather than what
> I see above.
>

No, it's not uncommon to have binary strings as indexes, as it is also
not uncommon to have several indexes for an entry - for example
dot1dTpFdbTable (BRIDGE-MIB, RFC 4188) is indexed by the entry's MAC
address, mgmdHostSrcListTable (MGMD-STD-MIB, RFC 5519) is indexed by
address type (IPv4 or IPv6), a multicast group address, a interface
index and a host ip address (again either IPv4 or IPv6). Many other
examples may be given in standartized MIBs and no software should rely
on having SNMP tables indexed by a single integer index.

cheers,
Shteryana