From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 19:26:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16FE81065675; Mon, 19 Jul 2010 19:26:30 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBE48FC14; Mon, 19 Jul 2010 19:26:28 +0000 (UTC) Received: by fxm13 with SMTP id 13so2633863fxm.13 for ; Mon, 19 Jul 2010 12:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=jC7qF01OKQIeqY9e84EGO//fnZeChV/fNhWH2t4tiRo=; b=eho9dDxGBlHS8FrSWkLqyRjWJzzB/ZNQ8WowdN5NyeCDOtN+tauHqFfp1mwezDyIrj pFnZOQDikWIxaAVpgF2x1aoBylF0PaBHqvSJjbukvhPnOlAfIs/7YBU7RoVl++PQuxbv TvTlCo095K69exMloez0vJq/uPnBE7uAAmDlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jnYzLRqbO4Su3nqYxLXWsIvBwV+SKL3o4zdX3TMdwftJ7hmU1rQyvDkkwubW1Ek7up Aly4wauM60VDI0rsJXdxKgRk9mijgfYbar8CwnKuEtIBlstcSVTxEXgFqFEf7PL6eoy6 lbt+0ZrxTqQGNSWJ47qt4cOLNWyZx33vvAniY= MIME-Version: 1.0 Received: by 10.223.104.148 with SMTP id p20mr4272156fao.11.1279567587972; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) Sender: shteryana@gmail.com Received: by 10.223.113.10 with HTTP; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 22:26:27 +0300 X-Google-Sender-Auth: -ox1kBeG0n3l5n9nfAxPr3JCgeM Message-ID: From: Shteryana Shopova To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@FreeBSD.org" , freebsd-current@freebsd.org Subject: Re: Call for testers: wireless module for bsnmpd(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 19:26:30 -0000 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 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 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 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 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