[Discussion] ssh được nhưng scp bị treo ở 100% |
24/05/2011 16:41:11 (+0700) | #1 | 237778 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
Chào cả nhà,
Hôm nay mình gặp ca này "ngộ" quá: ssh ok, nhưng scp thử một file dung lượng khoảng vài chục KB thì nó cứ treo ở 100%, và mình phải Ctrl + C.
Code:
$ scp -vv header.pcap <a href="mailto:user@192.168.6.x">user@192.168.6.x</a>:~
Executing: program /usr/bin/ssh host 192.168.6.x, user user, command scp -v -t ~
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.6.x [192.168.6.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 118/256
debug2: bits set: 491/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.6.x' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:4
debug2: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/identity ((nil))
debug2: key: /home/user/.ssh/id_rsa (0x2aca4c004c20)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: SHA1 fp 99:e8:e7:1a:cd:2b:8d:78:63:2a:51:92:e7:66:3b:1b:03:24:87:f8
debug1: Trying private key: /home/user/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
<a href="mailto:user@192.168.6.x">user@192.168.6.x</a>'s password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t ~
debug2: channel 0: request exec confirm 0
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
Sending file modes: C0644 2441 header.pcap
debug2: channel 0: rcvd ext data x
Sink: C0644 2441 header.pcap
debug2: channel 0: written x to efd 6
header.pcap 100% 2441 2.4KB/s 00:00
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Killed by signal 2.
Check dung lượng file này trên server thì vẫn là 0 byte. Thử với account khác và ngay cả root cũng không được.
Hiện mình đã biết được nguyên nhân nhưng muốn mời mọi người cùng giải quyết ca này. Các bạn cần thông tin gì thêm thì cứ cho mình biết nhé. |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 08:50:46 (+0700) | #2 | 237828 |
|
zeno
Elite Member
|
0 |
|
|
Joined: 20/07/2004 03:57:09
Messages: 124
Location: HVA
Offline
|
|
có thông tin messages log không anh? |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 09:49:42 (+0700) | #3 | 237832 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
Bạn muốn log của server à? Nếu set LogLevel của ssh server thành DEBUG thì thông tin trong /var/log/secure cũng chỉ tương tự như ở client thôi:
Code:
debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
debug1: Forked child 2745.
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.5.y port 34245
debug1: Client protocol version 2.0; client software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user xx service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "xx"
debug1: PAM: setting PAM_RHOST to "192.168.5.y"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user xx service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 505/507 (e=0/0)
debug1: trying public key file /home/xx/.ssh/authorized_keys
debug1: matching key found: file /home/xx/.ssh/authorized_keys, line 1
Found matching RSA key: 63:fb:c4:5b:79:78:a7:70:9e:d7:1e:6c:11:4a:80:41
debug1: restore_uid: 0/0
Postponed publickey for xx from 192.168.5.y port 34245 ssh2
debug1: userauth-request for user xx service ssh-connection method password
debug1: attempt 2 failures 1
debug1: PAM: password authentication accepted for xx
debug1: do_pam_account: called
Accepted password for xx from 192.168.5.y port 34245 ssh2
debug1: monitor_child_preauth: xx has been authenticated by privileged process
debug1: temporarily_use_uid: 505/507 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: PAM: establishing credentials
pam_unix(sshd:session): session opened for user xx by (uid=0)
debug1: PAM: reinitializing credentials
debug1: permanently_set_uid: 505/507
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request exec reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Hay bạn muốn log của cái gì, như nào, cho mình biết nhu cầu cụ thể, mình sẽ gửi.
PS: cả client và server đều dùng CentOS 5.5, OpenSSH_4.3p2. |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 10:44:35 (+0700) | #4 | 237836 |
|
zeno
Elite Member
|
0 |
|
|
Joined: 20/07/2004 03:57:09
Messages: 124
Location: HVA
Offline
|
|
Ý e là e muốn xem /var/log/messages chứ không phải /var/log/secure. |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 10:55:12 (+0700) | #5 | 237838 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
À, vậy thì không có gì bạn à vì mặc định log của ssh, scp, sftp, ... bắn vào /var/log/secure. |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 11:15:35 (+0700) | #6 | 237840 |
van_security
Member
|
0 |
|
|
Joined: 08/10/2009 14:02:39
Messages: 159
Offline
|
|
Chà, ca này chắc hay hà nhe. Mình chờ kết quả ... hehe |
|
Bệnh Khàn Tiếng: Tư Vấn về Chẩn đoán - điều trị Miễn Phí
http://trikhantieng.blogspot.com/
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 11:43:18 (+0700) | #7 | 237841 |
|
thangcuti01
Member
|
0 |
|
|
Joined: 07/04/2008 15:23:41
Messages: 29
Offline
|
|
Mình cũng đã bị tình trạng tương tự. Tuy nhiên, mình thay cách scp bằng wget của CentOS. Như vậy có đc xem là cách giải quyết ko?
Thứ 2: scp ở quyền root hay user đều bị treo 100%, nhưng nếu dùng 2 terminal cũng giả quyết đc, nên log của bạn minh thấy nó đều phản hồi tốt. Mình muốn hỏi thêm là file bạn copy chỉ là file text hay 1 file kc để mình có thể check lại phản hồi của mình cos đúng hay ko?
Thanks |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 11:53:10 (+0700) | #8 | 237842 |
|
tranhuuphuoc
Moderator
|
Joined: 05/09/2004 06:08:09
Messages: 865
Location: Lầu Xanh
Offline
|
|
Hi quanta,
Em thử một tập tin nào đó với dung lượng 100MB thử xem, theo anh biết thì dùng scp nó không hoạt động tốt với tập tin với dung lượng nhỏ, dùng rsync sẽ đáp ứng nhu cầu chăng !?
|
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 13:00:36 (+0700) | #9 | 237844 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
À, mình nói thêm để các bạn tiện suy luận nhé: máy client có 2 interface, nếu từ server, mình dùng WAN thì OK, còn LAN thì bị tình trạng trên nhé.
thangcuti01 wrote:
Mình cũng đã bị tình trạng tương tự. Tuy nhiên, mình thay cách scp bằng wget của CentOS. Như vậy có đc xem là cách giải quyết ko?
wget cũng không được bạn à: "HTTP request sent, awaiting response".
thangcuti01 wrote:
Thứ 2: scp ở quyền root hay user đều bị treo 100%, nhưng nếu dùng 2 terminal cũng giả quyết đc, nên log của bạn minh thấy nó đều phản hồi tốt. Mình muốn hỏi thêm là file bạn copy chỉ là file text hay 1 file kc để mình có thể check lại phản hồi của mình cos đúng hay ko?
Thanks
Bất kỳ file gì bạn à. Mình dùng `dd if=/dev/zero bs=1 count=xx of=xx` để tạo file có dung lượng theo ý muốn.
tranhuuphuoc wrote:
Hi quanta,
Em thử một tập tin nào đó với dung lượng 100MB thử xem,
Câu trả lời là không được anh à.
tranhuuphuoc wrote:
theo anh biết thì dùng scp nó không hoạt động tốt với tập tin với dung lượng nhỏ,
Anh đọc thông tin này ở đâu vậy? Em không nghĩ thế.
tranhuuphuoc wrote:
dùng rsync sẽ đáp ứng nhu cầu chăng !?
Vẫn bị treo anh nhé:
Code:
$ rsync -avvv -e ssh header.pcap <a href="mailto:quanta@192.168.6.x">quanta@192.168.6.x</a>:~
opening connection using: ssh -l quanta 192.168.6.x rsync --server -vvvlogDtpre.isf . "~"
<a href="mailto:quanta@192.168.6.xx">quanta@192.168.6.xx</a>'s password:
building file list ...
[sender] make_file(header.pcap,*,0)
done
send_file_list done
send_files starting
server_recv(2) starting pid=1034
recv_file_name(header.pcap)
received 1 names
recv_file_list done
get_local_name count=1 /home/quanta
recv_files(1) starting
generator starting pid=1034 count=1
delta-transmission enabled
recv_generator(header.pcap,0)
generating and sending sums for 0
send_files(0, header.pcap)
send_files mapped header.pcap of size 2441
calling match_sums header.pcap
header.pcap
sending file_sum
false_alarms=0 hash_hits=0 matches=0
sender finished header.pcap
generate_files phase=1
send_files phase=1
Killed by signal 2.
rsync error: unexplained error (code 255) at rsync.c(543) [sender=3.0.7]
[sender] _exit_cleanup(code=20, file=rsync.c, line=543): about to call exit(255)
|
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 13:12:14 (+0700) | #10 | 237846 |
lmthongtnb
Member
|
0 |
|
|
Joined: 19/05/2011 22:25:48
Messages: 11
Offline
|
|
Có con IDS nào trong LAN không bạn? Tình trạng này suất hiện trong cùng subnet hay khác vậy bạn? |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 13:25:09 (+0700) | #11 | 237851 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
lmthongtnb wrote:
Có con IDS nào trong LAN không bạn?
Cái này thì mình không chắc.
lmthongtnb wrote:
Tình trạng này suất hiện trong cùng subnet hay khác vậy bạn?
Khác subnet bạn à.
PS: các bạn có thể đưa ra các câu hỏi và mình sẽ trả lời là copy được hay không. |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 13:41:09 (+0700) | #12 | 237852 |
|
zeno
Elite Member
|
0 |
|
|
Joined: 20/07/2004 03:57:09
Messages: 124
Location: HVA
Offline
|
|
Code:
debug1: Authentication succeeded (password).
Nhìn vào đoạn log trên thì phần authentication đã ok. Việc không đẩy được file lên server (bị treo khi đang 100%). Liệu có firewall chặn callback request đến client cho việc close sesion không nhỉ? hay có 1 cái gi đó protect I/O không nhỉ? chưa nghĩ ra |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 15:27:39 (+0700) | #13 | 237859 |
|
secmask
Elite Member
|
0 |
|
|
Joined: 29/10/2004 13:52:24
Messages: 553
Location: graveyard
Offline
|
|
Em oánh Google ra được cái này http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2010-06/msg00012.html
Tóm tắt lại là do 2 máy đã gửi qua nhau packet có kích thước > MTU dẫn đến packet bị drop, việc này lại có lý do trước đó là quá trình discovery giá trị MTU trên "PATH"(con đường kết nối 2 host, bao gồm các router .. trung gian) không thành công. Thử một vài cách như này:
1. Giảm MTU đến khi hết lỗi.
2. Tìm xem thằng nào chặn ICMP discovery PMTU thì thiết đặt lại cho phép ICMP discovery PMTU. |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
25/05/2011 22:25:17 (+0700) | #14 | 237880 |
mR.Bi
Member
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
Có vẻ như secmask trả lời đúng rồi. Cám ơn bạn vì cái link |
|
All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children" |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
26/05/2011 00:49:45 (+0700) | #15 | 237890 |
|
St Konqueror
Member
|
0 |
|
|
Joined: 08/12/2007 00:47:39
Messages: 229
Offline
|
|
secmask wrote:
Em oánh Google ra được cái này http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2010-06/msg00012.html
Tóm tắt lại là do 2 máy đã gửi qua nhau packet có kích thước > MTU dẫn đến packet bị drop, việc này lại có lý do trước đó là quá trình discovery giá trị MTU trên "PATH"(con đường kết nối 2 host, bao gồm các router .. trung gian) không thành công. Thử một vài cách như này:
1. Giảm MTU đến khi hết lỗi.
2. Tìm xem thằng nào chặn ICMP discovery PMTU thì thiết đặt lại cho phép ICMP discovery PMTU.
Hehe, cái này có vẻ lí thú! Mình đang thử tái tạo lại xem có được không.
|
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
26/05/2011 07:00:30 (+0700) | #16 | 237894 |
|
tranhuuphuoc
Moderator
|
Joined: 05/09/2004 06:08:09
Messages: 865
Location: Lầu Xanh
Offline
|
|
Theo như anh nghĩ trường hợp MTU bị sai rất ít, vì nếu như MTU được thiết lập ở 2 PC có sai xót, không thống nhất ở 2 PC ví dụ cụ thể như trường hợp PPPoE, khi router của bên em nối đến ISP mà MTU của em được thiết lập sai xót với switch layer2 của ISP thì điều này sẽ xãy ra, như em nói thì em dùng được ssh nhưng đến khi dùng scp thì bị treo
http://www.netheaven.com/pmtu.html |
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
27/05/2011 09:31:28 (+0700) | #17 | 237978 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
Không phải là sai anh à, mà có thể muốn có performance tốt hơn nên set MTU to hơn, nhưng lại quên mất rằng cần có sự hỗ trợ từ 2 phía (network hardware + NIC).
Đố các bạn biết có cách nào xác định được MTU của hop kế tiếp không? |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
28/05/2011 10:45:36 (+0700) | #18 | 238068 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
Mặc dù Intel nói có, nhưng trên thực tế, mình thấy NIC trên cả 2 con này: 80003ES2LAN và 82572EI đều có vấn đề (không làm việc) với jumbo frames.
Mà ở đây: http://ark.intel.com/Product.aspx?id=20719, lại nói không support là sao nhỉ? |
|
Let's build on a great foundation! |
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
28/05/2011 13:43:48 (+0700) | #19 | 238082 |
myquartz
Member
|
0 |
|
|
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
|
|
Truyền khác subnet thì có router tham gia vào rồi. Có thể có rắc rối gì đó.
quanta có thể gửi kết quả của lệnh sau (dĩ nhiên là chạy lệnh này trước khi scp và lấy kết quả sau khi stop scp) được không:
tcpdump -i ethx -nn -c 1000 ip host 192.168.6.x or icmp
Trong đó ethx là interface nối mạng LAN dự định truyền, 192.168.6.x là IP của server. Xin chỉ có 1 phiên ssh lên server để dữ liệu đỡ bị loạn.
|
|
|
|
|
[Discussion] ssh được nhưng scp bị treo ở 100% |
28/05/2011 15:58:48 (+0700) | #20 | 238093 |
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
@myquartz: của bạn đây: http://www.mediafire.com/?17891vdbmvq81al (đã dùng editcap để loại bỏ những packets không cần thiết).
Mình còn một điểm thắc mắc nữa: 5.199 đi đến 6.29 qua con router 5.1. Mình thử ping đến router này với size khoảng 1979 bytes và không set DF nhưng lại không thấy nó reply là sao nhỉ?
Code:
ping -c 4 -M dont -s 1971 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 1971(1999) bytes of data.
--- 192.168.5.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
09:30:37.965363 IP (tos 0x0, ttl 64, id 58445, offset 0, flags [none], proto: ICMP (1), length: 1999) 199.localdomain > 192.168.5.1: ICMP echo request, id 45435, seq 1, length 1979
09:30:38.966006 IP (tos 0x0, ttl 64, id 58446, offset 0, flags [none], proto: ICMP (1), length: 1999) 199.localdomain > 192.168.5.1: ICMP echo request, id 45435, seq 2, length 1979
09:30:39.966019 IP (tos 0x0, ttl 64, id 58447, offset 0, flags [none], proto: ICMP (1), length: 1999) 199.localdomain > 192.168.5.1: ICMP echo request, id 45435, seq 3, length 1979
09:30:40.965033 IP (tos 0x0, ttl 64, id 58448, offset 0, flags [none], proto: ICMP (1), length: 1999) 199.localdomain > 192.168.5.1: ICMP echo request, id 45435, seq 4, length 1979
|
|
Let's build on a great foundation! |
|
|
|
|
|
|
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|