Nav-users January 2023

nav-users@lister.sikt.no

5 participants
6 discussions

Business 350-8T-E-2G support in NAV versione 5.4.0
by Davide Miccone 21 Mar '23

21 Mar '23

Seems that NAV (versione 5.4.0) does not full support switch Cisco Business 350-8T-E-2G. I get some box infos but - for example - port VLANs are not correctly get. LLDP data and neighbors are not correctly get. Someone use switch Cisco Business 350-8T-E-2G? Davide

2 10

Error 500 when upgrading to nav 5.6
by FOUR Ludovic (EXT) 09 Mar '23

09 Mar '23

Hello, I've updated recently Nav on debian from 5.5.2-1 to 5.6 I have an error 500 when I try to reach the nav gui website Here is some errors on /var/log/apache2/error.log [Tue Jan 24 11:18:16.723757 2023] [mpm_prefork:notice] [pid 22855] AH00169: caught SIGTERM, shutting down [Tue Jan 24 11:23:07.716778 2023] [mpm_prefork:notice] [pid 1600] AH00163: Apache/(version removed) (Debian) mod_fcgid/(version removed) OpenSSL/1.1.1n mod_wsgi/(version removed) Python/3.7 configured -- resuming normal operations [Tue Jan 24 11:23:07.881160 2023] [core:notice] [pid 1600] AH00094: Command line: '/usr/sbin/apache2' [Tue Jan 24 11:27:21.186436 2023] [wsgi:error] [pid 1602] [remote <IP removed>:55041] mod_wsgi (pid=1602): Exception occurred processing WSGI script '/opt/venvs/nav/lib/python3.7/site-packages/nav/wsgi.py'. [Tue Jan 24 11:27:21.187713 2023] [wsgi:error] [pid 1603] [remote <IP removed>:55043] mod_wsgi (pid=1603): Exception occurred processing WSGI script '/opt/venvs/nav/lib/python3.7/site-packages/nav/wsgi.py'. [Tue Jan 24 11:27:21.212539 2023] [wsgi:error] [pid 1602] [remote <IP removed>:55041] Traceback (most recent call last): [Tue Jan 24 11:27:21.212543 2023] [wsgi:error] [pid 1603] [remote <IP removed>:55043] Traceback (most recent call last): [Tue Jan 24 11:27:21.212725 2023] [wsgi:error] [pid 1602] [remote <IP removed>:55041] File "/opt/venvs/nav/lib/python3.7/site-packages/django/core/handlers/wsgi.py", line 133, in __call__ [Tue Jan 24 11:27:21.212731 2023] [wsgi:error] [pid 1603] [remote <IP removed>:55043] File "/opt/venvs/nav/lib/python3.7/site-packages/django/core/handlers/wsgi.py", line 133, in __call__ [Tue Jan 24 11:27:21.212737 2023] [wsgi:error] [pid 1602] [remote <IP removed>:55041] response = self.get_response(request)one Apparently, uwsgi Proxy is only used by graphite. No WSGI or uwsgi error found in /var/log/apache2/graphite-web_error.log The uwsgi configuration has not been touched since installation of nav and the other vhosts are working. When I downgrade nav to previous version, nav is working again and I can see updated traffic graphs (no gaps or missing graphs since the error) Regards, Ludovic F. Faculty of pharmacy - Strasbourg FRANCE

2 2

deviceNotice/None - no message template is defined
by Ingeborg Hellemo 08 Mar '23

08 Mar '23

NAV 5.5.2 An upgrade of a router generated several "Device SomeModule at router.domain had a software upgrade" (as expected), but also several Subject: deviceNotice/None on router.domain from NAV, but no message template is defined. Variable dump: {'_messages': None, 'alert_type': None, 'device': <Device: VB13030631>, 'event': <EventQueue: id=101132957, event_type_id='deviceNotice', source_id='ipdevpoll', target_id='eventEngine', netbox=<Netbox: router.domain> , subid='', state='x', time=datetime.datetime(2022, 12, 13, 13, 50, 53, 897695)>, 'event_type': <EventType: deviceNotice>, 'history_vars': {}, 'language': 'en', 'msgtype': 'email', 'netbox': <Netbox: router.domain>, 'severity': 3, 'source': <Subsystem: ipdevpoll>, 'state': 'x', 'subid': '', 'time': datetime.datetime(2022, 12, 13, 13, 50, 53, 897695), 'value': 100} --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

2 6

Re: Fortigate firewall
by Morten Brekkevold 23 Jan '23

23 Jan '23

On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas <nicolas.biselx(a)epfl.ch> wrote: > I'm not sure but I think that's what you asked me... > See in attachement Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :) > D:\>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 > iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143 All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB. This is the definition of an entry in the ipAddressTable: > IP-MIB::ipAddressEntry > ipAddressEntry OBJECT-TYPE > -- FROM IP-MIB > MAX-ACCESS not-accessible > STATUS current > INDEX { ipAddressAddrType, ipAddressAddr } > DESCRIPTION "An address mapping for a particular interface." > ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 } `iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`. This is the type definition: > InetAddressIPv4 ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1d.1d.1d.1d" > STATUS current > DESCRIPTION > "Represents an IPv4 network address: > > Octets Contents Encoding > 1-4 IPv4 address network-byte order > > The corresponding InetAddressType value is ipv4(1). > > This textual convention SHOULD NOT be used directly in object > definitions, as it restricts addresses to a specific format. > However, if it is used, it MAY be used either on its own or in > conjunction with InetAddressType, as a pair." > SYNTAX OCTET STRING (SIZE (4)) This response perfectly explains the warning/error given by ipdevpoll: > device has strange SNMP implementation of IP-MIB; ignoring retrieved IP > address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143') It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition. We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it. I would at the very least report this as a bug to Fortigate. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research

4 4

Re: Fortigate firewall
by Morten Brekkevold 10 Jan '23

10 Jan '23

On Mon, 9 Jan 2023 11:42:42 +0100 Biselx Nicolas <nicolas.biselx(a)epfl.ch> wrote: > In attachement, the debug with the list of ports It did find some 118 interfaces on the Fortigate, but no IP address information. Apparently, if found nothing useful in the IP-MIB: > 2023-01-09 11:27:03,353 [DEBUG plugins.prefix.prefix] [inventory fortigate] Trying address tables from IP-MIB > 2023-01-09 11:27:03,371 [WARNING plugins.prefix.prefix] [inventory fortigate] device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143') > 2023-01-09 11:27:03,371 [DEBUG plugins.prefix.prefix] [inventory fortigate] Found 0 addresses in IP-MIB: set() That is, it seems to have found *something*, but it didn't quite conform to that is expected in the MIB (the 1.10.0.2.49.143 value is invalid, as it is marked as a 4-octet IP address, but it contains 5 octets). Do you have the NET-SNMP command line tools and basic MIBs available on your system? Might be interesting to get a raw view of that the device presents, using something like these two commands: snmptable -v2c <community> <fortigate-ip-addr> IP-MIB::ipAddrTable snmptable -v2c <community> <fortigate-ip-addr> IP-MIB::ipAddressTable -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research

1 0

Fortigate firewall
by Biselx Nicolas 02 Jan '23

02 Jan '23

Hi, We have a Fortigate firewall that I introduced with the GW category (routers layer 3 device), all information seems ok according to the capture. But when I look at the tools > watchdog there is a problem with the routing interfaces not being recognized ? It's a same with GSW Is there a solution to fix this? Regards, Nicolas

2 3

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users January 2023