No route between clients until pinged from one of them (and not from another)

Question

3 items of hardware involved:

1. Netgear R7000 router with DD-WRT v24-sp2 (08/15/14) kongac (24865M) - it's dual band.
2. Raspberry Pi model B based print server, with Raspbian (Debian for Raspberry). Connected to WiFi (2,4GHz band) with ALFA AWUS050H USB adapter, HP LaserJet 3055 printer connected via USB. Running CUPS 1.5.3, and SANE. Nothing else besides that, and simple Raspbian installation.
3. Desktop running Windows 8.1 with Asus PCE68U. Connected to 5GHz WiFi on same router. Actually here all my other devices, like laptops, phones, etc. behave the same.

Problem: I cannot contact print server from desktop unless I ping desktop from print server. I do it by logging into router via ssh, and then via another ssh session to print server. When I ping desktop, first 4-5 packets are lost, and then it starts working. It does work for couple of minutes after I stop pinging. Then it stops again, and I cannot connect to print server anymore.

CUPS page is not responding, ping to print server gives

Reply from 192.168.xxx.xxx: Destination host unreachable.

Sometimes (mostly when I try to connect to CUPS page, or print while pinging):

Request timed out.

Router can be pinged/contacted from both, desktop and print server, all the time.

Dmesg on server gets lot of:

wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by [router's 2.4GHz MAC]

but not regularly. Sometimes it's every 4 seconds, sometimes it's quiet for 10 minutes. No other things in dmesg during that period.

Question: What can be wrong? Since this looks kind of strange, and it doesn't seem to be consistent (sometimes it works for half an hour after pinging, and sometimes stops after 10 seconds), I'd be grateful for any advice on how to investigate problem deeper.

Notes:

Both clients, printer server and desktop, get their network settings from same DHCP server (static leases outside of dhcp-range). It is dnsmasq running on server. Both get IP in same subnet, with 255.255.255.0 netmask.

Answer 1

This usually indicates a subnet mask mismatch.

In order for the PC to send packets to the printer, it needs the MAC address of the printer. This is done with an arp request who has ip xx.xx.xx.xx

This is sent to the broadcast address of the local network. If the printer has a different subnet mask, it may not see the request if the PC subnet mask does not include the IP the printer has, and so the PC doesn't see a reply and so doesn't get the MAC of the printer.

When the printer pings the PC, it sends the arp request, and because its subnet mask includes the PC, the PC responds with its MAC. However, at this point, the PC adds the MAC address of the printer to its arp table, and so can communicate with the PC.

After a while, the ARP entry on the PC will expire, and it will be unable to communicate with the printer until incoming comms happens again.

Answer 2

It seems that you've some layer 2 isolation brought about by there being multiple layer 1 media: an ip-less frame sent to MAC ff:ff:ff:ff:ff:ff such as is done in an ARP request does not seem to be spanning both WiFi bands.

It's not clear how the two hosts eventually get to exchange data; it's my guess that the linux systems are honouring a redirect of some sort that the windows box is ignoring. tcpdump -env on the print server might reveal some clues. arp -a on all systems before comms are working and during might also be of some use. Does an entry appear for each host, on each host? Just for completeness, it may be possible to statically configure the ARP table as a kludge, but I don't recommend spending much time here.

As well, perhaps doing ping 255.255.255.255 from the Windows system may kick-start the comms, in the interim, as this would take place on the IP layer which seems to be working, and the echo-reply by the printer would temporarily install whatever ARP entry required.

My general suggestions for remedying the problem include examining and toggling interface bridging options on your router, as well as enabling proxy arp functionality, which might serve to adequately mask the network fragmentation I suspect exists between the two bands. proxy arp would have your router respond to who-has requests for your printer's IP, so your Windows box knows it has to send printer traffic to the router. The router has to bridge communication between the two bands regardless...