LinuxQuestions.org
Help answer threads with 0 replies.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
Reload this Page Problem with SSH and router
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
Page 2 of 4 1 2 34
  Search this Thread
Old 01-09-2010, 05:34 PM   #16
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15

Ok, checked packet with sniffer on client machine. All packets after successful authentication are dublicates to the ACK or TCP retransmissions.
Now I've tried to SSH to router itself. In this case source address is correct and src/dst addresses are the same as with PuTTY. For some reason, by using Gnome terminal packets are dublicates and retransmits. I'm totally lost.
 
Old 01-09-2010, 06:06 PM   #17
GooseYArd
Member
 
Registered: Jul 2009
Location: Reston, VA
Distribution: Slackware, Ubuntu, RHEL
Posts: 183

Rep: Reputation: 46
you've run ssh in verbose (-v) mode?
 
Old 01-09-2010, 06:40 PM   #18
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
And also, tell please what is your network configuration: IP for wireless, IP for LAN, network masks, what is network configuration on client, their IP, network masks and GW. Do they all use the same GW.
 
Old 01-10-2010, 03:26 AM   #19
will177
LQ Newbie
 
Registered: Nov 2009
Location: London
Distribution: Ubuntu
Posts: 11

Rep: Reputation: 4
EDIT: Ah, I see you've made progress since your last post on src address, but I'll leave this post here just in case it's of any use.

I don't know, but I would say it's almost definitely your problem. The packet's src address should be the address of the source (the sshd server) not the address of the router!

Imagine this scenario.
What if you ssh'd from machine A to machine E and your route took you through several routers? It would be insane if each router replaced the src address so that it was no longer the address of machine E, wouldn't it?

I'm not sure why this is happening to you, nor how to fix it, but someone somewhere must have encountered it and know how to fix it. (I think some my router does something similar with OpenVPN packets, but that's a bit different I think.)

All the best!

P.S. You definitely don't have anything like IPtables running on your router?

http://www.linuxhomenetworking.com/w...Using_iptables
Last edited by will177; 01-10-2010 at 03:34 AM.
 
Old 01-10-2010, 10:26 AM   #20
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
Hi,

Thanks for helping me out. Of course it is my problem and it is obvious. I think all WiFi and SSH related bugs are corrected by this time. Ok, here it goes debug output from ssh -v

Code:
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.5.6 [192.168.5.6] port 22.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/identity type -1
debug1: identity file /home/xxx/.ssh/id_rsa type -1
debug1: identity file /home/xxx/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.5.6' is known and matches the RSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/xxx/.ssh/identity
debug1: Trying private key: /home/xxx/.ssh/id_rsa
debug1: Trying private key: /home/xxx/.ssh/id_dsa
debug1: Next authentication method: password
username@192.168.5.6's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Now network configuration:
LAN
---
Network: 192.168.5.0/24
Gateway: 192.168.5.254

WiFi
----
Network: 172.16.5.0/20
Gateway: 172.16.5.254

SSH server
----------
IP: 192.168.5.6
Mask: 255.255.255.0
Gateway: 192.168.5.254

SSH client
----------
IP: 172.16.5.109
Mask: 255.255.240.0
Gateway: 172.16.5.254
 
Old 01-10-2010, 10:40 AM   #21
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
You ask the SSH to send packets through TWO different gateway:

LAN
---
Network: 192.168.5.0/24
Gateway: 192.168.5.254

WiFi
----
Network: 172.16.5.0/20
Gateway: 172.16.5.254

LAN sends to 192.168.5.254, but wireless to 172.16.5.254.
Does 192.168.5.254 and 172.16.5.254 have connection between each other?
Or it is just a mistake?
Last edited by nimnull22; 01-10-2010 at 10:50 AM.
 
Old 01-10-2010, 11:01 AM   #22
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
192.168.5.254 and 172.16.5.254 is joined by routing tables and is accessible. it is simply two interfaces of the router. Anyway I was wrong about saying that return packets has different source address. Now I have double checked packets through router and here they are:
Code:
Interface   Direction   Src. address         Dst. address
------------------------------------------------------------
wlan1         in        172.16.5.109:60042   192.168.5.6:22
ether2        out       192.168.5.254:60042  192.168.5.6:22
ether2        in        192.168.5.6:22       192.168.5.254:60042
wlan1         out       192.168.5.6:22       172.16.5.109:60042
So it means that SSH client "talks" directly to server and SSH server talks with its gateway, but anyway it is correct. So no I begin to think that this is WiFi and SSH issue mentioned in one of the bug lists rather than router problem. The same path of packets I have by using PuTTY, but it works like a charm. So now I want to shoot myself
 
