# telnet problem

## ONEEYEMAN

Hi,

I am trying to telnet from my Gentoo box to one of my Windows (8.1) laptops.

This laptop runs the MS SQL Server 2012 Express which listens on default port 1433.

I turn off both CoMoDo and Windows firewall so they both not interfere with the testing and I can deal with them later.

On my Gentoo laptop I open up the terminal (I'm running KDE 4) and issued:

```

busybox telnet 192.168.1.4 1433

```

after a long wait time, I got a message "Connection timed out".

I did install telnet server on windows, so everything should be fine there.

How do I go to troubleshoot this issue?

Anybody got this problem before?

Thank you.

----------

## eccerr0r

Can you at least ping the machine?  If you can ping but telnet times out, then this is still a firewall problem....  Last I dealt with windows, that windows firewall is annoying...

----------

## ONEEYEMAN

eccerr0r,

Yes, ping works. It is a telnet and therefore freeTDS.

Like I said both CoMoDo and Win Firewall are off.

Thank you.

----------

## Hu

Run tcpdump on the Linux machine to monitor traffic to and from the Windows laptop.  You should see a SYN from Linux to Windows when you try to connect.  If the Windows network stack responds SYN|ACK, then it has accepted your connection.  If it responds RST or does not respond, then it refuses to talk to you.  If it does not respond, you have a firewall problem.

----------

## eccerr0r

That RST packet should result in the 'connection refused' - this should be the default case on any OS that's not listening to a particular port.  Since it does not respond, this has to be the firewall problem.  Likely you have a setting somewhere to default ignore connections to all ports, alas I don't really do windows...

This is, of course, if you don't have an incoming packet dumping on your Linux side too...

----------

## ONEEYEMAN

Hi, Hu,

What's best way to run  tcpdump? Like I said I'm trying to connect from 192.168.1.2 to 192.168.1.4 on port 1433.

Thank you.

----------

## nativemad

It could also be that the SQL server isn't listening on the port really...

```
netstat -na | find "1433"
```

 on the Windows machine should list a line like 

```
TCP  0.0.0.0:1433   0.0.0.0:0    LISTENING
```

.

If that is not the case, then you will need to configure the SQL Server to allow tcp connections.

You don't need to have the telnet-server installed on windows to connect to the SQL service... You basically just abuse the telnet client!   :Wink: 

Tcpdump should be run on the gentoo box while you are trying to connect with telnet....

HTH, cheers

----------

## ONEEYEMAN

nativemad,

Yes, I got exactly that line. But for some reason the line with my IP says "ESTABLISHED":

```

C:\Users\Igor>netstat -na | find "1433"

  TCP    0.0.0.0:1433           0.0.0.0:0              LISTENING

  TCP    192.168.1.4:1433       192.168.1.4:55788      ESTABLISHED

  TCP    192.168.1.4:55788      192.168.1.4:1433       ESTABLISHED

  TCP    [::]:1433              [::]:0                 LISTENING

```

Also, I'm not a network guru - how do I run "tcpdump"?

Thank you.

----------

## Syl20

 *ONEEYEMAN wrote:*   

> I did install telnet server on windows, so everything should be fine there.

 

You shouldn't. First, because nobody uses a telnet server today. SSH is a lot more safe.

Second, because you use here the telnet client to reach a SQL server, not a telnet one. And you (and most of the netadmins) use it because this client shows the raw application data, and you can say it which TCP port to use. That's all.

 *Quote:*   

> How do I go to troubleshoot this issue?

 

The laptop is the server, and the linux box is the client, right ?

I suppose there's nothing but an ethernet cable, or a switch, between both ? And this stuff does its job, because ping works.

On the server, you could install wireshark, which can show you the network traffic, like tcpdump on *nix does. If nothing appears when you try to reach the MS SQL port with your linux box, then either something (certainly a firewall) rejects your connection tries, or nothing listens on the TCP port 1433. Your netstat output show the second option is invalid.

Be careful, "disabling" a firewall doesn't necessarily means all the network traffic is allowed. Some firewalls, on the contrary, block everything when you deactivate them.

On the client, you can use nmap to show which ports are open on the server. If nothing is open, then something (like a firewall) certainly blocks you.

You can use (once installed) tcpdump like this :

```
 # tcpdump -ni <your_interface> host 192.168.1.4
```

You should read the tcpdump man page.  :Wink: 

Last, but not least : are you sure the SQL server is well configured to accept connections from your linux box ? Don't ask me how to know that, I don't know MS SQL at all...

----------

## nativemad

 *ONEEYEMAN wrote:*   

> 
> 
> ```
> 
> C:\Users\Igor>netstat -na | find "1433"
> ...

 

Ok, this means that you are actually connected!   :Wink: 

Question: what are you doing with that telnet-client!? What is the goal!?

If you just connect with the telnet client, it just sits there and will show nothing if you can't talk raw-MSSQL to the server!  - I guess this worked since some time and you just haven't recognized it!   :Wink: 

To see the difference, just telnet a port that has nothing listening on the Server...

If you really want to use MSSQL from the linux box you will need something like unixODBC to actually send SQL commands!

----------

## Syl20

 *nativemad wrote:*   

>  *ONEEYEMAN wrote:*   
> 
> ```
> 
> C:\Users\Igor>netstat -na | find "1433"
> ...

 

No, this means the Windows server is connected to itself.

----------

## bbgermany

Have you tried to use nmap and scan the port? 

greets, bb

----------

## eccerr0r

As far as I know in un*x, if a program is listening to the port, it will always SYNACK and you won't get a timeout, unless you use a kernel filter to block the syn/synack.

I don't know if the Windows kernel is the same way, whether you can specify which clients you can send the synack to if you want to let that server communicate to the connecting client.

Since you did install a telnet server on windows, you should be able to telnet to that port, does that work?  Or you could enable RDP and can you telnet to the RDP port?  VNC?  SMB?  Just wondering if *anything* works first...

You don't have any special networking equipment that the packet needs to go through, right? like wireless bridges with bridge firewalls, etc. ?

----------

## ONEEYEMAN

Hi,

Here is the output of nmap:

```

IgorDellGentoo dbhandler # nmap -v -p1433 192.168.1.4

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-21 23:49 EDT

Initiating ARP Ping Scan at 23:49

Scanning 192.168.1.4 [1 port]

Completed ARP Ping Scan at 23:49, 0.21s elapsed (1 total hosts)

Initiating SYN Stealth Scan at 23:49

Scanning fordanwork (192.168.1.4) [1 port]

Completed SYN Stealth Scan at 23:49, 0.53s elapsed (1 total ports)

Nmap scan report for fordanwork (192.168.1.4)

Host is up (0.051s latency).

PORT     STATE    SERVICE

1433/tcp filtered ms-sql-s

MAC Address: AC:B5:7D:E8:72:B7 (Liteon Technology)

Read data files from: /usr/bin/../share/nmap

Nmap done: 1 IP address (1 host up) scanned in 0.83 seconds

           Raw packets sent: 3 (116B) | Rcvd: 1 (28B)

```

It looks like the SQL Server is listening on the port/ I am just not sure what "filtered" means.

I did run this with both CoMoDo and Windows FW running.

Does this mean that someone blocks access to the port/SQL Server?

This is the result of running "busybox telnet 192.168.1.4 1433":

```

IgorDellGentoo dbhandler # tcpdump -ni wlan0 host 192.168.1.4

dropped privs to tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

23:55:47.799118 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145497763 ecr 0,nop,wscale 7], length 0

23:55:48.799825 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145498764 ecr 0,nop,wscale 7], length 0

23:55:50.803826 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145500768 ecr 0,nop,wscale 7], length 0

23:55:52.803808 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

23:55:52.811044 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

23:55:54.811829 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145504776 ecr 0,nop,wscale 7], length 0

23:56:02.835814 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145512800 ecr 0,nop,wscale 7], length 0

23:56:18.868029 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145528832 ecr 0,nop,wscale 7], length 0

23:56:23.875809 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

23:56:23.878441 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

23:56:50.931822 IP 192.168.1.2.44971 > 192.168.1.4.1433: Flags [S], seq 2163914611, win 29200, options [mss 1460,sackOK,TS val 1145560896 ecr 0,nop,wscale 7], length 0

23:56:55.939806 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

23:56:55.943128 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

23:56:59.058852 IP 192.168.1.4 > 224.0.0.22: igmp v3 report, 1 group record(s)

23:57:04.076486 IP 192.168.1.4 > 224.0.0.22: igmp v3 report, 1 group record(s)

^C

15 packets captured

15 packets received by filter

0 packets dropped by kernel

```

It results in:

```

igor@IgorDellGentoo ~/wxFork/buildX11 $ busybox telnet 192.168.1.4 1433

telnet: can't connect to remote host (192.168.1.4): Connection timed out

```

And this is the result of trying to connect to the server with unixODBC:

```

igor@IgorDellGentoo ~/wxFork/buildX11 $ isql freetds sa 

[ISQL]ERROR: Could not SQLConnect

IgorDellGentoo dbhandler # tcpdump -ni wlan0 host 192.168.1.4

dropped privs to tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

00:00:23.112889 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145773077 ecr 0,nop,wscale 7], length 0

00:00:24.115829 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145774080 ecr 0,nop,wscale 7], length 0

00:00:26.119775 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145776084 ecr 0,nop,wscale 7], length 0

00:00:28.115810 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

00:00:28.119398 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

00:00:30.131789 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145780096 ecr 0,nop,wscale 7], length 0

00:00:38.147801 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145788112 ecr 0,nop,wscale 7], length 0

00:00:54.195839 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145804160 ecr 0,nop,wscale 7], length 0

00:00:59.203757 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

00:00:59.206901 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

00:01:14.549510 IP 192.168.1.4 > 224.0.0.22: igmp v3 report, 1 group record(s)

00:01:16.085365 IP 192.168.1.4 > 224.0.0.22: igmp v3 report, 1 group record(s)

00:01:26.259833 IP 192.168.1.2.44973 > 192.168.1.4.1433: Flags [S], seq 1896183075, win 29200, options [mss 1460,sackOK,TS val 1145836224 ecr 0,nop,wscale 7], length 0

00:01:31.267806 ARP, Request who-has 192.168.1.4 tell 192.168.1.2, length 28

00:01:31.277219 ARP, Reply 192.168.1.4 is-at ac:b5:7d:e8:72:b7, length 28

00:01:36.053536 ARP, Request who-has 192.168.1.1 tell 192.168.1.4, length 28

^C

16 packets captured

16 packets received by filter

0 packets dropped by kernel

```

Thank you.

----------

## eccerr0r

Still looks like software firewall on windows.  It's responding to arps and actually sending crap to the network (try telnet from the windows machine to Linux, I suspect it should work).

----------

## bbgermany

 *eccerr0r wrote:*   

> Still looks like software firewall on windows.  It's responding to arps and actually sending crap to the network (try telnet from the windows machine to Linux, I suspect it should work).

 

I think the same. If you have disabled the firewall service in win 8.x/2012 and higher, you will get a strange behavior of the system. Better way, is to allow access to port 1433 via the advanced/extended settings (dont know the exact name for windows in english).

greets, bb

----------

## Hu

Sometime after Windows XP, Microsoft introduced the concept of "locations" for the network, where the builtin values are Home, Work, and Public.  If the network connection is classified as Public, Windows will filter incoming traffic aggressively.  I think I encountered at least one system where the "Windows Firewall" was configured fairly permissively, but the network connection was classified as Public, so traffic was still filtered.  If you are certain that you have configured all relevant software firewalls not to block the traffic, and it still does not work, check the zone that Windows has assigned to the network connection.

For Windows 7, this is configurable from Control Panel -> Network and Internet -> Network and Sharing Center.

----------

