Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Fortinet FortiOS Shenanigans (Christian Ramseyer)
2. Re: Fortinet FortiOS Shenanigans (Michael Butash)
--- Begin Message ---
On 16.03.2025 22:12, Michael Butash wrote:
Ahh, so money! Yeah, once I found a reference on how to set bulkget_no
(thanks mailing list, your docs *should* really give an example of
use.. :)), it ran right through with no issues using getnext. Reading
the doc didn't make any sense where to use it, searches turn up
nothing on how or where to declare this, even chatgpt said I should
jab it into the device_auth section, but otherwise... Thank you!!
So now the question is why is ND misbehaving? There really is little
configuration difference between the working fortigate and not working
one, particularly nothing special around SNMP, so I have no idea why
ND would behave like this for one fortigate and not another. This
seems more of a ND problem than the fortigate.
Nice we've made some progress, excellent :)
I doubt its ND, having crappy bulkget implementations is a tradition
across many vendors. I'm pretty sure you'll get the same result when
pointing "snmpbulkwalk" at the same ifStackStatus subtree.
And yes, I'm a dork re: discover vs arpnip, I was doing discovery.
Sorry for barking up the wrong tree.
Still though, it seems to try, but fails weirdly with an error about
.libnet-openssh-perl not being secure. I wasn't really sure what part
it was considering "not secure", chatgpt seemed to think it was
related to the directory not being secure, but it's chmod 700 to
netdisco only, not sure how much more secure it wants it. I can ssh to
the device normally with that account otherwise from the server.
[2179658] 2025-03-16 20:41:55 error [10.0.0.10] ssh connection error
[ctl_dir /opt/netdisco/.libnet-openssh-perl/ is not secure]
[2179658] 2025-03-16 20:41:55 debug ⬅ (defer) arpnip failed: could not
SSH connect to 10.0.0.10
It's probably the /opt/netdisco directory that's still group writeable
or worse, openssh doesn't like that. chmod 755 (or 700, 750) on it
should fix it.
Cheers
Christian
--- End Message ---
--- Begin Message ---
Ahh, yes chmod 755 on the directory worked for the arpnip! Ok, I guess I'm
not a very good sysadmin not knowing/realizing that as a security thing,
but didn't think (and never have) much about it.
Great, I was going more for completeness since I saw there was a forti ssh
collector now in there, as neighbors aren't figuring themselves out for me
at all here. LLDP still isn't figuring out neighbors between my catalysts
and fortiswitches, but it's a small enough network I just added manual
links for them anyways. I may still follow up separately on that as LLDP
info is being found, just not showing on ports or linking topology
neighbors.
Regarding having to bulkwalk_no the single host, I'd probably blame
Fortinet if it weren't for the fact 2 out of the 3 work normally, another
hub and a branch spoke all poll just fine. Even weirder it gets stuck on a
stack oid that most certainly isn't present on the fortigate, and
repeatedly with no delay or waiting for a response. The fortigate seems to
ignore it as an invalid mib, but they show incoming as quick as the
terminal will scroll.
I'm curious enough now I'm going to pull a full debug on the working and
not-working devices (both virtual in azure too, the spoke is a physical
100F) and see, maybe open a ticket too as I've had enough weirdness on this
deployment we're old friends they and I. I'll follow up if I get a better
answer. I'm open to share them unicast back to you if interested to have a
look.
Oh, separate note on your memory leak - maybe unrelated, but thought I'd
mention it... Another long-time customer of mine randomly started having
fortigate issues back in October with the IPS randomly starting to OOM the
box into conservation mode, and after a few months found out it was a bad
IPS engine update they pushed randomly (oct 26th if I remember right). I
think it got fixed officially in a january maintenance release, but I had
to get a specifically fixed IPS engine version for some older 7.2 boxes we
had that we didn't want to upgrade yet. IPS stuck out like honeymoon wood
for the top memory consumer out of nowhere on only one box of many. I was
surprised that it didn't get more public attention affecting folks,
fortinet support seemed to know about it after a few cases over months
about it running through hoops.
Thanks again Christian, really appreciate the answers and your experience!
-mb
On Sun, Mar 16, 2025 at 2:42 PM Christian Ramseyer <ramse...@netnea.com>
wrote:
>
>
> On 16.03.2025 22:12, Michael Butash wrote:
> > Ahh, so money! Yeah, once I found a reference on how to set bulkget_no
> > (thanks mailing list, your docs *should* really give an example of
> > use.. :)), it ran right through with no issues using getnext. Reading
> > the doc didn't make any sense where to use it, searches turn up
> > nothing on how or where to declare this, even chatgpt said I should
> > jab it into the device_auth section, but otherwise... Thank you!!
> >
> > So now the question is why is ND misbehaving? There really is little
> > configuration difference between the working fortigate and not working
> > one, particularly nothing special around SNMP, so I have no idea why
> > ND would behave like this for one fortigate and not another. This
> > seems more of a ND problem than the fortigate.
>
> Nice we've made some progress, excellent :)
>
> I doubt its ND, having crappy bulkget implementations is a tradition
> across many vendors. I'm pretty sure you'll get the same result when
> pointing "snmpbulkwalk" at the same ifStackStatus subtree.
>
> >
> > And yes, I'm a dork re: discover vs arpnip, I was doing discovery.
> > Sorry for barking up the wrong tree.
> >
> > Still though, it seems to try, but fails weirdly with an error about
> > .libnet-openssh-perl not being secure. I wasn't really sure what part
> > it was considering "not secure", chatgpt seemed to think it was
> > related to the directory not being secure, but it's chmod 700 to
> > netdisco only, not sure how much more secure it wants it. I can ssh to
> > the device normally with that account otherwise from the server.
> >
> > [2179658] 2025-03-16 20:41:55 error [10.0.0.10] ssh connection error
> > [ctl_dir /opt/netdisco/.libnet-openssh-perl/ is not secure]
> > [2179658] 2025-03-16 20:41:55 debug ⬅ (defer) arpnip failed: could not
> > SSH connect to 10.0.0.10
> >
>
> It's probably the /opt/netdisco directory that's still group writeable
> or worse, openssh doesn't like that. chmod 755 (or 700, 750) on it
> should fix it.
>
> Cheers
> Christian
>
>
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
