Hi Niels, thank you for help.
Your patch was not complete, but I think, my version is.
All test are running as before, but this part is not tested!
The error occurs only on little endian machines.
But now, it should work on either endian.
IMHO, there should be a test for the snmpTargetAddrTable and all supported
TDomain's.
My test was with this trap configuration:
trapsess -v 2c -c public tcp:127.0.0.1:162
trapsess -v 2c -c public tcp6:[::1]:162
trapsess -v 2c -c public udp:127.0.0.1:162
trapsess -v 2c -c public udp6:[::1]:162
# targetAddr NMS .1.3.6.1.6.1.1 0x7f00000100a2 1500 3 "NMS" NMS 3 1
# targetAddr NMSV6 .1.3.6.1.2.1.100.1.2 0x00000000000000000000ffffc0a8010100a2
1500 3 "NMSV6" NMSV6 3 1
Claus-Kleins-MacBook-Pro:net-snmp clausklein$ snmptable -Cibw 99 localhost
snmpTargetAddrTable
SNMP table: SNMP-TARGET-MIB::snmpTargetAddrTable
index TDomain
\'NMS\' SNMPv2-TM::snmpUDPDomain
\'NMSV6\' TRANSPORT-ADDRESS-MIB::transportDomainUdpIpv6
\'internal0\' TRANSPORT-ADDRESS-MIB::transportDomainTcpIpv4
\'internal1\' TRANSPORT-ADDRESS-MIB::transportDomainTcpIpv6
\'internal2\' SNMPv2-TM::snmpUDPDomain
\'internal3\' TRANSPORT-ADDRESS-MIB::transportDomainUdpIpv6
SNMP table SNMP-TARGET-MIB::snmpTargetAddrTable, part 2
index TAddress Timeout
RetryCount
\'NMS\' "7F 00 00 01 00 A2 " 1500
3
\'NMSV6\' "00 00 00 00 00 00 00 00 00 00 FF FF C0 A8 01 01 00 A2 " 1500
3
\'internal0\' "7F 00 00 01 00 A2 " 1000
5
\'internal1\' "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 A2 " 1000
5
\'internal2\' "7F 00 00 01 00 A2 " 1000
5
\'internal3\' "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 A2 " 1000
5
SNMP table SNMP-TARGET-MIB::snmpTargetAddrTable, part 3
index TagList Params StorageType RowStatus
\'NMS\' NMS NMS nonVolatile active
\'NMSV6\' NMSV6 NMSV6 nonVolatile active
\'internal0\' internal0 internal0 readOnly active
\'internal1\' internal1 internal1 readOnly active
\'internal2\' internal2 internal2 readOnly active
\'internal3\' internal3 internal3 readOnly active
Claus-Kleins-MacBook-Pro:net-snmp clausklein$
fix-byteorder-targetaddrmib.diff
Description: Binary data
//Regards Claus On 08.10.2013, at 14:54, Niels Baggesen wrote: > Den 03-10-2013 11:37, Claus Klein skrev: >> what is the reason for different byteorder of port configuration >> with snmpUDPDomain and transportDomainUdpIpv6 in snmpTargetAddrTable? > > This is a bug, not a feature > >> It is not clear to me, which port number is really used with this >> configuration. > > snmpd actually uses the correct port, it is only the address shown in the > snmpTargetAddrTable that is wrong. > > You might try the attached patch, which I hope fixes it without adding new > bugs > > /Niels > > -- > Niels Baggesen - @home - Århus - Denmark - [email protected] > The purpose of computing is insight, not numbers --- R W Hamming > <target.patch>
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
