I've been playing around with this one for a while, and it's got me stumped.
I'm running a Pi B (original model) on Ethernet rather than WiFi.
I have a Pi which when it is in the house works fine. However, when I put it out in the garden (it is connected to a Pi Cam), it has stopped being accessible on my network.
Looking at the Pi, the all the indicator lights come on, suggesting that it can at least sense that a network cable is present (do they indicate more ?).
When I first put it out there it was fine, but I brought it back indoors to do some more work on it, and when it went back out, it wasn't visible. At a casual glance the Ethernet cable looked like it might be kinked (but as it is external grade cable, I wasn't sure that it would be damaged), so I changed the network cable, and it sprang back to life, at which point I assumed that it was a damaged cable.
Last week, I had to take the power off, so I SSH'd in and shut the Pi down, then turned off the power supply. Once the power was restored, the Pi came back up, but wasn't visible on the network (Ping declared it unreachable).
I brought it back in the house, connected it up to a keyboard/mouse/TV and it appeared OK. I plugged a network cable in, and I could SSH into it. I started it up and shut it down several time, and each time it was OK. I shut it down, disconnected the keyboard/mouse/TV and it was still OK. So it should now be back in the state it is in when outside.
I took it back outside, connected it all up, and I'm back to it not being visible on the network. I tried swapping network cables, still no joy. I brought the cable from the house that I had been using moments earlier, and still no luck. I then unplugged that cable from the Pi, and into a netbook, and that can access my LAN quite happily, so I don't think it is a cabling issue. It looks as though the Pi doesn't like being outdoors (and it was a pleasant afternoon, what was wrong with being outdoors).
So what is happening ?
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
The Pi is inside a Pi case, and that is inside a metal box (part of the reason it is on Ethernet rather than WiFi), so I wouldn't have thought the light was an issue.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
I don' t think it is condensation. I took it outside today when it was warm and dry, not the sort of conditions where condensation should be a problem.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
Go and put something else on the end of the cable in the garden and confirm that works after multiple recycles, just in case you have too long a cable run for the Pi.
Was that just the Pi or Pi and cable and the box contents?
If the cable and/or box were left outside they may well have the problem.
Next time it happens, is it possible to bring the cable and all of it inside so you can then do tests immediately. By trying again, and swapping cable to make it work, then immediately changing back to original cable. Could just be the port on the switch you are using for the outside run has a funny or a combination of parts in the setup. Even try swapping ports on switch as first step.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Raspberry Pi Add-ons
Timing Diagram Font
For those web sites you hate
My first question was going to be: Is it in dayight? But I read it's in an opaque box.
My next is: When it's "dead" the lights are on but presumably as ping is "unreachable" the lights don't wink accordingly.
Already been asked DHCP or static? If DHCP are you seeing it ask for an address when you power it up? Either by using iptraf or in a log file. Does it get the address you expect it to get? The two Pi's I have here under DHCP have a habit of getting different IPs. Despite the DHCP server being configured with timeouts so long it effectively issues static IPs.
How long is the cable? Any joins? Corrosion of the RJ45 (plug or socket), not all "gold plating" is created equal. Correct type of IPC in the RJ45 for the cable (stranded/solid)?
One wire broken/poor connection can do odd things to ethernet.
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
The entire case, lead and Pi were brought inside, and then returned.
I'll bear that in mind for the future.
Thanks
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
That is what I did with a netbook, and that works just fine. To be clear, the Pi has been happily working out there, so this is something that has changed, rather than something that never worked in the first place.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
The Pi is in a black plastic Pi Case, and that is inside a light coloured alloy camera casing.
The network light is permanently on (or it is when I look at it).
The router sets a static address (rather than it being set in the Pi).
When I can get it on the network, it gets the right address.
The fixed cable from the switch in the house is probably about 12M (and that always works), that goes to a wall mounted socket. The lead from that to the camera is 1M, although I have tried longer. I've tried a netbook with a 5M lead plugged into the garage socket, and that worked OK.
Indeed, but it appear to be something intermittent.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
The Pi was left powered up overnight, but with no network cable plugged into it. This afternoon, I plugged one of the cables that I've successfully used before back in, and it there it was, back on the net.
I recovered the syslog file, and following the last reboot, the following entries were found :
May 12 16:10:10 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 4
May 12 16:10:10 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
May 12 16:10:11 southwatch ntpd[2034]: ntpd 4.2.6p5@1.2349-o Sun Apr 12
22:37:22 UTC 2015 (1)
May 12 16:10:11 southwatch ntpd[2035]: proto: precision = 1.000 usec
May 12 16:10:11 southwatch ntpd[2035]: Listen and drop on 0 v4wildcard
0.0.0.0 UDP 123
May 12 16:10:11 southwatch ntpd[2035]: Listen normally on 1 lo 127.0.0.1 UDP 123
May 12 16:10:11 southwatch ntpd[2035]: peers refreshed
May 12 16:10:11 southwatch ntpd[2035]: Listening on routing socket on fd #18 for interface updates
May 12 16:10:11 southwatch ntpd[2035]: restrict: error in address '::' on line 38. Ignoring...
May 12 16:10:11 southwatch ntpd[2035]: restrict: error in address '::1' on line 42. Ignoring...
May 12 16:10:11 southwatch ntpd[2035]: Deferring DNS for
0.debian.pool.ntp.org 1
May 12 16:10:11 southwatch ntpd[2035]: Deferring DNS for
1.debian.pool.ntp.org 1
May 12 16:10:11 southwatch ntpd[2035]: Deferring DNS for
2.debian.pool.ntp.org 1
May 12 16:10:11 southwatch ntpd[2035]: Deferring DNS for
3.debian.pool.ntp.org 1
May 12 16:10:12 southwatch ntpd[2042]: signal_no_reset: signal 17 had flags 4000000
May 12 16:10:14 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 10
May 12 16:10:14 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
May 12 16:10:14 southwatch dbus[1943]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)
May 12 16:10:14 southwatch dbus[1943]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)
May 12 16:10:14 southwatch polkitd[2185]: started daemon version 0.105 using authority implementation `local' version `0.105'
May 12 16:10:15 southwatch dbus[1943]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
May 12 16:10:15 southwatch dbus[1943]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
May 12 16:10:24 southwatch dbus[1943]: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper)
May 12 16:10:24 southwatch dbus[1943]: [system] Successfully activated service 'org.freedesktop.UDisks'
May 12 16:10:24 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 11
May 12 16:10:24 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
May 12 16:10:35 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 12
May 12 16:10:35 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
May 12 16:10:47 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 11
May 12 16:10:47 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
May 12 16:10:58 southwatch dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 10
May 12 16:10:58 southwatch ifplugd(eth0)[1567]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
May 12 16:11:08 southwatch dhclient: No DHCPOFFERS received.
May 12 16:11:08 southwatch ifplugd(eth0)[1567]: client: No DHCPOFFERS received.
May 12 16:11:08 southwatch dhclient: No working leases in persistent database - sleeping.
May 12 16:11:08 southwatch ifplugd(eth0)[1567]: client: No working leases in persistent database - sleeping.
May 12 16:11:10 southwatch ifplugd(eth0)[1567]: Program executed successfully.
May 12 16:11:54 southwatch kernel: [ 132.308033] smsc95xx 1-1.1:1.0 eth0: link down
May 12 16:11:55 southwatch ifplugd(eth0)[1567]: Link beat lost.
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: Executing '/etc/ifplugd/ifplugd.action eth0 down'.
May 12 16:12:06 southwatch dhclient: Internet Systems Consortium DHCP Client 4.2.2
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: Internet Systems Consortium DHCP Client 4.2.2
May 12 16:12:06 southwatch dhclient: Copyright 2004-2011 Internet Systems Consortium.
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: Copyright
2004-2011 Internet Systems Consortium.
May 12 16:12:06 southwatch dhclient: All rights reserved.
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: All rights reserved.
May 12 16:12:06 southwatch dhclient: For info, please visit
formatting link
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: For info, please visit
formatting link
May 12 16:12:06 southwatch dhclient:
May 12 16:12:06 southwatch dhclient: Listening on LPF/eth0/b8:27:eb:8a:a2:70
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: Listening on LPF/eth0/b8:27:eb:8a:a2:70
May 12 16:12:06 southwatch dhclient: Sending on LPF/eth0/b8:27:eb:8a:a2:70
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: Sending on LPF/eth0/b8:27:eb:8a:a2:70
May 12 16:12:06 southwatch dhclient: Sending on Socket/fallback
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: Sending on Socket/fallback
May 12 16:12:06 southwatch dhclient: DHCPRELEASE on eth0 to
192.168.1.254 port 67
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: DHCPRELEASE on eth0 to 192.168.1.254 port 67
May 12 16:12:06 southwatch dhclient: send_packet: Network is unreachable
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: send_packet: Network is unreachable
May 12 16:12:06 southwatch kernel: [ 144.157925] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
May 12 16:12:06 southwatch ifplugd(eth0)[1567]: Program executed successfully.
May 12 16:12:07 southwatch kernel: [ 144.372595] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
they stopped after the last one, which I assume was when I unplugged the cable. 192.168.1.254 is the address of the router.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
That's unusual - it's normally n.n.n.001. I've heard rumours of DHCP problems associated with use of the penultimate address in a network (the ultimate address being the broadcast one) but nothing to substantiate them.
BT Broadband uses 192.168.1.254 as the router interface IP by standard, given the quantity of BT Broadband around in the UK, I wouldn't have said it was "unusual"
I've only ever seen problems like that when a device encounters a subnet which is larger than a /24 and is given an address by DHCP where the last octet is either 254, 255 or 0 (all of which are valid addresses in a /23 or larger network) - and in those cases the device refuses the dhcp lease and persistently sends DHCP discovers.
I've never seen a Pi do it (and rather doubt it would as dhclient is pretty well behaved really!) I've mostly seen it on android phones.[1]
However, that's unlikely to be what's happening here as very few people have a subnet larger than a /24 at home!
My money is on the spring sunshine baking the box and making things too hot for the pi.
Easiest way to test that is probably to bring the pi (housing and all) inside and leave it running. If it works inside, but fails outside, it's either the cable or something environmental.
-Paul [1] My day job is running a large wireless network, 32000 devices connect per week and we operate 30 /22 subnets (1000 ish addresses per subnet) to accommodate those clients - so I've seen a lot of weird DHCP behaviour!
We ended up stopping our DHCP servers from handing out IPs that end in
254,255 or 0 - which chewed up 360 perfectly good IP addresses due to stupid client behaviour and made the lovely need pool definitions all messy!
x.x.x.001 is often the default of most routers when shipped from factory some are x.x.x.254, it does not matter what fixed address it is as long as it responds to broadcast DHCP requests and does not have overlapping DHCP address ranges with any fixed ones.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Raspberry Pi Add-ons
Timing Diagram Font
For those web sites you hate
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.