If this is your first visit, be sure to
check out the Forum Rules by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

A stab in the dark, are you running BT4 through VMware with a 36H ALFA chipset? I could not get APs created through airbase-ng to show (I could see the AP through my iPhone, but not through Windows XP) unless I booted directly (versus hosting the OS through VMware). I do not know if the issue is related to VMware, or if its just the chipset or if its both in combination.

A stab in the dark, are you running BT4 through VMware with a 36H ALFA chipset? I could not get APs created through airbase-ng to show (I could see the AP through my iPhone, but not through Windows XP) unless I booted directly (versus hosting the OS through VMware). I do not know if the issue is related to VMware, or if its just the chipset or if its both in combination.

Thanks for the reply,
No I am running BT4 Pre Final off a dual boot install on a Samsung NC110.

Probably should have mentioned that as well, I am running as root throughout.

The system can run without the PID file, but it's better not to make it.

DHCPD will drop privileges when it executes, this is standard security technique 101 for network programs that require root, so we need to ensure it can write to an otherwise restricted directory.

Someone (might have been me!) suggested you could just cheat and

Code:

touch /var/run/dhcpd.pid && chmod 777 /var/run/dhcpd.pid

But this is a not-good way of doing it (mostly because I can edit the file, change it to contain "1" and then wait for you to restart your dhcpd server - resulting in a kill of the "init" process, and partly because it's just poor form).

You can, however, create a directory within /var/run, and grant it access to the dhcpd daemon. Get the username it drops priv's too out of /etc/passwd (just grep for dhcp):

Code:

mkdir -p /var/run/dhcpd && chown _dhcpd /var/run/dhcpd

This gives dhcpd a place to write its PID file when it boots up.

The second part of the two step process is to give DHCPd a new command line flag to tell it where to save the PID file - across the three systems I looked at (none of them bt4 though as that is currently proxying connections through my company firewall - don't ask), the switch was the same:

Code:

dhcpd -cf /etc/dhcpd3/dhcpd.conf -pf /var/run/dhcpd/dhcpd.pid at0

Hopefully that is what you are looking for - it should both remove the Error at the end, and gives you a more "correctly secure" system than the other.

Let us know.

Still not underestimating the power...

There is no such thing as bad information - There is truth in the data, so you sift it all, even the crap stuff.