Odd Network Issue - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Odd Network Issue
On Thu, 21 May 2015 18:31:25 +0100, Chris Bartram wrote:

Quoted text here. Click to load it

PoE needs a DC path. We have a partially Ali telephone line, Ali is
very prone to breaking in the IDC jelly beans. When that happens the
insulation/jelly holds the wire in place so the AC ADSL signal can
just about get across but there is no DC path so the phone is dead.
  
Quoted text here. Click to load it

Time Domain Multiplexer? Time Domain Reflectometer (TDR) surely?

--  
Cheers
Dave.




Re: Odd Network Issue
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Quoted text here. Click to load it

So that was yesterday, today is another day.

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  
https://www.isc.org/software/dhcp/

May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: For info, please  
visit https://www.isc.org/software/dhcp/

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 dhclient: send_packet: please consult README  
file regarding broadcast address.

May 12 16:12:06 southwatch ifplugd(eth0)[1567]: client: send_packet:  
please consult README file regarding broadcast address.

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
On Wed, 13 May 2015 23:02:18 +0100

Quoted text here. Click to load it
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.


Re: Odd Network Issue

Quoted text here. Click to load it


I thought you said you were using a static address. In that case, why  
all the DHCP traffic.

Are you instead using a DHCP reservation to issue a constant address?


--  
Alan Adams, from Northamptonshire
snipped-for-privacy@adamshome.org.uk
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Quoted text here. Click to load it

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"

Quoted text here. Click to load it

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!
--  
http://paulseward.com

Re: Odd Network Issue
Quoted text here. Click to load it

Interesting... I could understand that not-so-good code would refuse the
.0 or .255 address, but what would be wrong with .254 I don't see yet.

Maybe some clients are surprised when they get a lease for the address
that they have cached as their previous DHCP server.  So when you try
to issue 192.168.1.254 to a client that previously was connected to one
of those BT routers with that address, it might think that it gets
issued an address that is already in use.

When that is the problem, it could in fact happen with *any* address.
192.168.1.1 is also quite usual for a router/DHCP server address.

Re: Odd Network Issue
says...
Quoted text here. Click to load it

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          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
On Thu, 14 May 2015 12:39:40 +0100

Quoted text here. Click to load it
Theoretically it doesn't matter because everything behaves as set out
in the relevant RFCs, but edge cases can exhibit unexpected behaviour.


Re: Odd Network Issue

Quoted text here. Click to load it

.254 is what BT Home Hubs use - I haven't had a problem with mine.

--  
Mike Fleming

Re: Odd Network Issue
On 23/05/15 21:11, Mike Fleming wrote:
Quoted text here. Click to load it

.254 is neither unusual nor has it any problems.

Nor incidentally, is the Ethernet chip in a Pi in anyway different from  
the Ethernet chip in anything else in terms of 'driving a long cable'.



--  
New Soialism consists essentially in veing seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Quoted text here. Click to load it

The Ethernet chip is a fairly standard usb-to-ethernet one. The
PHY (the line drivers) are different. And they are somewhat
power-constrained.

I haven't got firm experience with the pi on this, but on similar
low-end ethernet I have experienced that you have to take the
100 meters limit (less 6 for every connection) quite seriously,  
whereas laptops/desktops etc easily connect just fine on links
that are up to twice as long.

3com even have 10mb eternet drivers for 600 meter cat5 runs of cable,  
and I have used them to build networks some times.

-- mrr



Re: Odd Network Issue
says...
Quoted text here. Click to load it
......  
Quoted text here. Click to load it
......

So you are using the Router to assign the IP address (fixed by router  
configuration) from the MAC address or name of the Pi. So the Pi is
still doing DHCP.

Having recently had a funny on site where DHCP stopped some mornings
I set up on that router a scheduled auto reboot of the router an hour  
before anyone comes in, in the morning. Probably also needs a firmware  
upgrade as in THIS case I think it has a lease time calculation issue.
So far the scheduled reboot clears out that routers DHCP table issues.

Just find another fixed IP address and configure the Pi for that.

--  
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue

Quoted text here. Click to load it




I have had a router which used very short lease times. When the lease  
expired, instead of re-issuing the same address (as it should), it  
issued the next highest unused address. Similarly when clients  
restarted they got new addresses. Restarting the router caused it to  
start issuing from the start of the DHCP range.


--  
Alan Adams, from Northamptonshire
snipped-for-privacy@adamshome.org.uk
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Quoted text here. Click to load it

Rather than write similar replies to multiple posts (and thanks for the  
replies), one which hopefully answers the questions raised (as far as I  
can).

It seems that my interpretation of DHCP is different to everyone else's.  
The address was originally dynamically assigned by the router, and I  
then told the router to always use the same IP address for the given MAC  
address.  According to the router the lease time is infinite, fully  
dynamic appears to be a day..


