[ECOS] SNMP lockup

[ECOS] SNMP lockup

[Grant Edwards]

I've run across a problem where certain "get" requests for
certain OIDs cause a lock-up.  I can still ping the box, but
everything else is dead (all my user tasks are dead and the box
won't respond to any further SNMP requests).

The OIDs that are causing the problem are

.1.3.6.1.2.1.2.2.1.n.0

That's a query for an attribute of network interface #0.  Which
attribute depends on n: 6==physAddr, 2=name, etc.  That last
feild (.0) in the OID is the interface number.

Network interface 1 is the ethernet interface, and interface 2
is the loopback interface.  Requests for attributes of those
interfaces work fine.  [Asking for other unrecognized or
out-of-range OIDs seems to return the proper error codes.]

There isn't an interface 0, but some SNMP programs (e.g. the
really expensive ones from HP and Cisco) send requests for OID
.1.3.6.1.2.1.2.2.1.6.0 to my eCos-based widget and locking it
up.  It order to keep the eCos-based boxes running, my
customers have to disable SNMP suppert in the eCos-based
product or exclude the eCos-based products from the address
range to which said expensive SNMP apps are allowed to talk.

Has anybody seen this behavior before?  Any ideas on how to fix
it?

-- 
Grant Edwards                   grante             Yow! PEGGY FLEMMING is
                                  at               stealing BASKET BALLS to
                               visi.com            feed the babies in VERMONT.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Grant Edwards <grante@visi.com> wrote:

> The OIDs that are causing the problem are
>
> .1.3.6.1.2.1.2.2.1.n.0
>
> That's a query for an attribute of network interface #0.  Which
> attribute depends on n: 6==physAddr, 2=name, etc.  That last
> feild (.0) in the OID is the interface number.

It appears that in mibgroup/mibII/interfaces.c, the call to 

  cyg_snmp_get_if(if_num)

with if_num==0 never returns.

-- 
Grant Edwards                   grante             Yow! Everybody is going
                                  at               somewhere!!  It's probably
                               visi.com            a garage sale or a disaster
                                                   Movie!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Grant Edwards <grante@visi.com> wrote:

> It appears that in mibgroup/mibII/interfaces.c, the call to 
>
>   cyg_snmp_get_if(if_num)
>
> with if_num==0 never returns.

    struct ifnet *cyg_snmp_get_if(int if_num) {
      int index = 0;
      struct ifnet *ifp;
      
      do {
        while(0 == ifnet_addrs[index])
          index++;
    
        ifp = ifnet_addrs[index]->ifa_ifp;
        
        if_num--;       
        index++;
      } while (if_num);
    
      return ifp;
    }

If the above code is called with if_num==0, won't it decrement
it to -1, and then loop 2^32 times before giving up?

-- 
Grant Edwards                   grante             Yow! What I want to find
                                  at               out is -- do parrots know
                               visi.com            much about Astro-Turf?


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Grant Edwards <grante@visi.com> wrote:
> On 2009-05-08, Grant Edwards <grante@visi.com> wrote:
>
>> It appears that in mibgroup/mibII/interfaces.c, the call to 
>>
>>   cyg_snmp_get_if(if_num)
>>
>> with if_num==0 never returns.
>
>     struct ifnet *cyg_snmp_get_if(int if_num) {
>       int index = 0;
>       struct ifnet *ifp;
>       
>       do {
>         while(0 == ifnet_addrs[index])
>           index++;
>     
>         ifp = ifnet_addrs[index]->ifa_ifp;
>         
>         if_num--;       
>         index++;
>       } while (if_num);
>     
>       return ifp;
>     }
>
> If the above code is called with if_num==0, won't it decrement
> it to -1, and then loop 2^32 times before giving up?

And returning a rogue pointer...

-- 
Grant Edwards                   grante             Yow! I wish I was a
                                  at               sex-starved manicurist
                               visi.com            found dead in the Bronx!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

