Hello, I've been experiencing a strange problem related to my probe for several years. My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router. For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following: Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 The destination address belongs to my 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. 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. 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. I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation. Regards.
Who is the isp involved for connectivity ? Col Sent from my iPhone
On 6 Aug 2026, at 04:51, Daryl Morse <daryl_morse@telus.net> wrote:
Hello,
I've been experiencing a strange problem related to my probe for several years.
My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router.
For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following:
Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
The destination address belongs to my 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.
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.
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.
I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation.
Regards. ----- 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/
My ISP is Telus. On Wed, Aug 5, 2026 at 10:34 PM Colin Johnston <colinj@mx5.org.uk> wrote:
Who is the isp involved for connectivity ?
Col
Sent from my iPhone
On 6 Aug 2026, at 04:51, Daryl Morse <daryl_morse@telus.net> wrote:
Hello,
I've been experiencing a strange problem related to my probe for several years.
My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router.
For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following:
Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
The destination address belongs to my 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.
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.
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.
I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation.
Regards. ----- 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/
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.
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?
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.
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¤t_p...
-- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Thank you for your reply. See below [DM]. -----Original Message----- From: Marco Moock <mm@dorfdsl.de> Sent: Wednesday, August 5, 2026 10:43 PM To: ripe-atlas@ripe.net 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¤t_p...
[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 trashcan@stinkedores.dorfdsl.de
I'm surprised to see an IPv6 packet with link local scope source and a global scope destination. According to RFC3848 and RFC6724 this should not happen (prefer the larger scope, when choosing a source address from several candidates). Also RFC 4291:
2.5.6. Link-Local IPv6 Unicast Addresses
Link-Local addresses are for use on a single link. Link-Local addresses have the following format:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present.
Routers must not forward any packets with Link-Local source or destination addresses to other links.
Strange to see a Probe selecting a link-local as source.... On 2026-08-06 05:50, Daryl Morse wrote:
Hello,
I've been experiencing a strange problem related to my probe for several years.
My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router.
For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following:
Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
The destination address belongs to my 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.
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.
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.
I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation.
Regards.
----- 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/
-- NetCaT GmbH, Bennogasse 13/5, 1080 Wien FN 433437 h, Handelsgericht Wien, UID: ATU69635335 GF: Michael Kafka, Georg Kraus
i've had such messages for over a decade when i moved to newer fbsd in my case it's custom and not pfsense i even reported the strange global ll issues here but nobody responded. it's in the ml archives google finds me other people too with this there are those lines: Aug 6 16:14:00 green kernel: cannot forward src fe80:29::4e6d:580f:fc89:81ae, dst 2 001:7d0:8437:13bf:da58:d7ff:fe03:1274, nxt 58, rcvif vlan3, outif vlan91 Aug 6 16:15:27 green kernel: cannot forward src fe80:29::4e6d:580f:fc89:81ae, dst 2 001:7d0:8437:13bf:da58:d7ff:fe03:1274, nxt 58, rcvif vlan3, outif vlan91 Aug 6 16:16:03 green kernel: cannot forward src fe80:29::4e6d:580f:fc89:81ae, dst 2 001:7d0:8437:13bf:da58:d7ff:fe03:1274, nxt 58, rcvif vlan3, outif vlan91 vlan3 is wan, vlan91 has v5 probe with id 65133 in it 16:20,root@green:~# zfgrep 'cannot forward src' /var/log/all.log* | wc -l 15826 there are 16k of them in a week it's telia estonia gpon link i don't use any of their l3 cpe, only l2 one. well technically it does l3 too and i can monitor my huawei echolife hg8010h, but anyway should i report it to isp? you indeed can't forward ll to gua i don't know what crazy access network they have from public information on switch to ipv6 it showed that they have to waddle through deep (hu)manure powered by enterprise network gear sold to them e.g. <https://labs.ripe.net/author/tarko_tikan/ipv6-deployment-in-estonia/> so maybe it's not surprising if we get such errors? funnily at first i assumed those were bcp38 tests but then i was like wait it comes in from wan On August 6, 2026 2:08:54 PM GMT+03:00, Michael Kafka via ripe-atlas <ripe-atlas@ripe.net> wrote:
I'm surprised to see an IPv6 packet with link local scope source and a global scope destination.
According to RFC3848 and RFC6724 this should not happen (prefer the larger scope, when choosing a source address from several candidates).
Also RFC 4291:
2.5.6. Link-Local IPv6 Unicast Addresses
Link-Local addresses are for use on a single link. Link-Local addresses have the following format:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present.
Routers must not forward any packets with Link-Local source or destination addresses to other links.
Strange to see a Probe selecting a link-local as source....
On 2026-08-06 05:50, Daryl Morse wrote:
Hello,
I've been experiencing a strange problem related to my probe for several years.
My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router.
For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following:
Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
The destination address belongs to my 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.
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.
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.
I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation.
Regards.
----- 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/
Am 06.08.26 um 13:08 schrieb Michael Kafka via ripe-atlas:
I'm surprised to see an IPv6 packet with link local scope source and a global scope destination.
According to RFC3848 and RFC6724 this should not happen (prefer the larger scope, when choosing a source address from several candidates).
True, but some machines do not implement that properly and generate such message. Some may also do that intentionally for attacks etc. It is reasonable for routers not to forward, but drop them (you cannot reject them with ICMP unreachable, as the sender address will never be reachable). Although, that involves a check and I assume that the routers in large transit networks do not have such checks enabled to save CPU cycles. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
It is reasonable for routers not to forward, but drop them (you cannot reject them with ICMP unreachable, as the sender address will never be reachable). Although, that involves a check and I assume that the routers in large transit networks do not have such checks enabled to save CPU cycles.
Interesting thought. I would assume such drop rules are implemented in TCAM On 2026-08-06 16:07, Marco Moock wrote:
Am 06.08.26 um 13:08 schrieb Michael Kafka via ripe-atlas:
I'm surprised to see an IPv6 packet with link local scope source and a global scope destination.
According to RFC3848 and RFC6724 this should not happen (prefer the larger scope, when choosing a source address from several candidates).
True, but some machines do not implement that properly and generate such message. Some may also do that intentionally for attacks etc.
It is reasonable for routers not to forward, but drop them (you cannot reject them with ICMP unreachable, as the sender address will never be reachable). Although, that involves a check and I assume that the routers in large transit networks do not have such checks enabled to save CPU cycles.
----- 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/
-- NetCaT GmbH, Bennogasse 13/5, 1080 Wien FN 433437 h, Handelsgericht Wien, UID: ATU69635335 GF: Michael Kafka, Georg Kraus
participants (6)
-
Colin Johnston -
Daryl Morse -
daryl_morse＠telus.net
-
Marco Moock -
Michael Kafka -
Sulev-Madis Silber