5

I have two computers in one WiFi network:

  • A - client
  • B - server

Sometimes (once in ten times) after B reboot I am unable to ssh from A to B:

$ ssh 192.168.201.128
ssh: connect to host 192.168.201.128 port 22: No route to host

When I try to ping it, I get:

$ ping 192.168.201.128
PING 192.168.201.128 (192.168.201.128) 56(84) bytes of data.
From 192.168.201.133 icmp_seq=1 Destination Host Unreachable
From 192.168.201.133 icmp_seq=2 Destination Host Unreachable
From 192.168.201.133 icmp_seq=3 Destination Host Unreachable

ARP might be the issue:

$ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
_gateway                 ether   70:4c:a5:a7:c2:57   C                     wlp2s0
192.168.201.128                  (incomplete)                              wlp2s0

I was trying to fix it like this:

$ sudo arp -d 192.168.201.128
$ arping -c 10 -I wlp2s0 192.168.201.128
ARPING 192.168.201.128 from 192.168.201.133 wlp2s0
Sent 10 probes (10 broadcast(s))
Received 0 response(s)

no effect :(

I can workaround the issue by plugging in monitor and keyboard to B (server) and doing either:

1) ping A (client)

OR

2) typing "route" in terminal

Then everything goes back to normal.

Any idea why this might be happening? My guess is that B sometimes doesn't discover gateway correctly. I am unable to verify this, because when I type "route" in B terminal everything goes back to normal.

Side notes:

  1. There is no firewall on B (server)
  2. A (client) is Ubuntu 18.04 Desktop
  3. B (server) is Ubuntu 16.04 minimal (maybe missing some important package for arp/ auto gw discovery?)
  4. B (server) interfaces configuration:
$ cat /etc/network/interfaces
auto lo
iface lo inter loopback
user2449761
  • 263
  • 1
  • 3
  • 8
  • may I know the prefix of your two host's interface IP? – aircraft Apr 03 '19 at 10:40
  • I am not sure if I get the question right. A is 192.168.201.133 while B is 192.168.201.128. Is 192.168.201 the prefix? – user2449761 Apr 03 '19 at 11:06
  • @user2449761, may be you can post the content of the interface configuration from server? – Diamond Apr 04 '19 at 11:37
  • @Diamant I have posted interfaces configuration in side notes, pt. 4. – user2449761 Apr 04 '19 at 12:58
  • @user2449761, hi are you sure that's all? Because there is only entry for the loopback interface.. – Diamond Apr 04 '19 at 13:02
  • yes, that's all. This file looks the same for all my Ubuntu machines – user2449761 Apr 04 '19 at 13:07
  • 2
    `route -n` might offer a view of the route without sending out packets. You should probably make sure that the server sends out some packets to the access point at startup, so that it would be sure to know the MAC address of the server. Wifi is not really a broadcast network. – Gerrit Apr 04 '19 at 14:10
  • thanks @user188737. `route -n` show a correct gateway, and still client is unable to login (`no route to host`). I can add a script to `/etc/NetworkManager/dispatcher.d/` to send some packets after WiFi connection is up. So this kind of WiFi behavior is expected? – user2449761 Apr 05 '19 at 11:19
  • 1
    Yes. It seems the DHCP works allright, but the Access Point is blocking broadcasts, Sometimes there is a checkbox for that. Maybe sometimes the DHCP server on the Access Point doesn't populate its arp table. Putting a fixed ARP entry in the client might also work. – Gerrit Apr 05 '19 at 11:52
  • Does B see the gateway and/or other addresses before pinging A? In particular, what does "arp -an" output look like on B *before* pinging A? Can you try pinging the gateway from B instead of A, and see if that solves the problem too? My guess is that before "B" does any network activity, its interface is in some "sleep" state and isn't actually connected to the network. – wazoox Apr 05 '19 at 11:57
  • If I guessed right, than you would need to check wifi driver parameters to force B wifi controller to go online and never enter power saving mode. – wazoox Apr 05 '19 at 11:58
  • Obviously your client do not get ARP reply when it need so. It is either routing problem on the server or wi-fi not passing it through as others mentioned. Anyway that should not happen and you can start with tcpdump arp on server to see if it really get ARP request and reply properly. But the most probable cause is wireless router. You can post its model and tcpdump output in question. – kab00m Aug 15 '23 at 19:40
  • You can also add static arp entry to client ARP table and see what happens next. If it is a broadcast problem - you will have everything all right, but if the problem persists that means server wifi card is going in low-power and stop getting any packet at all. – kab00m Aug 15 '23 at 19:43

2 Answers2

1

I suggest you to check your WiFi router. After rebooting your server, are you able to see in router's administrative interface an IP address lease from its internal DHCP server to your server? Can you ping the server from your router? A cable link between router and server is feasible?

I experience a similar problem at home with a laptop computer and a smartphone connected to a WiFi network provided by an old TP-Link TLWR340G router. Sometimes, I am unable to establish a connection from smartphone to computer, despite both devices establish internet connections successfully. When such problem occurs, I solve it by pinging smartphone from computer until I get a response, which is generally after 20 packet misses.

0

What I have used in the past is to aggregate/add those servers (desired to be reached) into the hosts file and flush your dns cache. You can find a good resource on hot to edit your hosts file here.

Depending on the version of linux/unix/mac version you can found your file on /etc/hosts or /private/etc/hosts.

Once there, you can add a new server/host adding a line in the format like:

 192.168.201.128 remote_host

You can see examples into the hosts file

Then you can force the changs to have effect flushing the DNS what sounds like the problem you are facing.

  dscacheutil -flushcache
mario ruiz
  • 111
  • 3
  • 1
    That would help if 1) there was a DNS issue and 2) OP was using DNS names to connect. Given that (2) does not apply here, this will not help. OTOH pre-seeding the arp cache (/etc/ethers - https://linux.die.net/man/5/ethers) might. – symcbean Aug 16 '23 at 09:38
  • thanks for the note @symcbean – mario ruiz Aug 16 '23 at 14:29