>> It appears that in mibgroup/mibII/interfaces.c, the call to 
>>
>>   cyg_snmp_get_if(if_num)
>>
>> with if_num==0 never returns.
>
>     struct ifnet *cyg_snmp_get_if(int if_num) {
>       int index = 0;
>       struct ifnet *ifp;
>       
>       do {
>         while(0 == ifnet_addrs[index])
>           index++;
>     
>         ifp = ifnet_addrs[index]->ifa_ifp;
>         
>         if_num--;       
>         index++;
>       } while (if_num);
>     
>       return ifp;
>     }
>
> If the above code is called with if_num==0, won't it decrement
> it to -1, and then loop 2^32 times before giving up?

It also mis-handles negative values in a similar manner.

Adding a check seems to fix things:

    struct ifnet *cyg_snmp_get_if(int if_num) {
      int index = 0;
      struct ifnet *ifp;
    
      if (if_num <= 0)
        return NULL;
      
      do {

    [...]      

It should also probably check to make sure index doesn't go off
then end of if_addrs[] when large positive numbers are passed.
Perhaps something like this:

struct ifnet *cyg_snmp_get_if(int if_num)
  {
    int index = 0;
    struct ifnet *ifp;

    if (if_num == 0)
      return NULL;

    do
      {
        while (0 == ifnet_addrs[index] && index < if_index)
          index++;

        if (index >= if_index)
          return NULL;

        ifp = ifnet_addrs[index]->ifa_ifp;

        if_num--;
        index++;
      }
    while (if_num);

    return ifp;
  }



-- 
Grant Edwards                   grante             Yow! over in west
                                  at               Philadelphia a puppy is
                               visi.com            vomiting ...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Sergei Gavrikov]

On Fri, May 08, 2009 at 10:05:13PM +0000, Grant Edwards wrote:
> >> It appears that in mibgroup/mibII/interfaces.c, the call to 
> >>
> >>   cyg_snmp_get_if(if_num)
> >>
> >> with if_num==0 never returns.
> >
> >     struct ifnet *cyg_snmp_get_if(int if_num) {
> >       int index = 0;
> >       struct ifnet *ifp;
> >       
> >       do {
> >         while(0 == ifnet_addrs[index])
> >           index++;
> >     
> >         ifp = ifnet_addrs[index]->ifa_ifp;
> >         
> >         if_num--;       
> >         index++;
> >       } while (if_num);
> >     
> >       return ifp;
> >     }
> >
> > If the above code is called with if_num==0, won't it decrement
> > it to -1, and then loop 2^32 times before giving up?
> 
> It also mis-handles negative values in a similar manner.
> 
> Adding a check seems to fix things:
> 
>     struct ifnet *cyg_snmp_get_if(int if_num) {
>       int index = 0;
>       struct ifnet *ifp;
>     
>       if (if_num <= 0)
>         return NULL;
>       
>       do {
> 
>     [...]      
> 
> It should also probably check to make sure index doesn't go off
> then end of if_addrs[] when large positive numbers are passed.
> Perhaps something like this:
> 
> struct ifnet *cyg_snmp_get_if(int if_num)
>   {
>     int index = 0;
>     struct ifnet *ifp;
> 
>     if (if_num == 0)
>       return NULL;
> 
>     do
>       {
>         while (0 == ifnet_addrs[index] && index < if_index)
>           index++;
> 
>         if (index >= if_index)
>           return NULL;
> 
>         ifp = ifnet_addrs[index]->ifa_ifp;
> 
>         if_num--;
>         index++;
>       }
>     while (if_num);
> 
>     return ifp;
>   }
> 

Hi

If your guess is right... Can you walk here with/without tweaks when if_num=0

repo/devo/ecos/packages/net/snmp/agent/current/src/mibgroup/mibII/interfaces.c:398

(CVS HEAD sources)


Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Grant Edwards <grante@visi.com> wrote:

> It should also probably check to make sure index doesn't go off
> then end of if_addrs[] when large positive numbers are passed.
> Perhaps something like this:
>
> struct ifnet *cyg_snmp_get_if(int if_num)
>   {
>     int index = 0;
>     struct ifnet *ifp;
>
>     if (if_num == 0)

should be:       <= 0)

>       return NULL;
>

-- 
Grant Edwards                   grante             Yow! I want you to MEMORIZE
                                  at               the collected poems of
                               visi.com            EDNA ST VINCENT MILLAY
                                                   ... BACKWARDS!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:

> If your guess is right...

It's not a guess.

The problem occurs when cyg_snmp_get_if() is called with if_num <= 0.

The loop takes 1-2 minutes to loop from -1, -2, back to 0,
causing the SNMP management thread to lock out all lower
priority threads while it's doing so.

> Can you walk here with/without tweaks when if_num=0
>
> repo/devo/ecos/packages/net/snmp/agent/current/src/mibgroup/mibII/interfaces.c:398

I don't understand what you're asking.

The SNMP manager is asking for the physical address for
interface 0, and things lock up for a couple minutes because
cyg_snmp_get_if() doesn't return.  The same thing happens if
you ask for the interface name or any other attribute of
interface 0.

It also occurs if you ask for an attribute of an interface
number so large that it wraps into a negative number when
represented as a 2's compliment 32-bit int.

I'm surprised nobody else has run into this.  I'm told all our
customers who have HP or Cisco SNMP managers have had to
disable SNMP support in our products to keep them from locking
up every few minutes.

-- 
Grant Edwards                   grante             Yow! ... If I had heart
                                  at               failure right now,
                               visi.com            I couldn't be a more
                                                   fortunate man!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Sergei Gavrikov]

On Fri, May 08, 2009 at 10:38:24PM +0000, Grant Edwards wrote:
> On 2009-05-08, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> 
> > If your guess is right...
> 
> It's not a guess.
> 
> The problem occurs when cyg_snmp_get_if() is called with if_num <= 0.
> 
> The loop takes 1-2 minutes to loop from -1, -2, back to 0,
> causing the SNMP management thread to lock out all lower
> priority threads while it's doing so.

Then fix it.

> 
> > Can you walk here with/without tweaks when if_num=0
> >
> > repo/devo/ecos/packages/net/snmp/agent/current/src/mibgroup/mibII/interfaces.c:398
 
[snip]

> I'm surprised nobody else has run into this.  I'm told all our
> customers who have HP or Cisco SNMP managers have had to
> disable SNMP support in our products to keep them from locking
> up every few minutes.

I was just googling +'ifPhysAddress.0'

It seems you are not alone :-)

http://mtsc.moxa.com:8888/Software/DN/NPort/Firmware/NPort%205000/NPort%205600/ver3.2/VERSION.TXT

<quote>
ver3.1 (2006/05/16)

3. Fixed the problem that querying NPort by SNMP Software would cause NPort stop replying ethernet packet

   while querying "GET iso.3.6.1.2.1.2.2.1.6.0", which is resolved as

   "GET iso.org.dod.internet.mgmt.mib-2.interface.ifTable.ifEntry.ifPhysAddress.0".
</quote>


UCD-SNMP had a lot of holes. eCos UCD-SNMP implementation has even more
holes :-(


Good luck!

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Gary Thomas]

Sergei Gavrikov wrote:
> On Fri, May 08, 2009 at 10:38:24PM +0000, Grant Edwards wrote:
>> On 2009-05-08, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
>>
>>> If your guess is right...
>> It's not a guess.
>>
>> The problem occurs when cyg_snmp_get_if() is called with if_num <= 0.
>>
>> The loop takes 1-2 minutes to loop from -1, -2, back to 0,
>> causing the SNMP management thread to lock out all lower
>> priority threads while it's doing so.
> 
> Then fix it.
> 
>>> Can you walk here with/without tweaks when if_num=0
>>>
>>> repo/devo/ecos/packages/net/snmp/agent/current/src/mibgroup/mibII/interfaces.c:398
>  
> [snip]
> 
>> I'm surprised nobody else has run into this.  I'm told all our
>> customers who have HP or Cisco SNMP managers have had to
>> disable SNMP support in our products to keep them from locking
>> up every few minutes.
> 
> I was just googling +'ifPhysAddress.0'
> 
> It seems you are not alone :-)
> 
> http://mtsc.moxa.com:8888/Software/DN/NPort/Firmware/NPort%205000/NPort%205600/ver3.2/VERSION.TXT
> 
> <quote>
> ver3.1 (2006/05/16)
> 
> 3. Fixed the problem that querying NPort by SNMP Software would cause NPort stop replying ethernet packet
> 
>    while querying "GET iso.3.6.1.2.1.2.2.1.6.0", which is resolved as
> 
>    "GET iso.org.dod.internet.mgmt.mib-2.interface.ifTable.ifEntry.ifPhysAddress.0".
> </quote>
> 
> 
> UCD-SNMP had a lot of holes. eCos UCD-SNMP implementation has even more
> holes :-(

Feel free to improve this - much of the networking code,
including SNMP, is more than seven (7!) years old.  A lot
has gone on in the world in that time...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Sergei Gavrikov]

