RE: MAC address not retrieved by Win32 client

2004-06-21 Thread Fernández Piñas, David

Hi, are you sure that it is the correct OID ?

Try a tool that is able to perform an SNMP walk. You can also use Net-SNMP on Windows. 
See README.win32 file.

I tried the OID you gave on my Windows workstation and Net-snmp is able to retrieve 
MAC address of the machine, as you can see:

C:\snmpget -c public localhost .1.3.6.1.2.1.2.2.1.6.2
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: RFC1213-MIB::ifPhysAddress.2

C:\snmpwalk -c public localhost RFC1213-MIB::ifPhysAddress
RFC1213-MIB::ifPhysAddress.1 = 
RFC1213-MIB::ifPhysAddress.16777219 = Hex-STRING: 00 01 03 11 F8 D6

Ethernet adaptador Conexión de área local:

Descripción . . . . . . . . . . . . . : 3Com 3C920 Integrated Fast Ethernet Controller 
(3C905C-TX Compatible)
Dirección física. . . . . . . . . . . : 00-01-03-11-F8-D6



 -Original Message-
 From: Vic Berdin
 Sent: Monday, June 21, 2004 8:51 AM
 To: [EMAIL PROTECTED]
 Subject: MAC address not retrieved by Win32 client
 
 
 Hi,
 
 
 I've setup net-snmp (v5.1.1) on an RH7.3 machine. I 
 tried to retrieve information from it via a Win32 client 
 using the tool snmputilg.exe. It's nice to see that 
 common values such as sysUPTime, sysContact, sysName, 
 sysLocation, etc were retrieved successfully.
 
 However, I noticed that MAC (physical) addresses 
 (OID .1.3.6.1.2.1.2.2.1.6.2, etc) were NOT retrieved by 
 the tool.
 
 I'm not sure if this is a problem with net-snmp or the 
 Win32 tool (snmputilg.exe) I'm using. Can anyone:
 
 1. ...explain why MAC addresses can't by retrieved from 
net-snmp (if it's net-snmp's fault)
 
 2. ...or point to me to a more complete/stable (yet FREE)
Win32 snmp test suit that can prove that net-snmp can
provide MAC address queries.
 
 
 TIA and Best regards, 
 Vic
 
 
 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.672 / Virus Database: 434 - Release Date: 4/28/2004
 
 
 
 ---
 This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
 Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
 Conference, June 28 - July 1 at the Moscone Center in San 
 Francisco, CA
 REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
 Code NWMGYKND
 ___
 Net-snmp-users mailing list
 [EMAIL PROTECTED]
 Please see the following page to unsubscribe or change other options:
 https://lists.sourceforge.net/lists/listinfo/net-snmp-users
 
---
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene 
información de carácter confidencial exclusivamente dirigida a su destinatario o 
destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la 
previa autorización escrita de Indra. En el caso de haber recibido este correo 
electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante 
reenvío a la dirección electrónica del remitente.

The information in this e-mail and in any attachments is confidential and solely for 
the attention and use of the named addressee(s). You are hereby notified that any 
dissemination, distribution or copy of this communication is prohibited without the 
prior written consent of Indra. If you have received this communication in error, 
please, notify the sender by reply e-mail


---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


Re: MAC address not retrieved by Win32 client

2004-06-21 Thread Dave Shield

 However, I noticed that MAC (physical) addresses 
 (OID .1.3.6.1.2.1.2.2.1.6.2, etc) were NOT retrieved by 
 the tool.

It would be a lot easier to advise you as to the cause
of this problem if you'd included some indication as to
what you'd actually tried.
  It might be that you're asking for the wrong OIDs
(as David suggests).   Or it may be a problem with
the agent configuration.

Have you read the FAQ?
In particular, see the entry:
   I can see the system group, but nothing else.  Why?

Dave



---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


RE: MAC address not retrieved by Win32 client

