I run 2 different RasPis as headless servers on my WiFi LAN. Each selects a different hard coded IP from the router. I ssh into them, either from a desktop that is wired ethernet into the router, or from a laptop operating on the same WiFi LAN. The results are similar regardless of which RasPi I am trying to connect.
I often get an error message when trying to ssh "no route to host". If I keep retrying, I will eventually connect without changing anything. Sometimes it takes 1 try, sometimes it takes 20 tries, sometimes it takes 4 tries (or any random number < 20). Sometimes, it connects on the very first try. The RasPis are separated by 50 feet (15m).
Any ideas what causes this, and what I should do to allow me to connect first time?
No idea what causes it but it happens to me too. For me it started to happen when I changed my router to a Thomson Technicolor TG582n. I just assumed it's buggy software in the router.
Buggy Router software Poor signal @ the Pi (if possible try another location) interference from neighbours changing the channel on the router may help. The wifi scanner app on an android phone can assist here
remember all wifi channels overlap with their neighbours so channels 1 6 & 11 are generally preferred as they are clear of each other
It sounds a bit like you might have an IP conflict or something like that, e.g. two systems with the same IP or a system with a different subnet address.
I had something similar happen, but only with IPv6, when I was using a wifi bridge to join the two halves of my home LAN. I suspect you've got a MAC collision somewhere. Try replacing one of the wifi adapters with a different model. I recommend the Thinkpenguin brand - they use good Atheros chips so you don't have to muck with drivers.
"no route to host" ICMP error is returned by some IP stacks when there's no ARP entry for the host you are trying to contact. This will normally be the case when you haven't exchanged any IP packets with that host for some minutes, and this causes your system to send an ARP request to find out the host's ethernet address. If there isn't a prompt ARP reply, then some IP stacks return "no route to host" (which is a bit misleading, as it's not actually a routing problem).
So I suspect the cause is slow or intermitent response to ARP requests.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
I wonder if it might be the router dropping packets.
My ISP provides me with a less-than-super "Superhub" that's a wifi router with four Ethernet connections. It's wifi is fairly abysmal and my neighbourhood is wifi-dense so I connected everything up with wire. (Flat cat5e ribbon cables under the carpets, connecting to cable-joiners hot-glued to the skirting boards, and it carries 1G Ethernet OK.) But I then discovered that the Ethernet ports seem to time-out after 9 seconds or so, and if you wait longer than that between data transfers, it will drop the first packet of the subsequent transfer. (If I ping it at 9s intervals then no problem, but if the gap is longer than that then most of the pings get dropped.) So I've set up scripts on everything that connects to the router to ping it every 9s from boot-up.
I don't know if the same problem would occur with wifi, because I believe that wifi will maintain a continuous polling of the base-station.
If you are able to try another router though, that might be a worthwhile test.
I take it from the above that the pi's use wireless?
What is in the 50 feet between them and the router? Walls, floors, windows, free space? It can make a big difference. In particulay passing through a solid wall at an acute angle is bad. Some plasterboard used in stud partitions has a foil backing, which stops almost all radio signals. Some thermal glass has a metal film that has a similar effect. Ironstone is awful.
Floors (unless reinforced concrete) are usually almost transparent to radio.
That sounds as though the ARP timeout is set to 10 seconds. It's normally 15 minutes. Once the entry in the ARP cache is removed, the next ping causes a dialog to establish who owns the IP address. It should still work, but it is the reason why the first ping response is often longer than the others.
The issue seems to be with the "superhub", since it affects all connections, but it probably doesn't like flat cable at high data rates.
I would try putting a gigabit switch between the router and your LAN, so that only external traffic uses the router's ports. If the problem persists you can be fairly sure it's a cable problem.
--
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/
A solution to that would be to get a decent wireless router such as the ASUS RT-AC66 and connect it up to one of the ethernet ports, disabling the wireless on the superhub. The ASUS has one of the strongest signals, so should be able to poke its way trough overused 2.4GHz. Plus for devices that support it, there is the 5GHz frequencies which are far less crowded.
That classifies as completely broken, I can't believe they get away with selling such crap.
Perchance is the router a SpeedStream? I had one of that brand several years ago. I had to run a ping to the NNTP server or slrn would hang for ~30 seconds or longer if I went more than about 10 seconds between actions. I now refer to that brand as "SpeedBump", and that unit has been exiled to the garage.
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
How do you know? Actually tested and through put measured? Or just that the little lights on the cards/ports indicate 1G?
I'm suspicious of the cabling as well.
Simpler to buy a proper cable or two and try them in place of the flat stuff and joint boxes. The use of the term "Superhub", provided by the ISP in the UK hints that this is a BT supplied thing. I suspect there would be a lot of noise about this problem if it was really down to the "Superhub".
Actually the Superhub is a Virgin Media thing (combined cable modem/router/switch/wireless AP). BT supply a Homehub.
I have a Superhub and don't have any trouble with it (wired - I don't use wireless if I can help it). My house is cabled with standard CAT5 or CAT5e cable and RJ45 wall sockets in most rooms, although I do have a number of other Gigabit switches in the network.
I got a VM superhub a few years back when we tried the 20Mbps service upgrade option over the then standard 10Mbps service (the existing Ambit 120 modem wasn't up to the job so VM replaced it with the Superhub cable modem and Gbit WiFi gateway router combo unit, rendering our existing Cisco router redundent - it didn't have Gbit lan ports).
Performance seems to be excellent on the current 30Mbps service and the WiFi seems to penetrate 3 floors of timber construction quite well (it doesn't negotiate a large lump of earth and brickwork in between the back kitchen/dining room and the front of the basement where the Superhub is located but that's precisely to be expected in the circumstance - I've added a cheap cisco wifi router to the tangled mass of cables under the printer desk (handy to the 8 port Gbit switch) in my 1st floor office to fill in that hole in the wifi coverage).
I've always assumed it was a version 1 Superhub since I only started seeing references to "Superhub 2" modem/routers a year or two after we got ours. A quick look at the router status/information webmin page shows the hardware version as 2.00 ( the software version is V2.38.01 btw if that is of any significance).
The only minor issue I have with it is its relatively sluggish response when navigating its webmin interface (2 or 3 seconds response time versus the half a second or so of previous gateway routers). It's only minor on account I'm not delving into its webmin pages on a routine basis. Other than that, it seems to perform quite adequately (but then, I'm not on a 150Mbps service, so I'm hardly stressing it at the more leisurely 30Mbps wan connection speed).
As for its performance as a 4 port Gbit ethernet switch, I can't really say since the only PC connected to the LAN at that point with a Gbit ethernet adapter doesn't have enough CPU 'grunt' to do better than 16 MB/s anyway. All my speed critical data transfers go via the Netgear 8 port Gbit switch upstairs in my office, entirely avoiding the potential bottleneck of the VM Superhub's ethernet switch.
There are occasions when I see connectivity issues over the WAN connection but these tend to happen in the wee small hours (around 4am
- I'm a night owl). However, it's not always the gateway/router that sometimes benefits from a reset to cure internet connectivity issues, I've discovered that the Netgear 8 port ethernet switch can resolve 'internet' issues by a power down/power up reset. It's worth bearing this possibility in mind whenever a modem/router reset fails to resolve mysterious and weird internet connection issues.
It's definitely the router and I get the same result with cat6 cable.
Yes, it's almost certainly the ARP timeout at 10s. When I was investigating it, I wrote a script to generate pings with increasing gaps and ran it overnight between my main computer and network drive. See how the holes appear after 10s. It looks like a routine that runs every 10s and times-out if no data passed in the previous 10s -- so the problem begins after 10s, getting steadily worse until 20s.
#!/bin/bash read -p "Enter name to device to be pinged: " dv f=$(mktemp -t "ping.$(date +%d%b%y | tr '[A-Z]' '[a-z]').XXXXXX") echo "Ping $dv from $(hostname)" | tee -a $f echo Logging to $f | tee -a $f for ((j=1;;j=(j+1)%32)); do t=0 printf "%3d " "$j" | tee -a $f for ((k=1;k 1 )) && sleep $(( j - 1 )) ping -i5 -w1 $dv >/dev/null [[ "$?" == 0 ]] && c='!' || c='.' [[ "$c" == '!' ]] && let t++ echo -n $c | tee -a $f done printf " %3d\n" $t | tee -a $f done
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.