Wrong IP address on Pi Zero

I have finished setting up a pi zero w for a project, and now need to access it by ssh. I couldn't and after connecting a monitor and keyboard, doing 'ifconfig' returns eth0: inet 169.254.156.44 netmask 255.255.0.0 broadcast 169.254.255.255.

Is there is anywhere the IP address can be changed to 192.168.0.any other IP number.

I have rebooted my router and the Pi Zero several times, but no change.

Reply to
RobH
Loading thread data ...

You have much bigger problems if your IP starts 169.254.x.x.

Is your Pi meant to connect to a Wifi router and be allocated an IP address by DHCP? Because it isn't happening.

Perhaps you can detail how your Pi will be using the Wifi connection in your project and people can then give you the relevant help to configure it.

Also, Google link-local IPV3 address or even just 169.254 to read more about why you have this IP address.

Reply to
mm0fmf

If only I could type or proof-read... link-local IPV4 address.

Reply to
mm0fmf

If you're happy to give the pi zero a static address, do the following:

1)Add a line something like:

192.168.0.n pi0name pi0name.localdomain

to /etc/hosts on the Pi zero - where 'n' is an unused IP in the 168.192.0 subnet and 'pi0name' is whatever unused host name you want to give it.

2)Now make sure that /etc/hosts contains a single line containing the host name you've given

3)Make sure that /etc/resolv.conf has a "nameserver" line that contains the correct IP of your favourite nameserver (in the UK that would typically be one provided by your ISP).

4)Then reboot the Pi zero.

"ssh 168.192.0.n" should now connect to the Pi zero provided that your wifi router is configured to support the 168.192.0 subnet, and it should be able to connect to external hosts.

The rest of this post assumes that, like me, you are running Linux on your other computers - if you're not the following advice will need adjustment to work under other operating systems but, once adjusted to suit them, should also work.

- If you want to be able to use scp, ssh ftp, etc to connect to other hosts from the Pi zero (you probably will, particularly if you're planning to run a version control system for your pi-zero project, just add additional "168.192.0.ip hostname" lines to the Pi zero's copy of /etc/hosts for the other local machines you need to contact from it and add the "168.192.0.n pi0name" line to /etc/hosts on the machines you want to contact the Pi zero from.

Its good practice to maintain a master copy of /etc/hosts that contains the IP and name of every local machine and simply replicate it onto every host on your Lan - this lets all your machines talk to each other.

I used to work that way. By and large it 'just worked'. Now I run a local DNS on my house server. This is no better or worse than distributing /etc/hosts files except that when you have more than 3-4 hosts on the LAN it starts to make sense to use a local DNS as a central reference point.

Your router may also have a configurable DHCP system in it that can be used to assign names and specific IPS to computers, but you'll need to read its manual to find out whether it can do this and, if so, how to set it up. While you're doing that, you may want to work out how to lock the router down to keep intruders out because, although your other machines may have firewalls, to Pi zero probably doesn't and you really don't want to find out that its just become a member of some blackhat's botnet.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

I don't have a PiZeroW to check this, but:

Is eth0 the wlan interface? If wlan0 is the wlan interface, change eth0 to wlan0 in interfaces stanza below. Is your router a dhcp server on wifi using PSK?

/etc/network/interfaces should contain a stanza like:

auto eth0 iface eth0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

and /etc/wpa_supplicant/wpa_supplicant.conf should contain

ctrl_interface=/var/run/wpa_supplicant

network={ ssid="YourNetworkName" key_mgmt=WPA-PSK psk="YourNetworkPassword" }

When done, run 'ifup eth0' (no quotes) or reboot.

HIH

--

Chris Elvidge, England
Reply to
Chris Elvidge

Sorry, I should have been more clearer. The Pi Zero w is connected by a ethernet cable via a usb / ethernet adapter.

I have power cycled the router as well shutting the Pi Zero down and starting again as it were, but the problem still remains.

Reply to
RobH

The usb-ethernet adapter is broken or unsupported by Raspbian, or the ethernet cable is kaputt, or the connectors are, or the router is, or the router has disabled the ethernet port.

Reply to
A. Dumas

Yes you should have. :-) You still haven't said if you expect the Pi to get its IP address by DHCP or not. Let's assume you do.

