On 8/13/19 1:50 PM, Claudio Jeker wrote:
> On Tue, Aug 13, 2019 at 01:43:13PM +0200, Martijn van Duren wrote:
>> On 8/13/19 1:40 PM, Claudio Jeker wrote:
>>> On Tue, Aug 13, 2019 at 01:27:44PM +0200, Martijn van Duren wrote:
>>>>
>>>>
>>>> On 8/13/19 1:23 PM, Stuart Henderson wrote:
>>>>> On 2019/08/13 12:20, Stuart Henderson wrote:
>>>>>> On 2019/08/13 11:30, Martijn van Duren wrote:
>>>>>>> Found this one by because snmpd returns an invalid varbind on my laptop.
>>>>>>> Doing some digging I found the following:
>>>>>>> Error message:
>>>>>>> mib_iftable: iwm0: invalid ifq: Operation not supported
>>>>>>> mib_iftable: em0: invalid ifq: Operation not supported
>>>>>>>
>>>>>>> sysctl mib:
>>>>>>> { CTL_NET, PF_INET, IPPROTO_IP, IPCTL_IFQUEUE, IFQCTL_DROPS };
>>>>>>>
>>>>>>> file: usr.sbin/snmpd/mib.c:1198
>>>>>>>
>>>>>>> I'll look at why snmpd returns an invalid packet later, but did anything
>>>>>>> change in packet drop land that could've caused this?
>>>>>>>
>>>>>>> martijn@
>>>>>>>
>>>>>>
>>>>>> Yes, the input queuing mechanism was changed, these are no longer used.
>>>>>>
>>>>>
>>>>> oops s/input/interface :)
>>>>>
>>>> Does this mean we need to remove this mib from snmpd, or do we need to
>>>> invoke some other incantation?
>>>
>>> Uhm wait, that is querying net.inet.ip.ifq.drops and yes, that is gone but
>>> that has nothing todo with interface counters. What kind of mib value is
>>> that?
>>>
>>
>> That would be:
>> .iso.org.dod.internet.mgmt.mib_2.interfaces.ifTable.ifEntry.ifInDiscards
>
> In that case you want to use ifi_iqdrops in struct if_data.
> So maybe something like the appended diff could work.
> Then there is also case 21 that gets net.inet.ip.ifq.len which needs to be
> changed too.
>
This diff is outside my area of expertise.
If that fixes the issue you have my blessing, but ENOCLUE.
