Cannot connect to Linux host from Windows 7

The connection failure, if the ip is correct, does this Linux box run iptables/firewall?
Are you able to connect to this Linux box from any other Linux box?

No iptables running. Yes, I believe I mentioned in my OP that other Linux boxes can connect w/o problem, and the Windows box can can connect  to other Linux boxes on 22 and 5900 w/o problem. That's the puzzler.

Hi Mark,

IP address/netmask of this linux box and the windows box
Possibly/likely netmask typo that effectively excludes this box from being on the same segment as the windows box but is seen as local to other linux boxes.

192.168.0.22 mask 255.255.255.248
while the windows box is
192.168.0.24 mask 255.255.255.240
windows mask includes the linux as a direct access/local while the linux box sees the windows box as remote, next segment.
the other linux boxes are within the segment that is seen as local to the linux box 192.168.0.22. 192.168.0.17,18,19,20,21

does either system have issues accessing the outside world, internet?
the one that does, is the one with the mad mask, not the same as other systems on the network, router...

netmasks look OK (below). No hosts have trouble connecting to the outside world.

"Problem" Linux host 'netbook':

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.22  netmask 255.255.255.128  broadcast 192.168.0.127
        inet6 fe80::8daa:a477:fb66:34ad  prefixlen 64  scopeid 0x20<link>
        ether c0:18:85:8b:ed:31  txqueuelen 1000  (Ethernet)
        RX packets 33531  bytes 26525085 (25.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28849  bytes 4256661 (4.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Select allOpen in new window

Linux host Win7 can connect to:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.15  netmask 255.255.255.128  broadcast 192.168.0.127
        inet6 fe80::f66d:4ff:fe5f:ffd1  prefixlen 64  scopeid 0x20<link>
        ether f4:6d:04:5f:ff:d1  txqueuelen 1000  (Ethernet)
        RX packets 15389137  bytes 1638253524 (1.5 GiB)
        RX errors 30  dropped 1681  overruns 30  frame 0
        TX packets 104122575  bytes 152117601839 (141.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Select allOpen in new window

Win7:

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe FE Family Controller
   Physical Address. . . . . . . . . : 44-1E-A1-C8-E8-9B
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::1494:3a18:e057:a2fa%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.65(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Lease Obtained. . . . . . . . . . : Wednesday, June 28, 2017 11:17:14 AM
   Lease Expires . . . . . . . . . . : Thursday, June 29, 2017 11:17:14 PM
   Default Gateway . . . . . . . . . : 192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 340008609
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-FB-16-8D-94-39-E5-11-A2-2

   DNS Servers . . . . . . . . . . . : 192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Select allOpen in new window

Does your wireless network exist in the same vlan?
Run netstat -an | grep ":22"

Network/netmask seems right.
So at the same that you can not connect to a Windows box, if you connect to another Linux box you are an,e to connect to the wirelessly connected netbook, correct?

The reply you get when attempting to telnet basically means that the service is not available.at might explain the issue,

Try switching Ips of the Windows box with the Linux box if possible. Put the Linux box from 15 to 65 and the Windows box from 65 to 15 for the purpose of the test and see. If connection issues follow the IP or remain with the OS.

please double check to make sure there is no rules along the path

arnold:

Does your wireless network exist in the same vlan?
Run netstat -an | grep ":22"

On the 'netbook' Linux host:

# netstat -an | grep ":22"
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.22:22         192.168.0.15:55342      ESTABLISHED
tcp6       0      0 :::22                   :::*                    LISTEN

Select allOpen in new window

Network/netmask seems right.
So at the same that you can not connect to a Windows box, if you connect to another Linux box you are an,e to connect to the wirelessly connected netbook, correct?

Sorry, don't know what you're asking here.

The reply you get when attempting to telnet basically means that the service is not available.at might explain the issue,

But, the service *is* avaiable, elsewise I would not be able to connect to 'netbook' from the other Linux hosts.

Try switching Ips of the Windows box with the Linux box if possible. Put the Linux box from 15 to 65 and the Windows box from 65 to 15 for the purpose of the test and see. If connection issues follow the IP or remain with the OS.

Good idea, but might take a while for me to set that up. All IPS are DHCP allocated.

please double check to make sure there is no rules along the path

I'll double-check but there is no iptables running the the 'netbook' Linux host and I don't think Windows can restrict access via IP.

on the router use the MAC address to reserve the opposite IP to what each system now has.
what I was ask9ing is to when unable to connect to .22 to use another linux as a jump server to get to .22.
windows to linuxA fails.
windows to linuxB succeeds to linuxA?

when unable to connect to .22 to use another linux as a jump server to get to .22.
windows to linuxA fails.
windows to linuxB succeeds to linuxA?

I think this is essentially what I am already doing. I use putty on the WIN7 computer to ssh to e.g. 192.168.0.15, which works fine, then I can ssh from 192.168.0.15 to 192.168.0.22 w/o problem. Is that what you're asking?

I think another thing I'm going to try is taking the wireless out of the loop and connecting to the 'problem' Linux hard-wired. That will take me some time to re-arrange things as there is no convenient wired line where the computer now resides.

before you do the wireless to wired switch, configure IP reservation by swapping the IPs of the linux/windows and see if the issue follows the IP or the issue stays with the windows which would suggest a routing table entry that might be causing issues
netstat -rn on the windows system. an errand routing rule added that misdirects/diverts the .22 traffic..

another option get onto the .22 linux box and using tcpdump -i wlan0 -n host 192.168.0.65

Then attempt to connect to it directly from the windows box you could use wireshark, windows network monitor to capture packets destined to 192.168.0.22

here might be able to see whether the packets leaves the windows box and not received on the .22 or received and the response does not find its way back, etc.....

the tcpdump directive should be
tcpdump -n -i wlan0 -p src host 192.168.0.65

Actually, I had already tried the tcpdump thing. No packets arrived at the Linux .22 host from Win7.

I went a head and switched to wired as that was the easiest thing to try next. Wired works! (eth0 ip is 192.168.0.81)

Now I need to puzzle about why all Linux hosts can connect to wireless 192.168.0.22, but the Windows host cannot; and all hosts including the Windows host can connect to wired 192.168.0.81

look at the routing table on the windows box and it might fit within a rule that routes a request to 192.168.0.22 to some other destination.....

netstat -rn
route print

it is hard to guess whether the issue is isolated to the .22 IP or to any IP that winds up on the wireless device.

with eth0 disabled:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
192.168.0.0     0.0.0.0         255.255.255.128 U         0 0          0 wlan0

Select allOpen in new window

I don't have `route print`, but I can ...:

# route -CFvnee
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
0.0.0.0         192.168.0.1     0.0.0.0         UG    303    0        0 wlan0    0     0      0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo       0     0      0
192.168.0.0     0.0.0.0         255.255.255.128 U     303    0        0 wlan0    0     0      0
Kernel IP routing cache
Source          Destination     Gateway         Flags Metric Ref    Use Iface    MSS   Window irtt  TOS HHRef HHUptod     SpecDst

Select allOpen in new window

The above is with IP 192.168.0.22. Per your suggestion, I did change the IP to something different: 192.168.0.50. I did this as a manually assigned IP from the ASUS router (DHCP server), and ... the Windows box can connect!

Now I need to figure out why. Perhaps with a statically assigned IP the route is more discoverable? I'll change that to a static IP in the Linux box itself and remove the IP assignment from the router and see if that makes a difference.

So ... I removed the manual IP assignment from the router and put a static IP of 192.168.0.8 in the rc.inet1.conf file, gateway: 192.168.0.1. That worked too. I could ssh from putty from the Windows 7 computer. Finally, I put everything back the way it was with the Linux wireless soliciting a IP from the router DHCP server. As expected, it assigned it to 192.168.0.22. Not expected, the Windows 7 computer could connect!!!!! I have no idea what's going on. I have not been able to connect to this host from the Windows 7 computer since I made this post. I have not rebooted the WIN7 computer. I have no idea why it is working now.

It's been connecting consistently for several days now, through reboots, etc. I guess it's "fixed", though I'll never know exactly what was wrong. You explanation is as good as any!

Thanks, I usually like puzzles, and chasing down the unordinary versus the mandane issue.

Glad I could help.