On Fri, May 08, 2009 at 05:15:40PM -0600, Gary Thomas wrote:
> Sergei Gavrikov wrote:

[snip]

> > UCD-SNMP had a lot of holes. eCos UCD-SNMP implementation has even more
> > holes :-(
> 
> Feel free to improve this - much of the networking code,
> including SNMP, is more than seven (7!) years old.  A lot
> has gone on in the world in that time...

No, thanks... I know how old that. It's better to look on a baby

$ LANG=C wc -l lwip/src/core/snmp/*.c
   657 lwip/src/core/snmp/asn1_dec.c
   ...
  8714 total

Less of lines means for me to get more chances to get something working.
I even do not know why to have SNMP v2c/v3 for small embedded devices. I
have a doubt about SET requests too. IMHO, SNMPv1-- (-SET), that is it.

Sergei


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Grant Edwards <grante@visi.com> wrote:

> It should also probably check to make sure index doesn't go off
> then end of if_addrs[] when large positive numbers are passed.
> Perhaps something like this:
>
> struct ifnet *cyg_snmp_get_if(int if_num)
>   {
>     int index = 0;
>     struct ifnet *ifp;
>
>     if (if_num == 0)
>       return NULL;
>
>     do
>       {
>         while (0 == ifnet_addrs[index] && index < if_index)
>           index++;
>
>         if (index >= if_index)
>           return NULL;
>
>         ifp = ifnet_addrs[index]->ifa_ifp;
>
>         if_num--;
>         index++;
>       }
>     while (if_num);
>
>     return ifp;
>   }

I've decided that's just way too convoluted.  It's already
fooled several people for several years.  How about this?

long cyg_snmp_num_interfaces(void) {
  int i,n=0;

  for (i=0; i<if_index; ++i)
    if (ifnet_addrs[i])
      n++;

  return n;
}

struct ifnet *cyg_snmp_get_if(int if_num) {
  int i,n=0;

  for (i=0; i<if_index; ++i)
    if (ifnet_addrs[i])
      if (++n == if_num)
        return ifnet_addrs[i]->ifa_ifp;

  return NULL;
}

Maybe it's just me, that that seems a lot more transparent. Or
am I missing something subtle in the original versions?

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-08, Gary Thomas <gary@mlbassoc.com> wrote:

>>> The problem occurs when cyg_snmp_get_if() is called with if_num <= 0.
[...]
>>> I'm surprised nobody else has run into this.  I'm told all our
>>> customers who have HP or Cisco SNMP managers have had to
>>> disable SNMP support in our products to keep them from locking
>>> up every few minutes.
>> 
>> I was just googling +'ifPhysAddress.0'
>> 
>> It seems you are not alone :-)
>> 
>> http://mtsc.moxa.com:8888/Software/DN/NPort/Firmware/NPort%205000/NPort%205600/ver3.2/VERSION.TXT

That's interesting -- I hadn't found that.  Since the bug was
in eCos-specific code, do we assume that Moxa is using eCos for
the NPort?

>> UCD-SNMP had a lot of holes. eCos UCD-SNMP implementation has
>> even more holes :-(

Um... I blame Dick Cheney and Karl Rove!

> Feel free to improve this

Workin' on it...

> - much of the networking code, including SNMP, is more than
> seven (7!) years old.  A lot has gone on in the world in that
> time...

What I'd like a pointer on is the interface numbering in SNMP
OIDs.  Are the interfaces supposed to be numbered 1..N with
interface 0 being non-existent?  Or are eCos interface numbers
off by one and they should really be 0,1 instead of 1,2? [I
tried looking through the OID/ASN.1 docs, but got lost rather
quickly.]

If SNMP interface numbers are supposed to start at #1, why do
HP and Cisco SNMP managers ask for attributes of interface #0?

I looked at network traces for one customer site using, I
believe, HP Insight. It does read the interface attributes for
interfaces 1 and 2.  I don't see it attempt to read attributes
for interface 3 (which doesn't exist). I do see it attempt to
read attributes for interface 0 (which also doesn't exist).

If interface numbers are supposed to start at #0, will
renumbering the interfaces at this point (after product has
been shipping for 7 years) cause more problems that it will
solve?

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Sergei Gavrikov]

On Sat, May 09, 2009 at 08:48:12AM +0000, Grant Edwards wrote:

[snip]

> What I'd like a pointer on is the interface numbering in SNMP
> OIDs.  Are the interfaces supposed to be numbered 1..N with
> interface 0 being non-existent?  Or are eCos interface numbers
> off by one and they should really be 0,1 instead of 1,2? [I
> tried looking through the OID/ASN.1 docs, but got lost rather
> quickly.]
> 
> If SNMP interface numbers are supposed to start at #1, why do
> HP and Cisco SNMP managers ask for attributes of interface #0?
> 

Not only those Network managers... Any hacker can hang a "stupid"
device then

I tried it on my ADSL modem

snmpwalk -c public -v1 bridge.local IF-MIB::ifPhysAddress.0
IF-MIB::ifPhysAddress.0: Unknown Object Identifier (Index out of range: 0 (ifIndex))

But it still ping itself :-)

> I looked at network traces for one customer site using, I
> believe, HP Insight. It does read the interface attributes for
> interfaces 1 and 2.  I don't see it attempt to read attributes
> for interface 3 (which doesn't exist). I do see it attempt to
> read attributes for interface 0 (which also doesn't exist).
> 
> If interface numbers are supposed to start at #0, will
> renumbering the interfaces at this point (after product has
> been shipping for 7 years) cause more problems that it will
> solve?

That's known SNMP "issue"

-- “get” might want that the OID ends in .0

Example:

snmpget -c public -O X -v2c bridge.local sysDescr
SNMPv2-MIB::sysDescr = No Such Instance currently exists at this OID

snmpget -c public -O X -v2c bridge.local sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Foo bar baz

So, IMHO, it's better to fix the agent than to make managers work
"properly".

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-09, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:

> [snip]
>
>> What I'd like a pointer on is the interface numbering in SNMP
>> OIDs.  Are the interfaces supposed to be numbered 1..N with
>> interface 0 being non-existent?  Or are eCos interface numbers
>> off by one and they should really be 0,1 instead of 1,2? [I
>> tried looking through the OID/ASN.1 docs, but got lost rather
>> quickly.]

[...]

>> I looked at network traces for one customer site using, I
>> believe, HP Insight. It does read the interface attributes for
>> interfaces 1 and 2.  I don't see it attempt to read attributes
>> for interface 3 (which doesn't exist). I do see it attempt to
>> read attributes for interface 0 (which also doesn't exist).
>> 
>> If interface numbers are supposed to start at #0, will
>> renumbering the interfaces at this point (after product has
>> been shipping for 7 years) cause more problems that it will
>> solve?
>
> That's known SNMP "issue"

What is a known issue?

> -- ?get? might want that the OID ends in .0
>
> Example:
>
> snmpget -c public -O X -v2c bridge.local sysDescr
> SNMPv2-MIB::sysDescr = No Such Instance currently exists at this OID
>
> snmpget -c public -O X -v2c bridge.local sysDescr.0
> SNMPv2-MIB::sysDescr.0 = STRING: Foo bar baz

I'm afraid I don't understand your point.

> So, IMHO, it's better to fix the agent than to make managers
> work "properly".

I wasn't propsoing that we not fix the agent.  What I was
asking was

 * Which of two fixes is the "standards-correct" one:

    1) Leave the interfaces numbered 1,2 and fix handling
       for queries of interface <1.

    2) Change the interface numbers to 0,1.

 * If 2) is what the standards specify, are we still better off
   with 1) to maintain some backwards-compatiblity with older
   versions?  

My posted fix that implements choice 1).

I misunderstanding OID sematics? 

Is 1.3.6.1.2.1.2.2.1.6.0 supposed to refer to the physical
address of the first network interface?

Or is 1.3.6.1.2.1.2.2.1.6.1 the physical address of the first
interface and <...>.0 is something fundamentally different?

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-09, Grant Edwards <grante@visi.com> wrote:

>>> What I'd like a pointer on is the interface numbering in SNMP
>>> OIDs.  Are the interfaces supposed to be numbered 1..N with
>>> interface 0 being non-existent?  Or are eCos interface numbers
>>> off by one and they should really be 0,1 instead of 1,2?

After doing some more reading, I've concluded that the
interface numbers are correct.  OIDs for objects that are
single, scalar values end in .0.  OIDs for table entries end in
.1 through .N where the table contains N values.

The correct OID for the first network interface's physical
address should be (and was and still is) 1.3.6.1.2.1.2.2.1.6.1
and the second interface's address is 1.3.6.1.2.1.2.2.1.6.2

Those have always been handled correctly.

The problematic OID, 1.3.6.1.2.1.2.2.1.6.0, does not refer to
the value at "index 0" of the interface physical address table,
but refers to the scalar value identified by 1.3.6.1.2.1.2.2.1.6.

But, 1.3.6.1.2.1.2.2.1.6 isn't a scalar value, it's a table, so
1.3.6.1.2.1.2.2.1.6.0 isn't a valid OID.  AFAICT, error #2 (no
such name) is the appropriate error to return in that case.

That is now handled correctly after my posted fix.

What I'm now wondering is how many problems are waiting to pop
up when a similar requests received for "index 0" of other
table objects?

There also remains the open question of why well-known,
brand-name, hideously-expensive SNMP managers are sending out
that invalid OID...

-- 
Grant


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: SNMP lockup

[Sergei Gavrikov]

On Sat, May 09, 2009 at 10:28:24AM +0000, Grant Edwards wrote:
> On 2009-05-09, Grant Edwards <grante@visi.com> wrote:
> 
> >>> What I'd like a pointer on is the interface numbering in SNMP
> >>> OIDs.  Are the interfaces supposed to be numbered 1..N with
> >>> interface 0 being non-existent?  Or are eCos interface numbers
> >>> off by one and they should really be 0,1 instead of 1,2?

[ snip]

I was AWK. Now, It seems for me that I can pass your question, What is
known issue? :

   -- "get" might want that the OID ends in .0

NMS can bomb even _the_tables_ using OID.0. Why? (the below)


> What I'm now wondering is how many problems are waiting to pop
> up when a similar requests received for "index 0" of other
> table objects?
> 
> There also remains the open question of why well-known,
> brand-name, hideously-expensive SNMP managers are sending out
> that invalid OID...

There were (are?) a lot SNMP devices on the market which had the broken
compiled-in MIBs.  It's not possible to upgrade it for some reasons. A
logic of NMS (managers) is: it's better to get something, it's better to
notice something than to get nothing. The managers bomb the important
tables as the scalars in a hope to get something from the defective by
design devices.  It's better to notify sysadmin about a broken MIB and
even to interpret and to show a misplaced MAC than quite to ignore the
break (i.e. to be RFC stricted).

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] RE: SNMP lockup

[Danny Sade]

I've tried some other tables of the standard MIB, and found out that access to table
.iso.org.dod.internet.mgmt.mib-2.transmission.dot3.dot3StatsTable.dot3StatsEntry
with index 0 also locks the system.
For example:
snmpget -v 2c -c public -m : 10.10.100.20  .1.3.6.1.2.1.10.7.2.1.6.0

My guess is that there are some more cases like these.  So IMHO fixing
the problem within the agent will be a better solution i.e. the agent
should detect a request for a table entry with index 0 and respond with an error.

Thanks

Danny

 

-----Original Message-----
From: Grant Edwards [mailto:grante@visi.com] 
Sent: Saturday, May 09, 2009 13:28
To: ecos-discuss@sources.redhat.com
Subject: Re: SNMP lockup

On 2009-05-09, Grant Edwards <grante@visi.com> wrote:

>>> What I'd like a pointer on is the interface numbering in SNMP
>>> OIDs.  Are the interfaces supposed to be numbered 1..N with
>>> interface 0 being non-existent?  Or are eCos interface numbers
>>> off by one and they should really be 0,1 instead of 1,2?

After doing some more reading, I've concluded that the
interface numbers are correct.  OIDs for objects that are
single, scalar values end in .0.  OIDs for table entries end in
.1 through .N where the table contains N values.

The correct OID for the first network interface's physical
address should be (and was and still is) 1.3.6.1.2.1.2.2.1.6.1
and the second interface's address is 1.3.6.1.2.1.2.2.1.6.2

Those have always been handled correctly.

The problematic OID, 1.3.6.1.2.1.2.2.1.6.0, does not refer to
the value at "index 0" of the interface physical address table,
but refers to the scalar value identified by 1.3.6.1.2.1.2.2.1.6.

But, 1.3.6.1.2.1.2.2.1.6 isn't a scalar value, it's a table, so
1.3.6.1.2.1.2.2.1.6.0 isn't a valid OID.  AFAICT, error #2 (no
such name) is the appropriate error to return in that case.

That is now handled correctly after my posted fix.

What I'm now wondering is how many problems are waiting to pop
up when a similar requests received for "index 0" of other
table objects?

There also remains the open question of why well-known,
brand-name, hideously-expensive SNMP managers are sending out
that invalid OID...

-- 
Grant


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-14, Danny Sade <danny@channelot.com> wrote:

> I've tried some other tables of the standard MIB, and found out that access to table
> .iso.org.dod.internet.mgmt.mib-2.transmission.dot3.dot3StatsTable.dot3StatsEntry
> with index 0 also locks the system.
> For example:
> snmpget -v 2c -c public -m : 10.10.100.20  .1.3.6.1.2.1.10.7.2.1.6.0
>
> My guess is that there are some more cases like these.

Probably.  SNMP is a mess to start with, and the UCD
implementation doesn't have a very good reputation.

> So IMHO fixing the problem within the agent will be a better
> solution i.e. the agent should detect a request for a table
> entry with index 0 and respond with an error.

I don't see how that's possible.  Unless I'm misunderstanding
the way the agent code works, it doesn't know whether a request
is for a table or a scalar. AFICT, all it knows about is a
mapping from OID values to callbacks.  When an OID match is
found the corresponding callback is then passed the OID and is
supposed to "do the right thing".

However, I agree that the error should be handled as generally
as possible.

One possibility is to add a check in the utility funciton
header_simple_table().  That's the routine used by at least
_some_ of the callbacks to (among other things) check the max
index value. However, I don't know for sure that
header_simple_table() isn't also used for scalar values by
specifying a max index value of 0.  Presumably if the max index
value is > 0, then the entity is a table and an index value of
0 should be an error.  But that's just an educated guess. I
don't even know that all table-handling callbacks use
header_simple_table().

-- 
Grant Edwards                   grante             Yow! Send your questions to
                                  at               ``ASK ZIPPY'', Box 40474,
                               visi.com            San Francisco, CA 94140,
                                                   USA


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: SNMP lockup

[Grant Edwards]

On 2009-05-14, Danny Sade <danny@channelot.com> wrote:

> I've tried some other tables of the standard MIB, and found
> out that access to table .iso.org.dod.internet.mgmt.mib-2.transmission.dot3.dot3StatsTable.dot3StatsEntry
> with index 0 also locks the system.
> For example:
> snmpget -v 2c -c public -m : 10.10.100.20  .1.3.6.1.2.1.10.7.2.1.6.0

FWIW, the patch I posted fixes that as well.

-- 
Grant Edwards                   grante             Yow! So this is what it
                                  at               feels like to be potato
                               visi.com            salad


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss