Messages

> Nonetheless... that person is a troll. Floodding the forum with bullshit bingo, which potentially harm others.

Yeah, trolling back is not a great plan.

Just report the thread(s) and we'll deal with it.


Cheers,
Franco

@fastboot you posted this 3 times. If I see another one you get a temp ban because this is will be considered spam.


Cheers,
Franco

This is a known issue on LTE connections.


Cheers,
Franco

You'll need to be a lot more specific please.


Cheers,
Franco

On ixl cards? Intel probably just broke it again after I had to advocate for a revert when the first commit came in.

https://github.com/opnsense/src/commit/aa1fce8528200

Good luck with that.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283820


Cheers,
Franco

Yes, years ago.


Cheers,
Franco

"force down" isn't about fbsd at all, it's a sense thing that came to be with the gateway monitoring and is effectively labelled incorrectly. It's more of a "do not use for automation" flag with the twist that it blanks the status for the gateway. Won't be easy to clean this up.  ;)


Cheers,
Franco

> I have the same problem

I don't?  :)

If you're not using static ARP and the neighbor is found via ARP it's not going anywhere.


Cheers,
Franco

If you have a concept for it you can open a ticket and see.

For now I noted your wish, but would like to hear from others in unrelated topics, too. So far this is the only one I've heard.


Cheers,
Franco

Hey,

Already saw your Reddit post.  The plugin has a hook for bootup-time and for newwanip-time reconfiguration.

> Is it possible during boot igmpproxy try to starts before the WAN/LAN interfaces are fully up?

This would be my guess like a hiccup in the initiation sequence.  It's a bit strange that since we do have newwanip reconfiguration that should take care of dynamic scenarios.

The big question is which WAN scenario is this? Plain DHCP, or PPPoE or some sort of DSLite tunneling or VPN trickery?


Cheers,
Franco

Normally they continue to work until reconfigured, but since the recent blocklists changes require to move data around you're more or less forced into a reconfiguration.  In this case the blocklists already stopped working.


Cheers,
Franco

You're not posting your update attempt logs here either.  I'm not sure how to help in that case other than give moral rubber duck support.  ;)


Cheers,
Franco

I tested on 25.7.10 and it adds and deletes the neighbor entry from the configuration.

It likely does not remove the neighbor from the ARP table until a reboot. Static ARP in ISC DHCP may change that if you apply there but that's for historic reasons.  There are upcoming changes related to these topics in 26.1.

So in case I haven't answered your question or bug can you be more precise?


Thanks,
Franco

Great, thank you!  :)