# WTF is udhcpc and why did it run?

## curmudgeon

After experiencing days of absolutely horrible network performance, an investigation revealed that /etc/resolv.conf had been wiped out (not even backed up) and replaced with:

```

# Generated by udhcpc for eth0

search localdomain.loc

nameserver 1.2.3.4

nameserver 1.2.3.5

```

I am not using dhcp. My /etc/conf.d/net have the same two lines as always, and I still have the same static address as always.

```

config_eth0='192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0'

routes_eth0='default via 192.168.0.1'

```

What can trigger this, and (more important) how can I keep this from EVER running again?

----------

## krinn

 *curmudgeon wrote:*   

> 
> 
> What can trigger this, and (more important) how can I keep this from EVER running again?

 

To make story short, udev was update, a note has been put udev change network device name, so your config targetting eth0 is targetting a non existing device now, and the new device name (a stupid mqlkdafjqsdmlfksdj like name) now have no rules and so openrc trigger dhcp to get an ip.

If it's that, it's because you didn't read the note, so the answer to "What can trigger this" must be "udev stupid names" & "you".

----------

## curmudgeon

 *krinn wrote:*   

> If it's that, it's because you didn't read the note, so the answer to "What can trigger this" must be "udev stupid names" & "you".

 

I did read that note (especially the part about configuring rules to keep eth0 :) ).

I am still (very much) interested in the idea of some way to completely disable any possibility of a dhcp client automatically running if something fails (that is a very bad idea in my opinion).

----------

## Maitreya

 *curmudgeon wrote:*   

>  *krinn wrote:*   If it's that, it's because you didn't read the note, so the answer to "What can trigger this" must be "udev stupid names" & "you". 
> 
> I did read that note (especially the part about configuring rules to keep eth0  ).
> 
> I am still (very much) interested in the idea of some way to completely disable any possibility of a dhcp client automatically running if something fails (that is a very bad idea in my opinion).

 

Well in this particular case it is probably handy to have it try dhcp. Not everyone reads the notes carefully. So if someone rebooted after the udev update they could still reach it remotely. Also it fires only when it gets a network device, so why not probe for a automatic adres?

----------

## khayyam

curmudgeon ...

simply provide the nameserver, like so:

```
config_eth0="192.168.0.2/24"

routes_eth0="default via 192.168.0.1"

dns_servers_eth0="192.168.0.1"
```

I suspect some hotplugging here as I've not seen udhcpc run when a static address is asigned (though I would generally always provide a nameserver in such cases). Anyhow, none of this should result in "horrible network performance" so the actual issue may be elsewhere.

best ... khay

----------

## curmudgeon

 *khayyam wrote:*   

> Anyhow, none of this should result in "horrible network performance" so the actual issue may be elsewhere.

 

