# [SOLVED] how to get dhcpd and all it's deps onto a pi

## Lovot

i have a raspberry pi, and i need to get it connected to the internet, except the tools that come with the stage 3 tarball don't include a functional dhcp daemon, which i absolutely require for connecting to my router. A manual connection using ip has already been tried and it failed. Is there a way to load the dhcpcd sources and all it's dependencies directly onto the SD card via a computer with a functional internet connection, and then compile/install them using portage? 

alternatively, an explanation of why these commands seem to work, but do not result in an actual internet connection:

```

ip addr add 192.168.3.111/24 dev eth0

ip route add default via 192.168.3.1

```

192.168.3.111/24 is the desired IP, it's available

192.168.3.1 is the address of the router

the cable works with other devices.Last edited by Lovot on Sun Feb 07, 2016 4:12 am; edited 1 time in total

----------

## Ant P.

 *Quote:*   

> except the tools that come with the stage 3 tarball don't include a functional dhcp daemon, which i absolutely require for connecting to my router.

 

Busybox (in @system) contains a dhcp daemon and client by default. Is there any reason you can't use that?

----------

## Lovot

 *Ant P. wrote:*   

>  *Quote:*   except the tools that come with the stage 3 tarball don't include a functional dhcp daemon, which i absolutely require for connecting to my router. 
> 
> Busybox (in @system) contains a dhcp daemon and client by default. Is there any reason you can't use that?

 

Those were broken for whatever reason, i followed the steps listed here https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide#Enabling_networking_on_boot to try and get an internet connection, and that failed, 

```
running udhcpc

start-stop-daemon: failed to start '/bin/busybox'
```

so something appears to be broken there too, and the forum post I saw on the matter ended in OP giving up because they did not need those tools.

----------

## khayyam

 *Lovot wrote:*   

> alternatively, an explanation of why these commands seem to work, but do not result in an actual internet connection:
> 
> ```
> ip addr add 192.168.3.111/24 dev eth0
> 
> ...

 

Lovot ... firstly, do you in fact have an 'eth0'? If udev is in use then this may have been renamed. Look at the output of 'ifconfig -a' to confirm ... if so then please try the following (or substitute the interface name):

```
# ip link set dev eth0 up

# ip addr add 192.168.3.111/24 brd + dev eth0

# ip route add default via 192.168.3.1

# echo "nameserver 192.168.3.1" > /etc/resolv.conf

# ping -c 1 204.187.15.12

# ping -c 1 forums.gentoo.org
```

... if this works then you should be able to do the same using netifrc, eg:

```
config_eth0="192.168.3.111/24"

routes_eth0="default via 192.168.3.1"

dns_servers_eth0="192.168.3.1"
```

... you would then create a sym-link from net.lo to net.eth0 and add net.eth0 to the default runlevel

```
# ln -sf /etc/init.d/net.lo /etc/init.d/net.eth0

# rc-update add net.eth0 default

# /etc/init.d/net.eth0 start
```

No dhcp should be needed, unless your network is such that 192.168.3.111 may be in use by some other host.

If you must use dhcp to assign addresses then udhcpc (busybox) should work, though from the above errror I can't tell if this is due to udhpc not being enabled in busybox, or the interface passed isn't available (again, as udev is in use and has renamed it). You could check if USE="savedconfig" is enabled on sys-apps/busybox and if CONFIG_UDHCPC=y is set in /etc/portage/savedconfig/sys-apps/busybox-{version}.

HTH & best ... khay

----------

## Lovot

Yes, it's named eth0, one of the first things I checked when I couldn't connect to the internet.

I tried what you suggested, and got the same exact results as before, so I tried running udhcpc directly to confirm it was present and functional:

```
# busybox udhcpc

udhcpc (v1.23.1) started

Setting IP address 0.0.0.0 on eth0