OK, well that's the same setup I have on a PiW here. USB Ethernet adaptor and the Wifi acts as an access point.

I'm running Debian 8.0 and kernel "Linux rpiw 4.9.35+ #1014 Fri Jun 30

14:34:49 BST 2017 armv6l GNU/Linux" on mine. It worked with 2 USB Ethernet adapters out of the box, no need to add drivers or anything.

As you can access the Pi, check the dmesg log that that the USB adapter was found. My log shows:

[ 1.358884] usb 1-1: new full-speed USB device number 2 using dwc_otg [ 1.590598] usb 1-1: New USB device found, idVendor=0fe6, idProduct=9700 [ 1.590623] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 1.590635] usb 1-1: Product: USB 2.0 10/100M Ethernet Adaptor [ 8.603245] dm9601 1-1:1.0 eth0: register 'dm9601' at usb-20980000.usb-1, Davicom DM96xx USB 10/100 Ethernet, xx:xx:.....

A bit later in the log the ethernet connects:

[ 17.828327] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 17.916560] dm9601 1-1:1.0 eth0: kevent 4 may have been dropped [ 17.945909] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 18.041115] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF

I had to do nothing else as my /etc/network/interfaces already contained:

allow-hotplug eth0 iface eth0 inet dhcp

So check the log that the USB adapter is found and initialised. If it is then you should check the Ethernet cable and the router is setup to perform DHCP.

There is normally a big giveaway with these USB Ethernet devices, they have LEDS that come on when the device gets enumerated. I have several, the good ones have activity LEDS and link status LEDS (full / half duplex / 10 / 100). This DM9601 is a dog of device as some UARTs are faster than it is. It has a single LED that lights when enumerated and the driver loads. The LED flashes on any activity.

Maybe you should say now whether you have tinkered with any of the network files?

Reply to
mm0fmf

The hosts file has nothing to do with setting up networking.

It only matches host names to IP adresses in a static environment.

Reply to
Andreas Neumann

Here I just log into the router and assign a permanent IP to the Pi zero W's MAC address.

Taken from my router's set up pages I have:

the DCHP client list (part of) shows

picam3 B8:27:EB:FA:41:BA 192.168.1.113 Permanent picam6 B8:27:EB:AC:B4:E4 192.168.1.116 Permanent picam1 B8:27:EB:48:55:0E 192.168.1.111 Permanent picam2 B8:27:EB:DA:86:40 192.168.1.112 Permanent

The DHCP Address Reservation (part of) shows

74:DA:38:54:3F:0E 192.168.1.114 Default Enabled Edit 74:DA:38:54:3E:86 192.168.1.115 Default Enabled Edit b8:27:eb:23:fe:5a 192.168.1.119 Default Enabled Edit B8:27:EB:DA:86:40 192.168.1.112 Default Enabled Edit B8:27:EB:FA:41:BA 192.168.1.113 Default Enabled Edit and the Wireless MAC Filtering settings (part of) shows

B8:27:EB:DA:86:40 Disabled picam2 Edit B8:27:EB:FA:41:BA Disabled picam1 Edit B8:27:EB:70:83:2C Disabled picam7 Edit B8:27:EB:AC:B4:E4 Disabled picam6 Edit B8:27:EB:47:67:DF Disabled picam8 Edit

All easily set up via the router's web interface at 192.168.1.1 (yours may be different; try 192.168.1.254)

It all really depends on what your router's capabilities are.

--
nev 
getting the wrong stick end since 1953
Reply to
nev young

The it is not set up for DHCP

I susopect that normal debian behaviour is contrelloed by the file

/etc/network/interfaces This is from my server on a static IP address:

auto lo iface lo inet loopback iface etho inet static address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.254 broadcast 192.168.0.255 network 192.168.0.0 dns-nameservers 127.0.1.1 192.168.0.254

--
"Socialist governments traditionally do make a financial mess. They  
always run out of other people's money. It's quite a characteristic of them" 

Margaret Thatcher
Reply to
The Natural Philosopher

Which is useless if the Pi is not using DHCP.

The things to cheack are what interfaces have been recognised. ifconfig

-a should show them. There are other methods

Then to ensure they are correctly initialised by what is in /etc/networks/interfaces.

--
If I had all the money I've spent on drink... 
..I'd spend it on drink. 

