Wrong IP address on Pi Zero

[RobH]

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.

[mm0fmf]

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.

[mm0fmf]

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

[Martin Gregorie]

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

[Chris Elvidge]

On 05/05/2018 15:47, RobH wrote:

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

[RobH]

On 05/05/18 16:13, mm0fmf wrote:
> On 05/05/2018 15:56, mm0fmf wrote:
>> On 05/05/2018 15:47, RobH wrote:
>>> 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.
>>
>> 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 ev169.254en just 169.254 to read more

>> about why you have this IP address.
>>
>>
> If only I could type or proof-read... link-local IPV4 address.

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.

[A. Dumas]

RobH <r...@despammer.com> wrote:
> 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.

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.

[mm0fmf]

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.

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

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?

[Andreas Neumann]

Martin Gregorie wrote:

> 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

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

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

[nev young]

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

[The Natural Philosopher]

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

[The Natural Philosopher]

On 05/05/18 19:39, nev young wrote:
> Here I just log into the router and assign a permanent IP to the Pi zero
> W's MAC address.

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)

[druck]

On 05/05/2018 17:01, Martin Gregorie wrote:

> 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

[snip]

> "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.

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

---druck

[Martin Gregorie]

On Sat, 05 May 2018 20:32:00 +0200, Andreas Neumann wrote:

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

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

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

...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 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).

[Andreas Neumann]

Martin Gregorie wrote:

> On Sat, 05 May 2018 20:32:00 +0200, Andreas Neumann wrote:
>
>> The hosts file has nothing to do with setting up networking.
>>
> 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?

No.

> 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.

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

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

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

[mm0fmf]

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.

[Martin Gregorie]

On Sat, 05 May 2018 21:54:53 +0100, mm0fmf wrote:

> 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.
>

... 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.

[druck]

On 05/05/2018 21:08, Martin Gregorie wrote:
> 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).

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

---druck

[John Rickman]

In message <pclakn$hr$1...@news.albasani.net>

Martin Gregorie <mar...@mydomain.invalid> wrote:

> 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.

This happened on my 3B+ when I first started it. The cause in this case
was that the ethernet cable was not plugged in properly.

My fault as the cable I was using had previously been plugged into a
television and I had cut off the locking tag to make it possible to get
get the cable out without removing the television from the wall.

John

--
John Rickman

[The Natural Philosopher]

Why not? Unless he wants to talk to Sprint it makes no odds..
Or maybe he actually owns that range,


Anyway, one assumes it was an example

--
A lie can travel halfway around the world while the truth is putting on
its shoes.

[druck]

On 06/05/2018 10:15, The Natural Philosopher wrote:
> On 06/05/18 09:27, druck wrote:
>> On 05/05/2018 21:08, Martin Gregorie wrote:
>>> 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).
>>
>> Why are you using a non-private (Sprint) IP range on your LAN?
>>
>> ---druck
> Why not? Unless he wants to talk to Sprint it makes no odds..
> Or maybe he actually owns that range,

He doesn't, and should not be using it. If you use a non-private IP
range on a local network, you risk all traffic being exposed externally.

> Anyway, one assumes it was an example

It's what is called a bad example, and unhelpful to anyone interested in
setting up a working network.

---druck

[The Natural Philosopher]

On 06/05/18 10:37, druck wrote:
> On 06/05/2018 10:15, The Natural Philosopher wrote:
>> On 06/05/18 09:27, druck wrote:
>>> On 05/05/2018 21:08, Martin Gregorie wrote:
>>>> 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).
>>>
>>> Why are you using a non-private (Sprint) IP range on your LAN?
>>>
>>> ---druck
>> Why not? Unless he wants to talk to Sprint it makes no odds..
>> Or maybe he actually owns that range,
>
> He doesn't, and should not be using it. If you use a non-private IP
> range on a local network, you risk all traffic being exposed externally.

Go away and learn enough about routing on the internet to realise how
foolish a remark that was.

>
>> Anyway, one assumes it was an example
>
> It's what is called a bad example, and unhelpful to anyone interested in
> setting up a working network.
>
> ---druck

--
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah
puts mah heel on um jess the same if'n I catches him around mah chillun".