Sending discover...
```

the "Sending discover..." message repeats endlessly until the process is killed. udhcpc is present, and possibly functional, I do not know how to use it, there is no man page i can find, and all the gentoo stuff on it involves the OP trying to get rid of it, if you could describe how to use it manually, that could work.

----------

## khayyam

 *Lovot wrote:*   

> Yes, it's named eth0, one of the first things I checked when I couldn't connect to the internet. I tried what you suggested, and got the same exact results as before [...]

 

Lovet ... it would help if we could see that, what is the output of 'ip addr show dev eth0' and 'ping -c 1 192.168.3.1'?

 *Lovot wrote:*   

> [...]the "Sending discover..." message repeats endlessly until the process is killed. udhcpc is present, and possibly functional, I do not know how to use it, there is no man page i can find, and all the gentoo stuff on it involves the OP trying to get rid of it, if you could describe how to use it manually, that could work.

 

I don't think udhcpc is going to help as the lack of "discovery" suggests there is nothing passing accross the link (for some reason or other) ... anyhow, parameters for udhcpc can be found here. What are you seeing in 'demsg' relating to the interface? Also you should check/replace the cable ...

best ... khay

----------

## krinn

 *khayyam wrote:*   

> Also you should check/replace the cable ..

 

hihi, and check where it is connect to, i've seen people connecting it to the wan port of their router  :Smile: 

----------

## Lovot

Here is the output you requested

```
# ifconfig -a

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

      inet 192.168.3.111 netmask 255.255.255.0 broadcast 192.168.3.255

      ether b8:27:eb:a2:85:63 txqueuelen 1000 (Ethernet)

      RX packets 115 bytes 3976 (3.8 KiB)

      RX errors 7606 dropped 3803 overruns 0 frame 7606

      TX packets 51 bytes 16106 (15.7 KiB)

      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

      inet 127.0.0.1 netmask 255.0.0.0 broadcast 192.168.3.255

      loop txqueuelen 0 (Local Loopback)

      RX packets 56 bytes 3976 (3.8 KiB)

      RX errors 0 dropped 0 overruns 0 frame 0

      TX packets 56 bytes 3976 (3.8 KiB)

      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

# ping -c 1 204.187.15.12

PING 204.187.15.12 (204.187.15.12) 56(84) bytes of data

From 192.168.3.111: icmp sequence=1 Destination Host Unreachable

--- 204.187.15.12 ping statistics ---

1 packets transmitted, 0 recieved, +1 errors, 100% packet loss, time 0ms

# ping -c 1 forums.gentoo.org

ping: unknown host forums.gentoo.org
```

The cable is the same one I am making forum posts from, if it were plugged in incorrectly, or damaged I would be unable to make forum posts, sort of inconvenient, so I will be getting another router so both can connect at the same time.

----------

## NeddySeagoon

Lovot,

That looks good.

What does route show?

To ping by name you also need /etc/resolv.config to be populated. 

Look in dmesg for errors related to the network interface.

The Pi network interface is attached via USB2 an has a problem with dropping packets. 

There is an edit to /etc/sysctl.conf to fix that.

----------

## Lovot

 *NeddySeagoon wrote:*   

> Lovot,
> 
> That looks good.
> 
> What does route show?
> ...

 

```
# ip route get 8.8.8.8

8.8.8.8 via 192.168.3.1 dev eth0 src 192.168.3.111
```

/etc/resolv.conf has "nameserver 192.168.3.1", and nothing else

dmesg had no errors related to eth0, or the built in network device, it does have some messages that indicate that the built in ethernet device has been found, and initialized, as well as some messages about the link going active, presumably when I tried setting it up manually. Everything should be working, but the lack of connectivity persists. I am beginning to suspect a hardware problem, but I have no way to check that right now.

----------

## freke

I had a problem with my first Pi suddenly not being able to start networking - turned out it was the power-supply that after a year of service didn't quite manage to deliver enough juice...

Dunno if that could be a factor here?

----------

## Lovot

 *freke wrote:*   

> I had a problem with my first Pi suddenly not being able to start networking - turned out it was the power-supply that after a year of service didn't quite manage to deliver enough juice...
> 
> Dunno if that could be a factor here?

 

I thought of that, the power supply i was originally using when I started this thread was a 1 amp power supply, and the pi would boot loop when anything that required power was plugged, including the idiot lights on the Ethernet port, after it booted I could plug things in. I upgraded the power supply to one that was rated for 4 amps, it fixed the boot loops with other things plugged in, but not the networking issues.

----------

## Lovot

OK, this is getting weird, from the looks of things the cable may only work with the machine I am making forum posts from, like it's isometric, will have to check this at the soonest opportunity with known working devices that are not my main.

----------

## Lovot

I think the cable is too long for embedded devices to use it, it will connect to all of my PCs, but not the router i got, or the pi, even after changing out the plugs. I may have to put the second router in the middle to act as a repeater, even though the cable is <100' long, while the listed range is 100m, so <1/3 of the max range. The second router connected to the first router when connected with a shorter cable, so the repeater idea is most likely the solution.

----------

## Syl20

That's strange. Is your cable armored ?

----------

## NeddySeagoon

Lovot,

Cat5 cable or better?

----------

## Lovot

I took 10 feet of slack out of the cable, which was enough that the router accepted it, now everything works. 

For those who were asking, the cable is unshielded cat5e suitable for gigabit transmissions, interference did not seem to be an issue. The cable consistently worked flawlessly with any PC class device (desktops, laptops, etc), and consistently did not work with embedded devices. The plugs were good, I replaced them to make sure, with the exact same result. Apparently many embedded devices do not have good enough network hardware to use anywhere near the listed range of rj45 cat5e cable, even if the embedded device is explicitly designed for networking.

----------

