Thank you for your reply.

See below [DM].

-----Original Message-----
From: Marco Moock <[email protected]> 
Sent: Wednesday, August 5, 2026 10:43 PM
To: [email protected]
Subject: [atlas] Re: Probe 52209

Am 06.08.26 um 05:50 schrieb Daryl Morse:

> The destination address belongs to my probe.

I can properly ping your probe and did successful measurements with it. 
Seems your probe and your network are not the issue.

[DM] The only such messages I'm seeing in the log on the WAN side are related 
to the probe. There are a very small number of them originating in the LAN, but 
they have nothing to do with the probe.

> For a while I wondered what caused the "5" in the fe80:5::* link-local 
> address, but apparently, FreeBSD, on which pfSense is based, inserts 
> it to denote that the link-local address is associated with the WAN interface.

Is it assigned to it?
Can you see it via netstat -in in FreeBSD/pfsense?

[DM] I originally thought the address was being mangled due to an error or 
something after I used wireshark to capture the original messages. I posted 
about it in the pfsense forum and got no support until someone found in the 
freebsd documentation that it is being done intentionally. I just googled it 
using AI mode and it said this: What you are seeing is an embedded scope ID 
inside the second hextet of the address. This is a unique quirk of the KAME 
IPv6 stack used by FreeBSD, OpenBSD, NetBSD, and macOS.

[DM] Here is the respective line from netstat -rn:
fe80::%hn0/64                     link#5                        U               
hn0

> You can see that the messages are periodic, occurring every 4 seconds. 
> The addresses are not random. They repeat. I presume that the multiple 
> addresses indicate multiple measurements associated with my probe.
> 
> I connected Wireshark to the WAN interface and verified the packets 
> are present, but without the "5".
> 
> The problem is not that pfSense is logging these messages. It's 
> behaving properly.
> 
> I'm wondering why the messages have a link-local source address. The 
> only explanation is that the ISP router is converting routable GUA 
> addresses to non-routable link-local addresses, otherwise, the packets 
> could not have been routed to my probe. Since these packets are 
> arriving at my router, this conversion must be happening in the ISP 
> router at the other end of the fibre.

Technically, routing uses the destination address, so such packages can be 
delivered to you. Some ISPs and IXPs may filter them out, some may not (such 
checks need some CPU cycles).

Certain operating systems refuse to route them, as the RFC disallows that.

I've also seen packets with ULA as src and also NDP targeted to my public 
addresses from far away.

[DM] When I get a chance, I'll run wireshark again and capture everything sent 
to the probe to see how common the link local source addresses are.

> I'm wondering if there is any way to get a log of the measurements 
> being run against my probe. If I could see that the messages in my log 
> correspond to measurements against my probe, I could provide that 
> information to my ISP to diagnose the cause.
https://atlas.ripe.net/measurements/public?sort=-id&id__gt=1000000&current_probes=52209&toggle=all&page_size=100&page=1

[DM] Thanks for the link to look at the measurements. I'll try to compare the 
results to the log.

--
Gruß
Marco

Junk-Mail bitte an [email protected]

-----
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Reply via email to