Old 01-10-2010, 11:08 AM   #23
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
They can't talk directly AT ALL, they are located in different networks:
LAN
Network: 192.168.5.0/24

WiFi
Network: 172.16.5.0/20
 
Old 01-10-2010, 02:21 PM   #24
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
Yes, but here we talk about router. It has route tables and SRC NAT facility, so it is possible in my case. Look above where I posted about how packets go from one network to other through router.
 
Old 01-10-2010, 02:43 PM   #25
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Yes, but question is not "route tables and SRC NAT facility", question is CONFIGURATION.
You route has to have proper configuration to accept SSH traffic from both networks and send it to both directions.

And it seems to me that your route can't do all of it.
 
Old 01-10-2010, 03:57 PM   #26
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
Everything is not so complex as it seems. Here is the facts:

1. I can SSH to server and successfully login. If packet route would be wrong I would never authenticate
2. Everything works perfectly with the same conditions, but with PuTTY. This again means that routing of packets is ok.

What is not ok I don't know at all
 
Old 01-10-2010, 04:20 PM   #27
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Ok, may you right about you router.

So let's check gnome.
On gnome computer start tcpdump with:
Code:
tcpdump -n tcp port 22
Or even better:
Code:
tcpdump -n port 22

And monitor up to it hangs.

Send output please.
Last edited by nimnull22; 01-10-2010 at 04:21 PM.
 
Old 01-11-2010, 09:03 AM   #28
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
Hello,

