Messages

https://github.com/opnsense/hostwatch/issues/21

Hope that works for you. I'm sick (and bored) in my bed and typing on my phone, not the ideal environment for programming stuff...

@troplin best track coding things in the repository in an issue.

Ok, can do that. Is there already one that fits or should I create a new one?

@franco maybe this line?
https://github.com/opnsense/hostwatch/blob/3000f8f6611c098a7e7d01eaa0253b31c6af9ca3/src/database.rs#L141

Shouldn't that be

Code Select Expand

when real_ether_address = excluded.real_ether_addressInstead of

Code Select Expand

when ether_address = excluded.real_ether_address?

EDIT:
Also, this condition is always true:
https://github.com/opnsense/hostwatch/blob/3000f8f6611c098a7e7d01eaa0253b31c6af9ca3/src/lib.rs#L196
Because in the SQL statement prev_ethernet_address is only updated when ethernet_address actually changes.

@franco Even if the log message has been fixed (and is now disabled), it still makes no sense:

Firstly,

Code Select Expand

00:1d:63:63:eb:35 is the MAC address of my dishwasher and

Code Select Expand

64:62:66:22:44:8c is the LAN interface of the OPNsense box itself. The IPv6 address is the link-local address of the OPNsense box.
So why would hostwatch think that the LLA of the OPNsense box itself has been previously used by my dishwasher?

Secondly, the message is always just ,,host X moved from A to B", shouldn't the database be updated to reflect that after the fist time? There are no messages the opposite way, i.e. ,,host X moved from B to A".

I still believe that the logging issue is just a symptom of the actual problem, e.g. you're somehow comparing the wrong addresses.

Maybe I just don't understand it completely but those movement messages seem odd to me.

In my log I see the same message over and over again:

Code Select Expand

INFO hostwatch: changed ethernet address host 00:1d:63:63:eb:35 moved from 64:62:66:22:44:8c to fe80::6662:66ff:fe22:448c at igc1
The message makes no sense to me, how can it move from a MAC address to an IPv6 address? Could there be a confusion of variables in the code?

Also the fact that it is the same message over and over again kind of makes me a bit suspicious that there might be an error in the code where the previous and current address are compared, or that the state isn't updated correctly.

Anyway I thought including FireHOL and Spamhaus by default would be a no-brainer. Reputable open sources.

When I was setting up my blocklists some time ago I was curious which FireHOL level to use and did some digging.

I noticed that quite a few source lists in there are stale. Some have changed the URL or format or are not (publicly) available anymore.

Since FireHOL keeps the last available copy of all sources in its own repo, that means (for better or worse) that it probably contains a lot of IPs that at some point were part of a source blocklist but aren't anymore.

Another interesting detail: it looks there are always multiple log entries with the same source port when this happens.
So either a single packet generates multiple log entries or it's the other way round: two packets with the same source port arriving at the same time are causing the issue.

In either case, this screams ,,race condition" if you ask me...

Might be a coincidence but I've noticed that all the timestamps end in ~55s.
Could this be caused by some scheduled job that runs every N minutes, like the table update?

Here's what I think happened:

• At one point the alias had the correct type ,,Network(s)" and correct 33 entries.
• Then you switched it to the incorrect type ,,URL Tables" for reasons unknown to me.
• Since the ,,URLs" are obviously not valid blocklist URLs, the (resolved) alias content is not updated and still contains those 33 networks.
• While the type is still ,,URL Tables" you added two networks. But still none of the values are valid blocklist URLs, so the table still contains the last valid list, i.e those 33 networks.
• Now you have changed the type back to ,,Network(s)" but since the content field hasn't changed and this is not a dynamic type, the (resolved) alias table isn't updated.

I can reproduce the behavior. I guess this wasn't considered a valid use case (understandably so).

Just make some actual changes to the contents field and the alias will be updated.

Did you actually hit the ,,Apply" button at the bottom of the Aliases page after adding the new entries?

A ,,Network(s)" alias is completely static, the contents don't change unless you change them yourself (or if the alias references other dynamic aliases).
So it's completely expected that the update date doesn't change as well.

Also, the Cron job seems completely pointless to me. Dynamic aliases (e.g. ,,URL Tables") are already updated automatically without an explicit Cron job, based on the individual update settings of that specific alias.

Something else I just noticed: in my DCHP logs I'm seeing a lot of redundant requests from the devices that I'm having trouble with, like:

Code Select Expand

2025-03-16T16:27:19-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Debug dhcpd reuse_lease: lease age 299 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Debug dhcpd reuse_lease: lease age 299 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Debug dhcpd reuse_lease: lease age 265 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Debug dhcpd reuse_lease: lease age 265 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115

and that seems weird?

That might be just a TP-Link thing. My TP-Link APs (consumer grade, not Omada) are doing it as well. I suspect they are (ab)using DHCP as some kind of connectivity probe. I find it quite annoying.

I don't think it can be port forwarding.

In the screenshot of the first post you say that the source IP is the IP of the firewall itself. That means that the traffic has to come from OPNsense. Port forwarding does not change the source address of the packet, only the destination.

he's already said he's not using that feature ;)

I was just explaining why I asked that question.

Thank you very much again for your messages.

Do you have backup to git enabled?

Well, I am not using that feature for the moment. It looks great and can be very helpful, but at the same time, it is not making your configuration public, is it?

It can be a git server in your own network, it doesn't have to be a public one like GitHub.

But that's not the point. Git uses SSH to connect to the server which could explain the outgoing connections.

Do you have backup to git enabled?