| View previous topic :: View next topic |
| Author |
Message |
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3610
|
 Posted: Mon Jun 20, 2016 2:12 pm Post subject: telnet problem |
 |
|
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:
| Code: |
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. |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Mon Jun 20, 2016 6:50 pm Post subject: |
|
|
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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3610
|
| Posted: Mon Jun 20, 2016 8:02 pm Post subject: |
|
|
eccerr0r,
Yes, ping works. It is a telnet and therefore freeTDS.
Like I said both CoMoDo and Win Firewall are off.
Thank you. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Tue Jun 21, 2016 1:01 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Tue Jun 21, 2016 1:15 am Post subject: |
|
|
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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3610
|
| Posted: Tue Jun 21, 2016 2:10 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
nativemad
Developer
Joined: 30 Aug 2004
Posts: 918
Location: Switzerland
|
| Posted: Tue Jun 21, 2016 9:30 am Post subject: |
|
|
It could also be that the SQL server isn't listening on the port really...
| Code: | | netstat -na | find "1433" |
on the Windows machine should list a line like | Code: | | 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! 
Tcpdump should be run on the gentoo box while you are trying to connect with telnet....
HTH, cheers
_________________
Power to the people! |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3610
|
| Posted: Tue Jun 21, 2016 11:44 am Post subject: |
|
|
nativemad,
Yes, I got exactly that line. But for some reason the line with my IP says "ESTABLISHED":
| Code: |
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. |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Tue Jun 21, 2016 12:53 pm Post subject: Re: telnet problem |
|
|
| 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 : | Code: | | # tcpdump -ni <your_interface> host 192.168.1.4 |
You should read the tcpdump man page.
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... |
|
| Back to top |
|
|
nativemad
Developer
Joined: 30 Aug 2004
Posts: 918
Location: Switzerland
|
| Posted: Tue Jun 21, 2016 1:38 pm Post subject: |
|
|
| ONEEYEMAN wrote: |
| Code: |
C:\Users\Igor>netstat -na | find "1433"
TCP 192.168.1.4:1433 192.168.1.4:55788 ESTABLISHED
|
|
Ok, this means that you are actually connected!
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!
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!
_________________
Power to the people! |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Tue Jun 21, 2016 2:02 pm Post subject: |
|
|
| nativemad wrote: | | ONEEYEMAN wrote: |
| Code: |
C:\Users\Igor>netstat -na | find "1433"
TCP 192.168.1.4:1433 192.168.1.4:55788 ESTABLISHED
|
|
Ok, this means that you are actually connected! |
No, this means the Windows server is connected to itself. |
|
| Back to top |
|
|
bbgermany
Veteran
Joined: 21 Feb 2005
Posts: 1844
Location: Oranienburg/Germany
|
| Posted: Tue Jun 21, 2016 3:14 pm Post subject: |
|
|
Have you tried to use nmap and scan the port?
greets, bb
_________________
Desktop: Ryzen 5 5600G, 32GB, 2TB, RX7600
Notebook: Dell XPS 13 9370, 16GB, 1TB
Server #1: Ryzen 5 Pro 4650G, 64GB, 16.5TB
Server #2: Ryzen 4800H, 32GB, 22TB |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Wed Jun 22, 2016 12:06 am Post subject: |
|
|
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. ?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3610
|
| Posted: Wed Jun 22, 2016 3:54 am Post subject: |
|
|
Hi,
Here is the output of nmap:
| Code: |
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":
| Code: |
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:
| Code: |
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:
| Code: |
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. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Wed Jun 22, 2016 5:57 am Post subject: |
|
|
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).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
bbgermany
Veteran
Joined: 21 Feb 2005
Posts: 1844
Location: Oranienburg/Germany
|
| Posted: Wed Jun 22, 2016 8:45 am Post subject: |
|
|
| 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
_________________
Desktop: Ryzen 5 5600G, 32GB, 2TB, RX7600
Notebook: Dell XPS 13 9370, 16GB, 1TB
Server #1: Ryzen 5 Pro 4650G, 64GB, 16.5TB
Server #2: Ryzen 4800H, 32GB, 22TB |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Thu Jun 23, 2016 1:20 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
