R7800: understanding some packets emitted from router to APIPA address

[HELLO_wORLD]

Hi,

I try to understand some packets that my R7800 is sometimes attempting to send to the WAN. They are intercepted by Aegis, and are not frequent, so this is not a big issue, but I would like to know why they are emitted, and by which process?
Here are two samples:

IN= OUT=brwan SRC=[MY PUBLIC IP] DST=169.254.1.2 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=19613 PROTO=ICMP TYPE=11 CODE=1 [SRC=169.254.1.2 DST=169.254.1.1 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=29306 MF PROTO=UDP SPT=52310 DPT=2325 LEN=1849 ]
IN= OUT=brwan SRC=[MY PUBLIC IP] DST=169.254.1.2 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=3374 PROTO=ICMP TYPE=11 CODE=1 [SRC=169.254.1.2 DST=169.254.1.1 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=29376 MF PROTO=UDP SPT=52310 DPT=2325 LEN=1850 ]

It looks that it is not a forwarded packet, so it is coming from the router.
It aims an APIPA address 169.254.1.2, but no interface on the router has such an address. Furthermore, no device on my LAN has any address in this range.
The packets are ICMP type 11, Time exceeded message with error code “Fragment reassembly timeout”

It seems it is in answer to an UDP packet from 169.254.1.2 to 169.254.1.1, but 1) I don’t see this packet coming from WAN, and 2) why would the R7800 answer to such a packet anyway?

 

[sfx2000]

169.254.0.0/16 is the link-local range - it's internal to the lan, and not routable.

Probably nothing to worry about.

 

[HELLO_wORLD]

169.254.0.0/16 is the link-local range - it's internal to the lan, and not routable.

Probably nothing to worry about.

Yes, it is in the range of Automatic Private IP Addressing. These addresses are self-given by devices that cannot get a DHCP lease.

I know these packet are harmless, but it is abnormal, as:
1) I don’t have any device (or router interface) in this range,
2) These ICMP packet are an error message sent in answer to a packet that my router is therefore supposed to have received, but there is no trace of such packets incoming! So what is my router answering to?
3) As you mentioned, this address should be internal to the LAN, but my router is trying to send this to the WAN.

I am not worried, but I would like to make sense of why this I happening. Curiosity, wanting to understand.

 

[R. Gerrits]

Could it be that this communication is between your router and your ISP modem? i.e. that during DHCP renewal temporary APIPA adresses are configured?

perhaps run a tcpdump on filtering on these IP-addresses. Perhaps then you also see mac-addresses ?

 

[HELLO_wORLD]

Could it be that this communication is between your router and your ISP modem? i.e. that during DHCP renewal temporary APIPA adresses are configured?

perhaps run a tcpdump on filtering on these IP-addresses. Perhaps then you also see mac-addresses ?

No ISP modem. Router goes straight to ONT (transparent device, no IP). My first hop on WAN is ISP GPON gateway.

I should see any incoming packet from WAN with APIPA (INCOMING or FORWARD) but nothing.
I created a logging rule in mangle table PREROUTING to report any incoming APIPA (WAN or LAN). We will see...

 

[HELLO_wORLD]

Ok, there is definitely nothing incoming.

When the router sends its ICMP error, there is absolutely no incoming packet from WAN or LAN coming from or to 169.254.0.0/16
Meaning the log mentions the ICMP is in response from [SRC=169.254.1.2 DST=169.254.1.1 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=29306 MF PROTO=UDP SPT=52310 DPT=2325 LEN=1849 ], but the router never received this packet!!!!

So it seems that for some reason, the kernel thinks it received an incomplete fragmented packet from 169.254.1.2 and is sending the ICMP error message. But this packet was never received, or was generated by the router itself.

Is anyone else having anything like this?

 

[HELLO_wORLD]

The only code in the firmware that seems to deal with this type of address is avahi:

root@HERMES:~$ grep -rnF '169.254' /rom
/rom/etc/avahi/avahi-autoipd.action:45:            ip addr add "$3"/16 brd 169.254.255.255 label "$2:avahi" scope link dev "$2"
/rom/etc/avahi/avahi-autoipd.action:51:            ip addr del "$3"/16 brd 169.254.255.255 label "$2:avahi" scope link dev "$2"
/rom/etc/avahi/avahi-autoipd.action:66:            ifconfig "$2:avahi" inet "$3" netmask 255.255.0.0 broadcast 169.254.255.255 up
/rom/etc/init.d/br-mode:158:    if [ "${lan_ipaddress%.*.*}" = "169.254" ]; then
grep: /rom/sbin/led-extender: binary file matches
/rom/usr/lib/opkg/info/avahi-autoipd.control:25: from the link-local 169.254.0.0/16 range without the need for a central 
grep: /rom/usr/sbin/avahi-autoipd: binary file matches
/rom/usr/sbin/br-dhcp-helper:20:                if [ "x$old_status" != "x$current_status" -o "x`ifconfig br0 | grep "inet addr:169.254"`" != "x" ]; then
/rom/usr/share/udhcpc/default.script.ap:97:             if [ "${ori_ip%.*.*}" = "169.254" ]; then

It is running by default, so avahi must have a role in this.

BUT this does not explains why this is happening (just that avahi daemon is likely involved in the process), and why WAN interface is involved at all!

 

[HELLO_wORLD]

It seems to confirms that avahi is behind that.

Yesterday, I edited /etc/avahi/avahi-daemon.conf to add this line in the [server] section:
deny-interfaces=brwan

Then I restarted the avahi service from init.d

Since then, I did not see the unexplained ICMP to wan.
Despite the fact that the configuration file contains this:
allow-interfaces=br0
That should allow avahi to be bound to LAN only, it seems that it can leak to WAN, and specifically deny WAN seems to fix this.

@Voxel maybe this line should be added by default in avahi-daemon.conf in the firmware to increase security, as mDNS and other avahi related functions should not ever leak on the WAN?

 

[sppmaster]

It seems to confirms that avahi is behind that.

Yesterday, I edited /etc/avahi/avahi-daemon.conf to add this line in the [server] section:
deny-interfaces=brwan

Then I restarted the avahi service from init.d

Since then, I did not see the unexplained ICMP to wan.
Despite the fact that the configuration file contains this:
allow-interfaces=br0
That should allow avahi to be bound to LAN only, it seems that it can leak to WAN, and specifically deny WAN seems to fix this.

@Voxel maybe this line should be added by default in avahi-daemon.conf in the firmware to increase security, as mDNS and other avahi related functions should not ever leak on the WAN?

I completely agree with the last statement.

 

[HELLO_wORLD]

I was away from home for a few days. Coming back, I see in the log that there was one ICMP packet from router to 169.254.1.2 in the last 24h.
So if adding the rule in avahi did reduce the amount, it is not enough to completely solve it. I will keep monitoring now that I am back home.