What process is using 169.254.183.139

Installing and Using OpenWrt
1

Under status connections I see ip addresses 169.254.183.139 being used.
As far as I can trace it down, it is used within openwrt.
No node on the local Lan can ping it, only from cli op openwrt itself.
From a google search it seems that address is used when dhcp did not return an request and the node reverts to this address.

Using ping 169.254.183.139 and tcpdump I see mac addresses 00:00:00:00:00:00 used.

root@OpenWRT/tmp# tcpdump -e -v --interface any  dst  169.254.183.139
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
23:21:13.963362 lo    In  ifindex 1 00:00:00:00:00:00 (oui Ethernet) ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 35883, offset 0, flags [DF], proto ICMP (1), length 84)
    169.254.183.139 > 169.254.183.139: ICMP echo request, id 31635, seq 236, length 64
23:21:13.963407 lo    In  ifindex 1 00:00:00:00:00:00 (oui Ethernet) ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 35884, offset 0, flags [none], proto ICMP (1), length 84)

Anyone have any idea what process in openwrt is using this address?

2

Show us above. Remove anything identifying but if it's a MAC take note yourself and just delete the address, not the line that contains it.

3

mac address 00:00:00:00:00:00 is returned by tcpdump, so no private info shown. Question is where does the 169.254.183.139 address comes from? Some process in openwrt must generate it but why and why an all zero mac address

4

169.254.x.x is known as an Automatic Private IP Addressing (APIPA) address. As of Windows Vista, ALL devices must have an IP address so Windows can’t find a DHCP server and you do not force a static address, it will automatically assign itself a 169.254.x.x address.

2 Likes
5

A Windows machine on your network, as @thess said.

Because it is not responding to arp requests.

Make sure all your Windows machines are configured for dhcp (or have static addresses).

Why would you think that? OpenWrt does not use APIPA.

1 Like
6

There are no windows based nodes on the lan and ping to that address only works on the openwrt router. None of the other compute node can ping that address. Wireshark does not see it on the lan network.
Just upgraded to 24.10.1, never noticed this on earlier releases.
The ip address 169.254.183.139: only makes connections to 53 tcp ports of various dns servers.

IPV4 UDP 169.254.183.139:52343 8.8.8.8:53 146 B (2 Pkts.)

Plot thickens, added a firewall rule to block any traffic from 169.254.183.139, to any zone.
No effect, but mac address shown in the firewall rule ( when looking at IP address field when editing the rule) shows the router's mac address!
The rule does not seem to block the traffic to outgoing dns servers

7

Try arp command, is there any info?

8

No reference to 196.254.183.139 on the output of arp unfortunately

9

ip address gives the following output:

 ip address | fgrep 139
    inet 169.254.183.139/16 brd 169.254.255.255 scope global noprefixroute eth0
10

found the following in syslog, eth0 is WAN port and does received an IP address via dhcp from ISP provider, why this address is added is a mystery to me

Apr 18 12:55:17 2025 daemon.info dhcpcd[2488]: eth0: using IPv4LL address 169.254.183.139
Fri Apr 18 12:55:17 2025 daemon.info dhcpcd[2488]: eth0: adding route to 169.254.0.0/16
Fri Apr 18 12:55:17 2025 daemon.info dhcpcd[2488]: eth0: adding default route
Fri Apr 18 12:55:17 2025 daemon.info dhcpcd[2488]: eth1: deleting default route
Fri Apr 18 12:55:17 2025 daemon.info avahi-daemon[2900]: Registering new address record for 169.254.183.139 on eth0.IPv4.
11

I haven't upgraded to 24.10.1 yet, so could you please clarify whether udhcpc has been replaced with dhcpcd as the default dhcp client, or you did it for some reason.

In my experience dhcpcd assigns a link-local address if the DHCP server does not respond quickly enough.

You should be able to change this behavior by adding noipv4ll to /etc/dhcpcd.conf.

1 Like
12

I have the following options/packages installed, don't see udhcpc as package option to be installed,

opkg list-installed | fgrep dhcp

collectd-mod-dhcpleases - 5.12.0-r53

dhcpcd - 10.0.10-r1

odhcp6c - 2024.09.25~b6ae9ffa-r1

odhcpd-ipv6only - 2024.05.08~a2988231-r1
13

looking at startup I see two dhcp processes, should there be only one?

image
image2108×204 43.5 KB

14

This is not part of the default image:

Did you install it yourself?

1 Like
15

It is part of busybox.

16

Did you install it yourself?

Not that Im aware off, is there a way to see if there are dependencies on other packages.
If there are no dependencies, is it safe to remove and the udhcpc taking over the functionality?

17

Adding the noipv4ll did solve the issue. See also https://github.com/NetworkConfiguration/dhcpcd/issues/330

Looking at the syslog at the boot phase it seems that bringing up the network interfaces seem to be to early in the boot sequence.
Bringing up WAN ( eth0) fails first time, no carrier. After LAN (eth1) is brought up, the WAN interface is tried again successfully.

1 Like
18

Disabled dhcpcd in system -> startup menu. No negative impact , rebooted the router, things still ok. So deleted the dhcpcd package. All fine. No idea why it ended up in my router on the first place.

19

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.