It blew up /etc/resolv.conf (without backing it up, which is doubly annoying). The DNS servers that udhcpc picked up were horrible (minimum fifteen seconds to return anything), and on top of that, I run dnsmasq (which any decent dhcp client would have incorporated into a modified resolv.conf, but udhcpc didn't).

Beyond that, there are security implications involved in running a dhcp client when one is not desired.

Since my question has not been answered yet, I will repeat it - how do I block udhcpc from ever running under any circumstances?

----------

## khayyam

 *curmudgeon wrote:*   

>  *khayyam wrote:*   Anyhow, none of this should result in "horrible network performance" so the actual issue may be elsewhere. 
> 
> It blew up /etc/resolv.conf (without backing it up, which is doubly annoying). The DNS servers that udhcpc picked up were horrible (minimum fifteen seconds to return anything), and on top of that, I run dnsmasq (which any decent dhcp client would have incorporated into a modified resolv.conf, but udhcpc didn't).

 

curmudgeon ... none of which are directly related to the quote above. It "blows up" resolv.conf because dhcp clients do this *unless* they are told not to request DNS (using the "nodns" switch in dhcp_${IFACE}), the dns servers "picked up" are provided by whatever is serving dhcp on the network, and if you want resolv.conf to be handled by multiple sources, or be static, then you need to figure out why udhcpc is started in the first place. As I said, the issue seems to be elsewhere as having a static address defined should be sufficent for the interface to be brought up, and no dhcp client should be called. So, something else is no doubt causing udhcpc to be started, what I can't tell, as there is too little information to go on.

 *curmudgeon wrote:*   

> Beyond that, there are security implications involved in running a dhcp client when one is not desired.

 

There are security implication to any number of things, but it is by understanding the cause behind an event that allows for its mitigation. So, sure, we can state "that shouldn't happen" but that is in the realm of the obvious, and provides no clue as to the why.

 *curmudgeon wrote:*   

> Since my question has not been answered yet, I will repeat it - how do I block udhcpc from ever running under any circumstances?

 

As I stated above with a staticly defined address it shouldn't, so you need to look for the root cause and/or provide some clue as to why it might. Generally, to get your question answered its best to present the question in a way in which others can help, your "question has not been answered yet" because, quite frankly, no one has any idea what might be at work here, all we have is two lines from your /etc/conf.d/net ... and lots of huffing and puffing.

best ... khay

----------

## nix213

There's a net.example file in /usr/share/doc/openrc*/ that might be of help to you.  

You could, for example, install net-misc/dhcp then add stuff like this to /etc/conf.d/net:

config_eth0="dhcp"

modules_eth0="dhcpd !udhcp"

dhcp_eth0="release nodns"

dns_servers_eth0="8.26.56.26 198.153.192.40"

just a few ideas   :Idea: 

----------

## curmudgeon

 *khayyam wrote:*   

> none of which are directly related to the quote above. It "blows up" resolv.conf because dhcp clients do this *unless* they are told not to request DNS (using the "nodns" switch in dhcp_${IFACE}),

 

Well-behaved dhcp clients will back up the original, and restore it when shutting down.

 *khayyam wrote:*   

> the dns servers "picked up" are provided by whatever is serving dhcp on the network, and if you want resolv.conf to be handled by multiple sources, or be static, then you need to figure out why udhcpc is started in the first place.

 

In looking at the time stamp on the altered resolv.conf, it appears that it happened several cycles (boots) ago. I have never watched for that before, and it has not happened since (and I have been paying VERY close attention to it. The log files (/var/log/messages*) contain no information about it.

 *khayyam wrote:*   

> There are security implication to any number of things, but it is by understanding the cause behind an event that allows for its mitigation. So, sure, we can state "that shouldn't happen" but that is in the realm of the obvious, and provides no clue as to the why.

 

This is why running a dhcp client on a machine that is NEVER supposed to use dhcp is so pernicious. If the machine finds a rogue dhcp server on the network, it is easy to end up with hijacked dns servers, and it doesn't take much imagination to see the types of problems that can cause.

 *khayyam wrote:*   

>  *curmudgeon wrote:*   Since my question has not been answered yet, I will repeat it - how do I block udhcpc from ever running under any circumstances? 
> 
> As I stated above with a staticly defined address it shouldn't, so you need to look for the root cause and/or provide some clue as to why it might.

 

As I stated above, it has a static address, and should always use it. I want to protect against the "known unknown" of activating a dhcp client that should never be activated under any circumstances.

I don't believe it should be that difficult (in fact, it should be trivial) to disable a program that should never be run.

 *nix213 wrote:*   

> There's a net.example file in /usr/share/doc/openrc*/ that might be of help to you. 
> 
> You could, for example, install net-misc/dhcp then add stuff like this to /etc/conf.d/net: 
> 
> config_eth0="dhcp" 
> ...

 

I absolutely do not want ANOTHER dhcp client on the machine, and I don't want to EVER use ANY dhcp client.

Would this work in isolation (or in combination with something else)?

modules_eth0="!udhcp"

I doubt it, but it will probably be the next thing I test?

----------

## Jaglover

Well, you can set immutable flag on resolv.conf, but this is hardly an elegant soulution. Why is this udhcpc present in your box? I use static conf and there is no DHCP client in the system.

----------

## Gusar

 *Jaglover wrote:*   

> Why is this udhcpc present in your box?

 

Every gentoo user has it, it's part of busybox.

----------

## Jaglover

Right you are ... it just didn't show up on PATH ...

----------

## curmudgeon

 *Jaglover wrote:*   

> Well, you can set immutable flag on resolv.conf, but this is hardly an elegant soulution.

 

Still wouldn't solve the problem of a rogue dhcp server setting a malicious router.

 *Jaglover wrote:*   

> I use static conf and there is no DHCP client in the system.

 

I use a static ip address, and I didn't think there was any dhcp client either.

In a way this reminds me of the stupid programming in browsers now. If something doesn't work, it is automatically "searched for" instead of displaying the proper messages.

What I want is that if, for any reason (such as whatever happened that one time a few boots ago), the static address assignation fails, there should be a CLEAR AND UNAMBIGUOUS ERROR, because something is obviously wrong.

----------

## krinn

then how about just

```
echo 'INSTALL_MASK="${INSTALL_MASK} /usr/share/udhcpc"' >> /etc/portage/make.conf
```

----------

## khayyam

 *krinn wrote:*   

> then how about just
> 
> ```
> echo 'INSTALL_MASK="${INSTALL_MASK} /usr/share/udhcpc"' >> /etc/portage/make.conf
> ```
> ...

 

krinn ... udhcpc is a component of /bin/busybox, busybox doesn't install anything to /usr/share/udhcpc. Anyhow, the problem isn't with udhcpc, thats meerly the effect.

best ... khay

----------

## krinn

damnit this thing is a virus  :Smile: 

maybe change /etc/udhcpcd.conf

```
interface     anonexistantname
```

----------

## The Doctor

If you just want to kill it, then why not configure busybox not to build it. Build busybox with USE="savedconfig" and edit the file. I think the file should be located at /etc/portage/savedconfig/sys-apps/busybox-1.21.0

You probably want to be careful not to rip too much out.

----------

## UberLord

 *nix213 wrote:*   

> There's a net.example file in /usr/share/doc/openrc*/ that might be of help to you.  
> 
> You could, for example, install net-misc/dhcp then add stuff like this to /etc/conf.d/net:
> 
> config_eth0="dhcp"
> ...

 

Better yet disable dhcp globally

modules="!dhcp"

may work, if that fails specify each dhcp module

modules="!dhcpcd !udhcpc"

----------