[Martin Gregorie]

Another typo - ignore it, but my comment about 255.255.255.n vs
255.255.255.ip convention in that post is as I said.

[RobH]

On 05/05/18 15:47, RobH wrote:

Ok an update on the problem I was having.

From one of the replies I went to find the linux equivalent of ipconfig
/release etc for windows. I found the answer and was about to try it on
the Pi Zero when my network went down.

Here I should say that I am or was using a VM Hub 3 in modem mode with a
TP Link Archer AC 1750 router. I had this setup for about 2 months and
everyhing was working, but yesterday the problems began after I rebooted
the router in an attempt to get a DHCP IP address of 192.160.0. something.

My IP cctv cameras were not showing anything on another monitor, but a
switch showed that they were working,from the blinking leds on a switch.
Then there was no wireless connection to my android equipment.

So , in conclusion, I disconnected the TP link router and set the vm Hub
back to router mode, and after a short while , my network came back,
cameras were displaying pictures on the monitor and wireless was back.

So for now, I am going to stick with this setup, and I have no ideas as
to why the TP Link router developed the said problems.

[The Natural Philosopher]

On 06/05/18 15:57, RobH wrote:
> I have no ideas as to why the TP Link router developed the said problems.

I have never found they needed a reason.


--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

[druck]

On 06/05/2018 11:28, The Natural Philosopher wrote:
> On 06/05/18 10:37, druck wrote:
>> On 06/05/2018 10:15, The Natural Philosopher wrote:
>>> On 06/05/18 09:27, druck wrote:
>>>> On 05/05/2018 21:08, Martin Gregorie wrote:
>>>>> 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).
>>>>
>>>> Why are you using a non-private (Sprint) IP range on your LAN?
>>>>
>>>> ---druck
>>> Why not? Unless he wants to talk to Sprint it makes no odds..
>>> Or maybe he actually owns that range,
>>
>> He doesn't, and should not be using it. If you use a non-private IP
>> range on a local network, you risk all traffic being exposed externally.
>
> Go away and learn enough about routing on the internet to realise how
> foolish a remark that was.

Words fail me at the stupidity of your comment.

---druck

[The Natural Philosopher]

Well in fact which of us spent years of his life building the Internet?


>
> ---druck
>


--
Climate Change: Socialism wearing a lab coat.

[Nomen Nescio]

The Natural Philosopher <t...@invalid.invalid> wrote:

> >>> He doesn't, and should not be using it. If you use a non-private IP
> >>> range on a local network, you risk all traffic being exposed externally.

Only if the ISP doesn't implement BCP38 (a running gag) and unless the
Internet routes those addresses back to your local network, the connection
would be write-only.

> Well in fact which of us spent years of his life building the Internet?

Al Gore and me.

[The Natural Philosopher]

On 08/05/18 02:12, Nomen Nescio wrote:
> The Natural Philosopher <t...@invalid.invalid> wrote:
>
>>>>> He doesn't, and should not be using it. If you use a non-private IP
>>>>> range on a local network, you risk all traffic being exposed externally.
>
> Only if the ISP doesn't implement BCP38 (a running gag) and unless the
> Internet routes those addresses back to your local network, the connection
> would be write-only.

Precisely.

But that is only half the story.


BGP would route any accesses to those IP addresses to Sprint which is
who owns them (allegedly) .

It would take insider knowledg to even know that those addresses were
being used on a private LAN and had been connected via a router that
doesn't do NAS.

And indeed there would be liitle point in HAVING them on a private LAN
and connecting them to the internet, without NAT since they would not
work anyway ...

>
>> Well in fact which of us spent years of his life building the Internet?
>
> Al Gore and me.
>

:-)


--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

[John Rickman]

In message <pcos0v$7sf$1...@dont-email.me>

The Natural Philosopher <t...@invalid.invalid> wrote:

>>> Go away and learn enough about routing on the internet to realise how
>>> foolish a remark that was.
>>
>> Words fail me at the stupidity of your comment.

> Well in fact which of us spent years of his life building the Internet?

Gentlemen - please. Tis is not appropriate here.



--
John Rickman