2004-06-21 Thread Vic Berdin
Hi David, everyone,

 -Original Message-
 From: Dave Shield [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 21, 2004 4:52 PM
 To: Vic Berdin
 Cc: [EMAIL PROTECTED]
 Subject: Re: MAC address not retrieved by Win32 client 
 
 However, I noticed that MAC (physical) addresses 
 (OID .1.3.6.1.2.1.2.2.1.6.2, etc) were NOT retrieved by 
 the tool.

 It would be a lot easier to advise you as to the cause
 of this problem if you'd included some indication as to
 what you'd actually tried.
  It might be that you're asking for the wrong OIDs
 (as David suggests).   Or it may be a problem with
 the agent configuration.

 Have you read the FAQ?

Yep I did, prior to posting.

 In particular, see the entry:
I can see the system group, but nothing else.  Why?

Here are more details:
If I will run `snmpwalk` from my Linux machine, I can definitely
see the line:

RFC1213-MIB::ifPhysAddress.2 = Hex-STRING: 00 90 73 00 02 F5

as one of the results to my snmpwalk command. Then if I will use
`snmptranslate -On RFC1213-MIB::ifPhysAddress.2`, the output is
indeed: 

.1.3.6.1.2.1.2.2.1.6.2. 

The same OID that comes out NULL from snmputilg.exe tool, but the
value is NULL.
It's also highly possible that snmputilg does not support 
physical addresses (*shrugs*).
Btw, what other FREE Win32 client tools that you guys use, in order 
to get/set information to your net-snmp servers?

Also, here's my test conf, please feel free to send flames:

#-
#   sec.name  source  community
com2sec local 172.0.0.1   public
com2sec mynetwork 0.0.0.0/0   public


# Second, map the security names into group names:

#   sec.model  sec.name
group MyRWGroup v1 local
group MyRWGroup v2clocal
group MyRWGroup usmlocal
group MyROGroup v1 mynetwork
group MyROGroup v2cmynetwork
group MyROGroup usmmynetwork


# Third, create a view for us to let the groups have rights to:

#   incl/excl subtree  mask
view allincluded  .1   80


# Finally, grant the 2 groups access to the 1 view with different
# write permissions:

#context sec.model sec.level match  read   write  notif
access MyROGroup   any   noauthexact  allnone   none
access MyRWGroup   any   noauthexact  allallnone


###
# System contact information
#

syslocation In My Place
syscontact zxiv1001 [EMAIL PROTECTED]
sysdescr My Machine
sysname Machine Sys

###
# Define trap destinations
#

# trapsink: A SNMPv1 trap receiver
#   arguments: host [community] [portnum]
trapsink 127.0.0.1

# trap2sink: A SNMPv2c trap receiver
#   arguments: host [community] [portnum]
trap2sink 127.0.0.1

# informsink: A SNMPv2c inform (acknowledged trap) receiver
#   arguments: host [community] [portnum]
informsink 127.0.0.1

# trapsess: A generic trap receiver defined using snmpcmd style arguments.
#   Read the snmpcmd manual page for further information.
#   arguments: [snmpcmdargs] host
#trapsess 127.0.0.1

#--


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.672 / Virus Database: 434 - Release Date: 4/28/2004



---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


Re: MAC address not retrieved by Win32 client

2004-06-21 Thread Dave Shield
 Here are more details:
 If I will run `snmpwalk` from my Linux machine, I can definitely
 see the line:
 
 RFC1213-MIB::ifPhysAddress.2 = Hex-STRING: 00 90 73 00 02 F5

Is that the same box as the agent is running on, or a different one?
It's worth checking you can see things from a remote system,
as well as the local one.


 It's also highly possible that snmputilg does not support 
 physical addresses (*shrugs*).

Seems unlikely, to be honest.
Such tools typically work with raw OIDs, and don't care about what
the values actually mean.

 Btw, what other FREE Win32 client tools that you guys use, in order 
 to get/set information to your net-snmp servers?

Well personally, I tend to use the Net-SNMP client applications
on all systems, including windows boxes.   (Not that I use windows
kit much).   But I'd be fairly surprised if this made a difference.
It's much more likely to be an access control problem.


 Also, here's my test conf, please feel free to send flames:
 
 #-
 #   sec.name  source  community
 com2sec local 172.0.0.1   public
 com2sec mynetwork 0.0.0.0/0   public

Is that a typo for 127.0.0.1 ?
Otherwise the access control stuff looks OK.

(I'd have used default rather than 0.0.0.0/0 but it
 probably works the same).



You don't need all three of the following:

 trapsink 127.0.0.1
 trap2sink 127.0.0.1
 informsink 127.0.0.1

since that will generate *three* copies of every trap you send,
but that's not relevant to this problem.


Another thought - are you *sure* that this is the snmpd.conf file
that's being read.   If you're running a pre-installed version
of the agent, then that will typically be looking in somewhere like
/etc/snmp/snmpd.conf rather than /usr/local/etc/snmp/snmpd.conf

Try deliberately putting an invalid token into the config file
and restarting the agent.  It should log an error.

Or stop the agent, and restart it using

snmpd -f -Le -Dread_config

and check that it's reading things in correctly.

Dave



---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


Re: MAC address not retrieved by Win32 client

2004-06-21 Thread Alex Burger
Vic Berdin wrote:
Hi David, everyone,
Btw, what other FREE Win32 client tools that you guys use, in order 
to get/set information to your net-snmp servers?
Have you tried Net-SNMP under Windows?  A Windows binary is available 
for 5.1.2pre2 on the Net-SNMP download page.

Alex

---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


RE: MAC address not retrieved by Win32 client

2004-06-21 Thread Vic Berdin
Hi Dave, Alex, everyone,

 -Original Message-
 From: Dave Shield [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 21, 2004 7:00 PM
 To: Vic Berdin
 Cc: [EMAIL PROTECTED]
 Subject: Re: MAC address not retrieved by Win32 client

 Here are more details:
 If I will run `snmpwalk` from my Linux machine, I can definitely
 see the line:

 RFC1213-MIB::ifPhysAddress.2 = Hex-STRING: 00 90 73 00 02 F5

 Is that the same box as the agent is running on, or a different one?
 It's worth checking you can see things from a remote system,
 as well as the local one.

VIC: It's the same box. I've just tried your suggestion, and my other
 Linux machine (vmware actually) was able to get the physical address.
 And incidentally, after reading another response from Alex, I tried
 the Win32 based net-snmp, and yep, snmpwalk from this net-snmp flavor
 can also retrieve physical address values.

 It's also highly possible that snmputilg does not support
 physical addresses (*shrugs*).

 Seems unlikely, to be honest.
 Such tools typically work with raw OIDs, and don't care about what
 the values actually mean.

 Btw, what other FREE Win32 client tools that you guys use, in order
 to get/set information to your net-snmp servers?

 Well personally, I tend to use the Net-SNMP client applications
 on all systems, including windows boxes.   (Not that I use windows
 kit much).   But I'd be fairly surprised if this made a difference.
 It's much more likely to be an access control problem.


 Also, here's my test conf, please feel free to send flames:

 #-
 #   sec.name  source  community
 com2sec local 172.0.0.1   public
 com2sec mynetwork 0.0.0.0/0   public

 Is that a typo for 127.0.0.1 ?
 Otherwise the access control stuff looks OK.

VIC: It is a typo on my actual config. I already changed it, but the
 problem remains

 (I'd have used default rather than 0.0.0.0/0 but it
  probably works the same).

 You don't need all three of the following:

 trapsink 127.0.0.1
 trap2sink 127.0.0.1
 informsink 127.0.0.1

 since that will generate *three* copies of every trap you send,
 but that's not relevant to this problem.

VIC: So that's what it means! I've made a script just to see if my trap
 daemon can indeed detect coldStart. The script simply echoes to a
 file. And to my amazement, three entries are always gets created.
 Thanks for this one!
 BTW, how do you actually test warmStart, linkUp, and linkDown?

 Another thought - are you *sure* that this is the snmpd.conf file
 that's being read.   If you're running a pre-installed version
 of the agent, then that will typically be looking in somewhere like
 /etc/snmp/snmpd.conf rather than /usr/local/etc/snmp/snmpd.conf

VIC: This is indeed the active config. I have this on my rc start-up
 script:

-c /usr/local/share/snmp/snmp.conf

 ...and this as my trapd option:

-f -Le -c /usr/local/share/snmp/snmptrapd.conf

 Try deliberately putting an invalid token into the config file
 and restarting the agent.  It should log an error.

VIC: No need. I've had obvious errors on this config before. And the
 error does get logged in /var/log/messages. At present, my messages
 log is free from snmpd errors.

VIC: I really have no more ideas at this point on how to resolve this.
 Since another Linux machine and the Win32 net-snmp can retrieve the MAC
 values from the server, I'm bent on believing that snmputilg.exe has
 problems...

 
   However:
 

 I also would like to inform the list that SilverCreek spurs out a lot
 of TimeOut errors from this server and config. Out of 79 tests for v2c,
 I get:

- 52 passed tests, 23 failures, 3 warnings, and 1 uninnitiated test due
  to dependencies on previous failed tests.

- For v1, almost half of the test failed (22 failures  3 warings out
  of 51 tests).

- I haven't started testing v3 yet.

 Can this be interpreted that net-snmp has its own means of getting
 things done? Or isn't really/fully RFC compliant? :o(

 To those who may be interested, I can give you a zipped copy of the
 errors I'm getting. But for starters, here's a snip of one of my saved
logs:

 I really wonder what does this error on Index value mean. I'm getting
lines
 and lines of these errors/warnings, along with write problems
eventhough
 `snmpset` works fine from a Linux client.



---
[WARNING] Remarks: Possible problems in set-request operation
Agent returned out of range error-index value
The error-index value in a Reponse-PDU with an error-status of notWritable
must be between 1 and the number of varbinds in the request.  Instead, an
error-index of 0 was received, which does not correspond to any of the 2