Re: Call for testers: SNMPv3 support for bsnmpd(1)
Hi all, OK, I discovered and fixed several v3 bugs while testing this config. 1) A regresion introduced with SVN r256678 breaking parsing of v3 authentication part of a PDU - this is only in current; stable should be fine; I've uploaded a patch here - http://people.freebsd.org/~syrinx/snmp/libsnmp-v3-auth-20140403-01.diff 2) A bug in decoding string indexes in snmp_target(3), thus causing bsnmpd(1) to not send v3 notifications properly and two missing return statements which could lead to abort() in case of a rollback - this has never worked in the svn tree, I am not sure why the patch didn't make it - a patch is available here - http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff, it was generated against head, but should apply cleanly against stable too - to patch the module #cd #fetch http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff #cd /contrib/bsnmp #patch < snmp_target-20140403-01.diff #cd ../../usr.sbin/bsnmpd/modules/snmp_target/ #make && make install 3) A problem with old SNMP engine time being returned to the client in some cases (relevant to v3 only again) which would cause subsequent PDUs comming from the same client to be considered out-of-time-window and discarded - patch is available here - http://people.freebsd.org/~syrinx/snmp/bsnmpd-engine-time-20140403-01.diff 4) There is also a problem with the handling of the connected UDP sockets - e.g. if the client listening for the trap has not been available for sometime, the socket error is not cleared until the first send() - causing "snmpd[8573]: send: Connection refused" messages in syslog even though the trap was successfully send - an old patch (pre-v3 sources) is available here - http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff, I'll update it against head too Comments, reviews and test reports are very welcome. Now, the needed configuration for encrypted traps - 1) bsnmpd(1) part #First v3 SNMP Engine value should be set, e.g. engine := 0x80:0x10:0x08:0x10:0x80:0x25 snmpEngineID = $(engine) #USM module should be enabled and at least one user with proper credentials created user1 := "bsnmp" user1passwd := 0x22:0x98:0x1a:0x6e:0x39:0x93:0x16:0x5e:0x6a:0x21:0x1b:0xd8:0xa9:0x81:0x31:0x05:0x16:0x33:0x38:0x60 # # SNMPv3 User-based security module - must be loaded for SNMPv3 USM # begemotSnmpdModulePath."usm"= "/usr/lib/snmp_usm.so" # Definition of user "bsnmp" with password "bsnmptest" usmUserStatus.$(engine).$(user1) = 5 usmUserAuthProtocol.$(engine).$(user1) = $(HMACSHAAuthProtocol) usmUserAuthKeyChange.$(engine).$(user1) = $(user1passwd) usmUserPrivProtocol.$(engine).$(user1) = $(AesCfb128Protocol) usmUserPrivKeyChange.$(engine).$(user1) = $(user1passwd) usmUserStatus.$(engine).$(user1) = 1 #Definition of a Notification target where traps will be sent with the credentials of $user1 # # SNMPv3 Notification Targets module # begemotSnmpdModulePath."target"= "/usr/lib/snmp_target.so" tag:= "test" snmpNotifyRowStatus.$(tag) = 4 snmpNotifyTag.$(tag) = $(tag) # # Specify the target parameters for the notifications - send with the credentials # of user $user1 # snmpTargetParamsRowStatus.$(tag) = 5 snmpTargetParamsMPModel.$(tag) = $(MPmodelSNMPv3) snmpTargetParamsSecurityModel.$(tag) = $(securityModelUSM) snmpTargetParamsSecurityName.$(tag) = $(user1) snmpTargetParamsSecurityLevel.$(tag) = $(authPriv) snmpTargetParamsRowStatus.$(tag) = 1 # # Define the notifications' target address - port 162 on localhost # snmpTargetAddrRowStatus.$(tag) = 5 snmpTargetAddrTAddress.$(tag) = 0x0a:0x0:0x0:0x01:0x0:0xa2 # hexstring representing 10.0.0.119 in 4 octets and port 162 in two octets snmpTargetAddrTagList.$(tag) = "test notification" snmpTargetAddrParams.$(tag) = $(tag) snmpTargetAddrRowStatus.$(tag) = 1 2) To receive the traps with net-snmp's snmptrapd put the following coonfiguration in /etc/snmp/snmptrapd.conf createUser -e 0x801008108025 bsnmp SHA "bsnmptest" AES "bsnmptest" authuser log bsnmp and start it e.g. #snmptrapd -f -C -c /etc/snmp/snmptrapd.conf -Le cheers, Shteryana On Tue, Apr 1, 2014 at 2:47 PM, Marciano, Anthony wrote: > Thank Harti. > > Tony > > -Original Message- > From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] > Sent: Tuesday, April 01, 2014 2:06 AM > To: Marciano, Anthony > Cc: syr...@freebsd.org; Bjoern A. Zeeb; freebsd-current@freebsd.org; > tomaro...@gmail.com > Subject: RE: Call for testers: SNMPv3 support for bsnmpd(1) > > On Mon, 31 Mar 2014, Marciano, Anthony wrote: > > MA>Currently, we are just looking to monitor standard objects such as > MA>interfaces and send traps accordingly. Would it be possible to > MA>provide a trap example of what needs to be added to the snmpd.config > MA>file to monitor an object and have it sent via V3? > MA> > MA>I've searched for this information and read through various RFCs but > MA>have not discovered any bsnmpd specific trap syntax and/or examples. > > Well, bsnmp can send only the standard traps curren
Re: Call for testers: SNMPv3 support for bsnmpd(1)
Hi all, The modules implementing SNMPv3 in bsnmpd(1) are snmp_usm(3), snmp_vacm(3) and snmp_target(3) all based on standard RFC. snmp_usm(3) handles v1/v2c and v3 user configuration including user name, auth/priv protocol type and relevant keys. snmp_vacm(3) allows restricting users to specific parts of the MIB tree, and snmp_target(3) allows configuring destination hosts for SNMP traps and notifications. To get SNMPv3 traps, snmp_target(3) module needs to be loaded - the default /etc/snmpd.config file contains commented out example configuration, looking at snmp_target(3) man page should give some hints too - basicly you need to set at least one entry in snmpTargetAddrTable containing relevant connection parameters for the host that should receive the notifications, one snmpTargetParamsTable specifying the USM user credentials that should be used and one entry in snmpNotifyTable specifying for which tag whether a trap or notification should be sent. RFC 3413 also contains examples on how to fill in the SNMP-NOTIFICATION-MIB . The standard SNMPv3 modules are somewhat too complicated for most configurations though, so I've had the idea to implement a private Begemot module with much simpler configuration that will fill automatically the standard MIB trees with v3 user configuration but I haven't gotten to actually implementing it yet. cheers, Shteryana On Mon, Mar 31, 2014 at 4:07 PM, Bjoern A. Zeeb wrote: > On 31 Mar 2014, at 12:14 , Marciano, Anthony wrote: > >> Thanks Harti. >> >> I did get the basic V3 configuration working in that I could walk the mib >> using authorization and encryption. >> >> If Shteryana has the time, maybe he would be able to provide me with some >> information needed to configure and test V3 traps. >> >> I don't have his e-mail so if you could forward this to him I would >> appreciate it. > > I’ve put her on Cc: > > >> -Original Message- >> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] >> Sent: Sunday, March 30, 2014 8:22 AM >> To: Marciano, Anthony >> Cc: freebsd-current@freebsd.org; tomaro...@gmail.com >> Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1) >> >> Hi Anthony, >> >> On Fri, 28 Mar 2014, Marciano, Anthony wrote: >> >> MA>I've been tasked to get bsnmpd V3 working for my company. The post >> MA>referenced in the subject above gave me some insights but I'm still >> MA>stuck and was wondering if you would take the time to answer some >> MA>questions. I'm a snmpV3 newbie and have never worked with bsnmpd. I >> MA>have worked minimally with net-snmp V2. >> MA> >> MA>First, is there a document listing all of the configuration options >> MA>in the snmpd.confg file? It appears to differ from other packages >> MA>such as net-snmp. >> >> >> I can answer only this question - I'm not very familiar with SNMPv3, but >> Shteryana should be able to help. >> >> No, there is no document with all the setting. The reason is simple: the >> config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or >> module load. The file is segmented into sections by %name lines with all >> segments having the same name beeing put together. At the begin of the file >> there is an implicit %snmpd line. >> >> Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, >> all other sections are executed when the corresponding module is beeing >> loaded or on SIGHUP if that module is already loaded when the SIGHUP occures. >> >> So any writeable or creatable MIB variable can be put into the configuration >> file. >> >> harti >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > — > Bjoern A. Zeeb ? ??? ??? ??: > '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? > ?? ?? ? ', ? ?, "??? ? ?? ?", ?.??? > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Call for testers: SNMPv3 support for bsnmpd(1)
Dear all, I am happy to announce that work on SNMPv3 support for bsnmpd(1) is now completed and ready for testing. I want to thank the FreeBSD Foundation for funding this work. A quick how-to get started with the changes bsnmpd(1) follows. The patch against FreeBSD current sources is available under http://people.freebsd.org/~syrinx/snmp/svn-snmpd-20101028-02.diff. To compile && install the sources #cd #fetch http://people.freebsd.org/~syrinx/snmp/svn-snmpd-20101028-02.diff #mkdir contrib/bsnmp/snmp_vacm && mkdir contrib/bsnmp/snmp_usm && mkdir usr.sbin/bsnmpd/tools && mkdir usr.sbin/bsnmpd/tools/bsnmptools && mkdir usr.sbin/bsnmpd/tools/libbsnmptools && mkdir usr.sbin/bsnmpd/modules/snmp_vacm && mkdir usr.sbin/bsnmpd/modules/snmp_usm #patch < svn-snmpd-20101028-02.diff # The patch contains all changes made to support SNMPv3 in bsnmpd(1) and also bsnmpdtools(1) that were initially developed during Google's Summer of Code 2005 and later together with bsnmpd(1) enhanced to support SNMPv3 encryption and authentication. After the implemented changes bsnmpd(1) should be compatible with old configuration files and unless explicitly specified in its configuration file, it should also retain its current behavior. By default, all SNMP versions are enabled, however as there are no SNMPv3 USM users defined, SNMPv3 packets are silently dropped. To be able to configure SNMPv3 users View-based access rules one needs to load two additional modules in bsnmpd(1) that are not loaded by default - snmp_usm(1) and snmp_vacm(1). This is done by adding the following lines in bsnmpd.config # SNMPv3 User-based security module - must be loaded for SNMPv3 USM begemotSnmpdModulePath."usm" = "/usr/lib/snmp_usm.so" # SNMPv3 View-based Access Control module begemotSnmpdModulePath."vacm" = "/usr/lib/snmp_vacm.so" The objects from SNMP-FRAMEWORK-MIB (snmpEngineID, snmpEngineBoots, snmpEngineTime and snmpEngineMaxMessageSize) are mandatory for an SNMP agent compliant with the SNMPv3 Framework and are supported by bsnmpd(1). A administrative value for the snmpEngineID may be specified via the daemon's configuration file , for example # The SNMP engine ID engine := 0x80:0x00:0x1f:0x88:0x80:0x91:0x04:0xc9:0x0f:0x67:0xe9:0x5b:0x4c snmpEngineID= $(engine) If not present, a default value is assigned to the object based on host id, where bsnmpd(1) is running. SNMPv1 and SNMPv2 communities definitions in the config file have not changes. Definition of SNMPv3 users is done in the usm section of the configuration file, for example %usm NoAuthProtocol := 1.3.6.1.6.3.10.1.1.1 HMACMD5AuthProtocol := 1.3.6.1.6.3.10.1.1.2 HMACSHAAuthProtocol := 1.3.6.1.6.3.10.1.1.3 NoPrivProtocol := 1.3.6.1.6.3.10.1.2.1 DESPrivProtocol := 1.3.6.1.6.3.10.1.2.2 AesCfb128Protocol := 1.3.6.1.6.3.10.1.2.4 user1 := "test" user4 := "testmd5" user6 := "testaes" user4passwd := 0xa4:0x27:0x99:0xe2:0x4b:0x32:0x12:0xec:0xe5:0xf4:0xac:0x83:0x1f:0x75:0xbb:0x59 user6passwd := 0x1b:0x07:0x9b:0x0b:0x75:0xb7:0xab:0xc7:0x77:0x6a:0x1a:0x24:0x02:0x0c:0x3a:0x87:0x4c:0x80:0x80:0x04 # SNMPv3 user with name "test", no authentication, no privacy usmUserStatus.$(engine).$(user1) = 5 usmUserAuthProtocol.$(engine).$(user1) = $(NoAuthProtocol) usmUserPrivProtocol.$(engine).$(user1) = $(NoPrivProtocol) usmUserStatus.$(engine).$(user1) = 1 # SNMPv3 user with name "testmd5", MD5 message digests, no privacy usmUserStatus.$(engine).$(user4) = 5 usmUserAuthKeyChange.$(engine).$(user4) = $(user4passwd) usmUserPrivProtocol.$(engine).$(user4) = $(NoPrivProtocol) usmUserStatus.$(engine).$(user4) = 1 # SNMPv3 user with name "testaes", SHA256 message digests, AES encryption usmUserStatus.$(engine).$(user6) = 5 usmUserAuthProtocol.$(engine).$(user6) = $(HMACSHAAuthProtocol) usmUserAuthKeyChange.$(engine).$(user6) = $(user6passwd) usmUserPrivProtocol.$(engine).$(user6) = $(AesCfb128Protocol) usmUserPrivKeyChange.$(engine).$(user6) = $(user6passwd) usmUserStatus.$(engine).$(user6) = 1 The password of each user specified in the configuration file is the localized password for the current snmpEngineId and may be calculated via bsnmpget(1), for example > setenv | grep SNMP SNMPUSER=testaes SNMPPASSWD=shteryana SNMPAUTH=sha SNMPPRIV=aes > bsnmpget -v 3 -D -K -o verbose Engine ID 0x80001f88809104c90f67e95b4c Boots : 145 Time : 1 Localized keys for testaes SHA : 0x1b079b0b75b7abc7776a1a24020c3a874c808004 AES : 0x1b079b0b75b7abc7776a1a24020c3a87 > Supported authentication options are MD5 and SHA256 or none, and supported encryption options are DES and AES. If encryption is used, authenticaiton is also mandatory. Unless the snmp_vacm(1) module is loaded, all users have access to the values of all MIB objects available in bsnmpd(1). To allow only access to ceratain parts of the MIB subtrees supported in bsnmpd(1) one should use the snmp_vacm(3) module. The module is configured in the %vacm section of the snmpd.config file. To properly configu
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 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 t
Call for testers: wireless module for bsnmpd(1)
Hi all, As some of you may know, I've been awarded a grant by the FreeBSD Foundation to make several improvements to FreeBSD's SNMP daemon. The first part of the project - a module for monitoring wireless networking under FreeBSD - is now completed and I'd really appreciate if I could get some help in more extensive testing in a wider range of wireless networking usage scenarios. A tarbal of the latest sources of the module is available under http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100710-01.tar. To compile and install the module - #fetch http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100710-01.tar #tar -xvf snmp_wlan-20100710-01.tar #cd snmp_wlan #make #make install (as root) To enable loading of the module in bsnmpd(1), one should add the following line to bsnmpd(1) config file (usually /etc/snmpd.config) - begemotSnmpdModulePath."wlan" = "/usr/lib/snmp_wlan.so" More details on how the module works may be found in the snmp_wlan(3) man page and in the private BEGEMOT-WIRELESS-MIB the module implements (installed under /usr/share/snmp/mibs/BEGEMOT-WIRELESS-MIB.txt). Know issues currently are that BITS types are not always handled properly, and TX rates may not always be properly set - I am working on fixing those. All feedback is wellcome - bug reports, requests for features to be included in future versions of the module, code style and bug fix patches. I will be glad to help resolve any problems that may arise while installing/working with the module and answer any questions you may have. Thanks! cheers, Shteryana ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Virtualbox
Hi, On what kind of CPU are you trying to get VirtualBox to work? In some cases VirtualBox requires VT-x/AMD-V support in the CPU to work - you might want to make sure your CPU supports that and it's actually on. Otherwise, I've see the same errors trying to get VirtualBox to work on Intel Atom N270 with CURRENT. cheers, Shteryana On Tue, Feb 23, 2010 at 6:20 PM, Ian FREISLICH wrote: > Hi > > Has anyone managed to make Virtualbox work on 9-Current? Since > installing 3.1.2-OSE VMs, all brand new, abort on startup. > > The last part of the log seems pertinent: > > 00:00:15.481 !!Assertion Failed!! > 00:00:15.481 Expression: paPages[i].Phys != 0 && paPages[i].Phys != > NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) > 00:00:15.481 Location : > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) > int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const > char*, RTGCPTR64*) > 00:00:15.482 i=0x0 Phys= Heap > > Does anyone have any ideas? > > Ian > > > -- > Ian Freislich > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