Too much reading, but here it goes:
Code:
16:58:03.636401 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [S], seq 1959498773, win 5840, options [mss 1460,sackOK,TS val 175773 ecr 0,nop,wscale 6], length 0
16:58:03.638440 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [S.], seq 2319343147, ack 1959498774, win 5792, options [mss 1460,sackOK,TS val 165561 ecr 175773,nop,wscale 7], length 0
16:58:03.638474 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1, win 92, options [nop,nop,TS val 175773 ecr 165561], length 0
16:58:03.655180 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1:40, ack 1, win 46, options [nop,nop,TS val 165563 ecr 175773], length 39
16:58:03.655245 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 40, win 92, options [nop,nop,TS val 175778 ecr 165563], length 0
16:58:03.655499 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1:40, ack 40, win 92, options [nop,nop,TS val 175778 ecr 165563], length 39
16:58:03.657056 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [.], ack 40, win 46, options [nop,nop,TS val 165563 ecr 175778], length 0
16:58:03.657106 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 40:832, ack 40, win 92, options [nop,nop,TS val 175778 ecr 165563], length 792
16:58:03.658240 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [.], ack 832, win 58, options [nop,nop,TS val 165563 ecr 175778], length 0
16:58:03.659639 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 40:824, ack 832, win 58, options [nop,nop,TS val 165563 ecr 175778], length 784
16:58:03.664263 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 832:856, ack 824, win 116, options [nop,nop,TS val 175780 ecr 165563], length 24
16:58:03.683251 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 824:976, ack 856, win 58, options [nop,nop,TS val 165564 ecr 175780], length 152
16:58:03.689579 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 856:1000, ack 976, win 141, options [nop,nop,TS val 175786 ecr 165564], length 144
16:58:03.718219 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 976:1696, ack 1000, win 70, options [nop,nop,TS val 165569 ecr 175786], length 720
16:58:03.725970 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1000:1016, ack 1696, win 165, options [nop,nop,TS val 175795 ecr 165569], length 16
16:58:03.762459 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [.], ack 1016, win 70, options [nop,nop,TS val 165574 ecr 175795], length 0
16:58:03.762528 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1016:1064, ack 1696, win 165, options [nop,nop,TS val 175804 ecr 165574], length 48
16:58:03.763289 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [.], ack 1064, win 70, options [nop,nop,TS val 165574 ecr 175804], length 0
16:58:03.763782 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1696:1744, ack 1064, win 70, options [nop,nop,TS val 165574 ecr 175804], length 48
16:58:03.767397 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1064:1128, ack 1744, win 165, options [nop,nop,TS val 175806 ecr 165574], length 64
16:58:03.787447 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1744:1808, ack 1128, win 70, options [nop,nop,TS val 165575 ecr 175806], length 64
16:58:03.827004 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1808, win 165, options [nop,nop,TS val 175821 ecr 165575], length 0
16:58:07.903550 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1128:1272, ack 1808, win 165, options [nop,nop,TS val 176840 ecr 165575], length 144
16:58:07.951740 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1808:1840, ack 1272, win 83, options [nop,nop,TS val 165992 ecr 176840], length 32
16:58:07.951807 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1840, win 165, options [nop,nop,TS val 176852 ecr 165992], length 0
16:58:07.952407 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1272:1400, ack 1840, win 165, options [nop,nop,TS val 176852 ecr 165992], length 128
16:58:08.014273 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 165995 ecr 176852], length 48
16:58:08.015170 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 176868 ecr 165995], length 448
16:58:08.199030 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 166016 ecr 176852], length 48
16:58:08.199107 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1888, win 165, options [nop,nop,TS val 176914 ecr 166016,nop,nop,sack 1 {1840:1888}], length 0
16:58:08.234998 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 176923 ecr 166016], length 448
16:58:08.675008 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 177033 ecr 166016], length 448
16:58:08.676758 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 166058 ecr 176852], length 48
16:58:08.676798 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1888, win 165, options [nop,nop,TS val 177033 ecr 166058,nop,nop,sack 1 {1840:1888}], length 0
16:58:09.555010 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 177253 ecr 166058], length 448
16:58:09.556800 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 166142 ecr 176852], length 48
16:58:09.556841 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1888, win 165, options [nop,nop,TS val 177253 ecr 166142,nop,nop,sack 1 {1840:1888}], length 0
16:58:11.262167 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 166310 ecr 176852], length 48
16:58:11.262225 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1888, win 165, options [nop,nop,TS val 177679 ecr 166310,nop,nop,sack 1 {1840:1888}], length 0
16:58:11.314997 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 177693 ecr 166310], length 448
16:58:14.488585 IP 192.168.5.6.22 > 172.16.5.109.57353: Flags [P.], seq 1840:1888, ack 1400, win 95, options [nop,nop,TS val 166646 ecr 176852], length 48
16:58:14.488636 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [.], ack 1888, win 165, options [nop,nop,TS val 178486 ecr 166646,nop,nop,sack 1 {1840:1888}], length 0
16:58:14.835009 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [P.], seq 1400:1848, ack 1888, win 165, options [nop,nop,TS val 178573 ecr 166646], length 448
16:58:19.241036 IP 172.16.5.109.57353 > 192.168.5.6.22: Flags [F.], seq 1848, ack 1888, win 165, options [nop,nop,TS val 179674 ecr 166646], length 0
16:58:19.659412 IP 192.168.5.6.22 > 172.16.5.109.57299: Flags [P.], seq 812802433:812802481, ack 449526485, win 95, options [nop,nop,TS val 167145 ecr 152898], length 48
16:58:19.659487 IP 172.16.5.109.57299 > 192.168.5.6.22: Flags [.], ack 48, win 165, options [nop,nop,TS val 179779 ecr 167145,nop,nop,sack 1 {0:48}], length 0
The last 4 or 5 packets where sent after successful login and gnome was hung. If I do not close gnome terminal then it keeps sending the same packets.
Also I've checked about Broadcom WiFi and SSH bug mentioned in some link and made 'blacklist wl', but it didn;t worked. Everything works the same.
 
Old 01-11-2010, 10:36 AM   #29
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
172.16.5.109.57353 > 192.168.5.6.22
172.16.5.109.57353 > 192.168.5.6.22:
192.168.5.6.22 > 172.16.5.109.57299:
172.16.5.109.57299 > 192.168.5.6.22:

Look, your server changed a port.
You start session from 57353, but later server send packet to 57299 (192.168.5.6.22 > 172.16.5.109.57299)
I do not think that it is good, that is probably why Gnome terminal hangs.

May be others can help us.

You can do the same monitor for Putty
 
Old 01-11-2010, 10:58 AM   #30
alpha_lt
Member
 
Registered: Jul 2009
Location: Denmark
Distribution: Fedora
Posts: 95

Original Poster
Rep: Reputation: 15
WOW ! I've missed that. Thanks. Now I'm running to check PuTTY
 
  


Reply
Page 2 of 4 1 2 34



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSH Problem with DI-614+ router darkjeffro Linux - Networking 12 05-16-2007 05:08 AM
ssh problem with dhcp router jewelshaw Linux - Networking 4 09-13-2006 04:34 AM
ssh, confirmed router problem Ossar Linux - Networking 2 10-09-2004 10:00 AM
SSH from Internet to RH9 through xavi 7028r router problem xtra Linux - Networking 6 06-29-2004 05:10 AM
dsl router + NAT + ssh = problem valleyman Linux - Networking 5 12-10-2003 09:19 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 08:56 PM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration