Odd Network Issue

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.

ping

Even with ping running?

for

log

How does the Pi know what to use if it's not in its config and is not using DHCP?

Wires don't break cleanly, intermittentcy is common especially when things are moved.

--
Cheers 
Dave.

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 
alan@adamshome.org.uk 

Just to recap - there are three ways to define the IP address for a computer

1: DHCP. The server assigns an address of its choice

2: DHCP reservation. An IP address is associated with a hardware address, by the DHCP server.

3: Static. A config file on the computer defines the address. It also needs to define the network mask and the default gateway.

One scenario which causes apparently random problems is when some computers use static while others use DHCP. It occurs if the static address is in the DCHP range.

Scenario one. Static machine starts. Then DHCP machine starts. Router detects that the static address exists, and avoids issuing it. All works. (Not all DHCP servers make this check resulting in the same problem as scenarion2)

Scenario two: DHCP client starts and gets issued an address which happens to be the one set as static. Static starts. Now each machine on the netwoek has to decide which hardware address to sent messages to for the IP address. This produces an unpredictable combination of working and non-working routes.

Scenario 2 can also occur if the network was broken during startup then becomes connected. Commonly this occurs if there is a flaky network cable somewhere.

The solution to prevent this is always to make sure that static (i.e. manually defined) addresses are not included in the DHCP scope.

In contrast DHCP reservations must be in the scope. I would also set reservations at the high end of the scope, since the server automatically starts from the low end. It's not essential to do this, but it can make fault-finding easier.

So I would typically have

192.168.4.1 router 192.168.4.2 - 100 DHCP scope, reservations from 100 downwards 192.168.4.101-254 manually assigned addresses.

Alan

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 

In message , Adrian writes

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 

Power supplies can cause all manner of problems. Try another one.

It is using DCHP, the router assigns it the same address every time it requests one, determined by its reported MAC address.

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

This means you have a link on level-2 (ethernet) from the switch/hub to the pi. Have you verified that there is a link on the switch too, so the switch can see the pi?

With tcpdump/wireshark or similar, do you see the dhcp requests from the pi when it boots?

Verify that the switch also have connection lights come on. Then run wireshark and/or tcpdump on some host inhouse and see that you get the dhcp requests.

-- mrr

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.

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 
andrews@sdf.lonestar.org

In message , Morten Reistad writes

I can't remember if I tried checking the light on the switch.

I've not tried running either of those. I'll have a look at installing them on one of my Ubuntu boxes, so if this happens again, I'm ready for it.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected 

In message , Gordon Levi writes

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 

In message , Andrew Smallshaw writes

Thanks for the detailed reply.

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.

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.

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 

Degrees alone is a bit misleading.

to the topic: If you don't want to connect a keyboard/monitor to the PI outdoors, you might consider saving some debug stuff on the sd-card for later examination.

like sleep 200 ifconfig > /mylog_ifconfig route -n > /mylog_route dmesg > /mylog_dmesg ...

The Pi's network interface is in a multifunction chip. It may not have t he drive or sensitivity to handle such a long cable run. Even the net conn ector quality could be a problem on long cable runs. Your Netbook may hav e a better network chip, network interface drivers, or just a better connec tor. The Pi's interfaces have very limited power resources, even compared to a netbook. An external USB network dongle, run off an external powered hub, may work better over your network cable. Plugable Technologies has us b dongles which are Pi friendly. They may handle more of the networking lo ad than the Pi's onboard chip. I can only address the networking issue, not possible heat problems.

I do not work for Plugable Tech. I have had good luck with their products . In another application, a quality USB network dongle increased the networ k performance of an old desktop remarkably, compared to the offbrand networ k card in it. I hope this information helps.

How long is said cable? could it be performance is marginal, so it fails annoyingly intermittently?

Last time I saw something similar (with an IP phone that failed every time, but a PC worked a little shakily) it was a badly stripped cat5 cable on the back of an outlet, which intermittently made connection- it was broken, but presumably heat expanded/contracted it so it sometimes made. I still don't know why the PC worked; perhaps PoE came into play.

Can you beg/borrow/steal a TDM tester?

In message , Chris Bartram writes

Rough figures are available elsewhere in the thread. Looking at the distances in some commercial premises between desks and switches, I don't think the length is excessive.

It is now up and running, and has been happily working away for a week or so. It looks as though the problem is that it is a bit slow establishing itself on the network, and I'm a bit impatient in expecting to be able to get at it almost straight away. I've now got it to ping the router every minute, so hopefully that will improve matters next time it goes off line. Time will tell.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected