@jimp said in Packages 24.11 Issue:

Plus 24.11 should be good now, the others are still rebuilding and will be fixed shortly.

Confirmed, thanks Jimp, 24.11 fixed already.

I've been able to confirm...

If the interface does not show in the PIMD Virtual Interface Table on the Status Tab, it gives the "Invalid phyint address" error in the logs. Sooo....

It appears that there is some limit that is preventing PIMD from seeing all the interfaces. The closest information I found is related to Linux and the limit is defined in the kernel...

I'm guessing even though I've been able to reverse my settings and avoid the errors in the logs, that any interfaces not shown in the Table are just ignored and are not participating in IGMP :-(

another optoin to avoid 0.0.0.0 &169.254.0.0 spam is to igmore the mac-addr's
from arpwatch>settings, click the +Add button at the bottom
add any mac you don't want alerts for

That alert is coming from the built-in QUIC-events rules that ship with the Suricata binary.

The events rules are simply informational in nature and don't indicate any malware or other compromise. I suggest disabling that rule or else using the "suppress by SID" feature on the ALERTS tab to prevent the alert the resulting block of a host.

Hi Patch,

Thank you for your help.

Just a side note.. I have not always set the "proxy" in my client devices and it still would work.. but sometimes the client device would bypass the proxy and cause me issues.

@jasch
Thanks.
I finally got around to try again. But to no avail. I allow everything through (any/any/any/any -you get the drift). It seems like both ends, music streamer on LAN and smartphone on OPT1, succeeds in passing multicast traffic to the multicast addresses. But the phone is still not aware of the streamer's existence unless I put them on the same subnet.
I think I have to give up. I am too much fumbling in the dark.

@jwilli5646
AFAIK this is normal behavior, old states remain on the backup until they expire, new one will be created on the primary WAN, if you search the forum there was someone who invented some script to automate this If my memory's correct

@Uglybrian Appreciate that feedback. Why would cpu usage be at 23% if at idle thats where I am getting confused. Cpu usage has for the most part been half this number or lower and system activity is not showing it working on anything to justify the 23%. I may be looking at this wrong but to my mind cpu usage would be a representation of how much the cpu is being put to work on a task/function. I am assuming idle is the correct state given the command column contents and everything else in the system activity is or was at 0.00%.

@pfpv from what I remember the android was the biggest pain.. And someone at the time there was a thread going about on it couldn't get his android to add the ca at all.. But our versions were different.

With ios, I do recall having to do something with the password on the cert or pk12 because it didn't like just blank so used openssl to add a password.. I think you can do it now in the gui.

Windows I had to manually change the mode of the connection to enterprise I believe.

Oh and think there was something about having to set legacy in the openssl cmd to get accepted as well.. But what I can tell you for sure is once their added it doesn't ask you to retrust them on every connection, etc.

Haven't played with it long time, sorry.. But my iphone is using it - and its gone through multiple upgrades to the IOS and still working, etc.

@Gertjan said in Freeradius3: No more automatic service restart upon config change?:

But : where do you see them ? The command line ?

I see these messages in the system log in the pfSense GUI.

@Gertjan said in Freeradius3: No more automatic service restart upon config change?:

are normal messages.
When settings are changed in the pfSense GUI for Freeradius, the process gets restarted.

I also thought they were normal and expected but the title of this thread is "no more automatic service restart upon config change". Somehow this is not happening to the OP.