Sir Henry (at Rawlinson's End)
Reply to
The Natural Philosopher

[snip]

Bit of lexdysia there, you mean 192.168.0.n throughout.

---druck

Reply to
druck

It does if you're not using DNS on your LAN - how else is the system making a connection supposed to translate the hostname into an IP?

Also, the combination of the name on hostname and a matching line in hosts was the traditional way to tell a system what its IP is.

Another way is to edit /etc/network/interfaces: something like:

auto lo iface lo inet loopback iface eth0 inet static address 192.168.7.101 netmask 255.255.255.0 gateway 192.168.7.1

makes the use of static addressing for eth0 explicit and, as part of its standard operation, overwrites /etc/hosts

...static addressing is exactly what said I was describing and did describe.

Nothing else is needed for a small LAN and, while most routers can assign anonymous IPs via DHCP, many fewer allow hostnames to be associated with DHCP-assigned addresses and assigned to specific MACs - something thats needed if your local machines are to talk to each other.

If your router won't do that but your hosts need to communicate, your choices are:

a) use static assignment via /etc/hosts

b) set up your own DHCP server on a suitable PC or RPi

c) set up a local DNS on a suitable PC or RPi

and option (a) is a lot easier to install and configure than (b) or (c).

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

No sir! I intentionally used 192.168.0.n when I was referring to the new RPi but 168.192.0.ip when referring to IPs of other hosts on the LAN. A quick review sees no typos (in the IPs anyway).

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

No.

No. Where there is no configured network, there is no IP address, no matter what your hosts file says.

No. This is the only way to set up and configure networking (unless you are dealing with sick concepts like systemd).

Reply to
Andreas Neumann

The OP's question was why the IP address was unexpectedly 169.254.x.x and that is a big indication that there is no static IP set and DHCP is not giving the Pi an IP addr.

Whilst the OP may have asked about how to get an IP addr in the range he expected, the fact he doesn't grok what a 169.254 address signifies is the question that needs answering. viz. why isn't DHCP working. The most likely reason is because networking is actually not working.

Get networking working then you can fanny about with hostnames but again, the original question is framed in such a way that the OP is expecting to access the Pi by an addr not a name.

Reply to
mm0fmf

... but wants to define his own IP setting. Sure.

IIRC out of the box an RPI expects to get an IP from the nearest DHCP server, but obviously that isn't happening, but to me the fact that its getting a 169.254.0.0 address implies that the network stack on his RPi is working but that there's isn't a DHCP server running in the local network segment. Accordingly, I think he has these choices, in roughly ascending order of difficulty:

- configure and activate the DHCP server in his router

- configure his RPi to use static address assignment

- install, configure and activate a DHCP server on one of his PCs

- set up a local DNS for his LAN

He has to do something: either tell us enough about his router, LAN and the hosts on it for more specific help to be provided or try one of the above.

Since he wants to establish connections between the RPi and another box on his LAN, he can't simply switch on a DHCP server and let it do its thing with minimal configuration (tell it which subnet to use and what range of IPs its allowed to hand out) isn't really much use since (at least in theory) the RPi may get a different IP each time it boots, he at least needs to configure DHCP to associate a specific IP with the RPi, but going the extra metre and giving it a name as well would seen sensible.

The problem with the default DHCP setup in most cheap COTS routers is that, while they are great for simply plugging in several PCs that will all talk to the 'net and not to each other, but that a non-zero amount of work is needed configuring DHCP if you want the PCs/RPis on the LAN to talk to each other.

I suspect this is what the OP is running into, but can't know for sure until he comes back with more information. Until then I'm out of this thread.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

On Sat, 5 May 2018 22:19:03 +0000 (UTC), Martin Gregorie declaimed the following:

Server could be active -- but configured to only serve a small range of IPs, and all of that range are currently assigned and active.

Mine is currently rigged to only serve 20 IPs (192.168.2.100 -

192.168.2.119) {of which, 6 are currently in use, but I have three Nooks that are "off-line", an RPi3 off-line [which may get different IPs for WiFi and wired] and a few BeagleBone Blacks -- the Rpi3 and BBB are in the "reserved" list taking up three address of the 20).
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Why are you using a non-private (Sprint) IP range on your LAN?

---druck

Reply to
druck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.