Regarding the temperature thing, Tuesday was a (for the time of year) a  
warm day, as was Wednesday, but neither day could be described as hot  
(local weather stations were giving 16-18 degrees centigrade).  On  
Tuesday I brought it into the house (ambient temperature upper teens),  
and it worked fine.  It then went back outdoors, and was installed and  
connected up within 10 minutes or so, I wouldn't have thought that the  
temperature would have risen so much in that 10 minutes or so that it  
was out of operating range.  It then stayed in position until I went out  
to it again yesterday PM, when plugging a cable in, it came back to  
life.  It had been sat in the sun for about 3 hours at that point.  If  
it was a temperature problem, why was it a problem on Tuesday, but not  
yesterday.

It is difficult to run it on the same kit in the house as it runs on  
outside.  I could plug it into the same switch, but that would be a much  
shorter cable run, and I use a different power supply (otherwise I'd  
need to remove the garage guttering)  I doubt the power supply is the  
issue, but who knows.

To repeat, I've plugged the Pi into a network cable, and not been able  
to get through to it, unplug the cable from the Pi, and into a netbook,  
and we are in business.


Adrian
--  
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Power supplies can cause all manner of problems. Try another one.

Re: Odd Network Issue

Quoted text here. Click to load it

Why do you doubt it? The only difference between the working laptop
and the intermittent Pi is the power supply. In addition Pis,
particularly early ones, are notorious for being sensitive to their
power supply.
Quoted text here. Click to load it

Re: Odd Network Issue
Quoted text here. Click to load it

I'm not arguing about the possibility of the power supply being a  
problem, but there is rather more to it than that.  The netbook is  
completely different hardware, running a different OS, so I think that  
all that proves is that the connection from the garage is good.

Whilst it is an original model B Pi, it was bought towards the end of  
the run (but before the B+ was announced).  How long it had been sitting  
on a shelf I can't say (is there anyway to tell ?).

Adrian
--  
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
We've slightly trimmed the long signature. Click to see the full one.
Re: Odd Network Issue
Quoted text here. Click to load it

Unless you have funny stuff on your home network (primarily multiple
subnets) this doesn't sound like a DHCP issue at all and blaming
the power supply is simply taking a shot in the dark at this point.

I personally suspect this is a problem with MAC address table expiry
- if you get it to the point where it is "correctly" cabled but
doesn't work does it then start working on its own if you leave it
for half an hour?  If it does that suggests the switch(es) (including
the one built in to your router) are sending the traffic to the
wrong port.

That process isn't magic - if the switch has a seen packet _from_
the destination MAC in question "recently" (typically around the
last ten minutes) it sends the traffic out the last port traffic
from that MAC came from.  The other ports don't get it, even if
the device is moved between switch ports.  That continues until
either the machine sends out a new packet (which will cause the
switch to note the new MAC->switch port relationship) or the address
expires after which time it is treated as a "new" MAC and the packet
is sent out all ports until the correct location is established.

You tend not to see this too much on Windows machines since they
tend to be fairly chatty on the network anyway (SMB in particular)
which keeps the switches updated.  A Pi on the other hand tends to
be a lot quieter unless you yourself start adding network services.

If this is the real issue then resetting the switch would solve
it for that one time.  A permanent fix needs something to keep
"tickling" the network connection.  The easiest way to do that
would be in root's crontab with a line:

*/6 * * * * ping -c 1 (IP of gateway) >/dev/null

That's based on this NetBSD system here but the AFAICR the crontab
format is fairly standard between Unix systems.

--  
Andrew Smallshaw
snipped-for-privacy@sdf.lonestar.org

Re: Odd Network Issue

Thanks for the detailed reply.

Quoted text here. Click to load it

I don't think I'm doing anything funny with my network.

The router has three ethernet ports.  One is unused, the other two both  
lead to Netgear switches which have a variety of computers plugged into  
them (not all of them on all of the time).  I also have some devices on  
WiFi.

Most of the *nix boxes are allocated IP addresses at the router (as  
discussed elsewhere in this thread), other stuff is fully dynamic.

When everything is in its usual location, one of the switches has two  
Pis plugged into it, the one that I've been having the problems with,  
and another one (which is on the other end of a 0.5M cable).  This  
second one (a Pi B+) works fine.

Quoted text here. Click to load it

I don't think waiting half an hour has worked in the past (I'm wracking  
what is left of my brains here), doing something physical (e.g.  
reconnecting network cables) sometimes seems to do the trick.

<snip useful stuff>

Quoted text here. Click to load it

Interesting.  Some time back, I was having problems with network  
dropouts between my the switch that the Pi isn't on, and the router  
(that problem has been identified) .  In trying to work out what was  
happening, I put a cron job onto the other Pi (that was the only one  
running at the time) which pings the router every minute, logs the time,  
and then emails me the results once a day.  This morning I modded that  
script to record the Pi's CPU temperature, and installed the same script  
on the Pi that I was having a problem with.  It will be interesting to  
see if that resolves the issue next time the power goes off.

For those that might be interested, the local weather stations suggest a  
maximum air temperature of mid teens today.  This afternoon, the sun  
made a half hearted attempt to come out (the outside Pi is in the shade  
in the morning).  The inside Pi (in the loft) was running between 35 and  
40 degrees, the outside one between 42 and 50 degrees.

Adrian
--  
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline