Search Results

Search found 3489 results on 140 pages for 'tcp'.

Page 2/140 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Does TCP actually define 'TCP server' and 'TCP clients'? [closed]

    - by mjn
    In the Wikipedia article, TCP communication is explained using the terms 'client' and 'server'. It also uses the word 'peers'. But TCP actually does not define "TCP clients" and "TCP servers" - In the RFC 675 document (SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM), the word "client" never appears. The RFC explains that TCP is used to connect processes over ports (sockets), and that 'A pair of sockets form a CONNECTION which can be used to carry data in either direction [i.e. full duplex]. Calling the originating party the "client" seems to be common practice. But this client/server communication model is not always applicable to TCP communication. For example take peer-to-peer networks. Calling all processes which open a socket (and wait for incoming connections from peers) "TCP servers", sounds wrong to me. I would not call my uncle's telephone device a "Telephony server" if I dial his phone number and he picks up.

    Read the article

  • TCP/IP & throughput between FreeNAS (BSD) server & other LAN machines

    - by Tim Dickerson
    I have got a question for someone that knows BSD a bit better than me that are in regards to my LAN setup at home/work here outside Chicago. I can't seem to fully optimize my network's (LAN) thoughput via my FreeNAS (BSD based) file server. It runs with the latest FreeBSD release which is modified to support several protocols for file transfers and more. Every machine that is behind my Smoothwall (Linux based) router is on the usual 192.168.0.x subnet and for most part works just fine. Behind the Smoothwall box, all machines are connected to a GB HP unmanaged switch. I host a large WISP here and have an OC-3 connection here at home/work and have no issues with downloading/uploading from/to the 'net'. My problem is with throughput. When I try and transfer large files...really any for that matter..between any of the machines to/and from the FreeNAS server via FTP, the max throughput I can achieve say between a Win 7 or a Linux box is ~65Mbit/sec. All machines are running Intel Pro 1000 GB NIC's and all cable is CAT6. Each is set to 'auto negotiation' and each shows 1500 MTU Full Duplex @1GB so I know the hardware is okay. I have not adjusted the MTU on any machine as I understand it to be pointless unless certain configurations are used (I assume I am not one of those). My settings for the FreeNAS machine are the following: # FreeNAS /etc/sysctl.conf - pertinent settings shown kern.ipc.maxsockbuf=262144 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_inc=16384 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.hostcache.expire=1 From what I can tell, that looks to be a somewhat optimized profile for a typical BSD machine acting as a server for a LAN. I might be wrong and just wanted to find out from someone that knows BSD better than I do if indeed that is ok or if something is out of tune or what. Are there other ways I would find better for P2P file transfers? I honestly do not know what I SHOULD be looking for with respect to throughput between the NAS box and another client when xferring files via FTP, but I am told that what I get on average (40-70MB/sec) is too low for what it could be. I have thought about adding another NIC in the FreeNAS box as well as the Win7 machine and use a X-over cable via a static route, but wanted to check with someone first to see if that might be worth it or not. I don't know if doing that would bypass the HP GB switch and allow for a machine to machine xfer anyways. The FTP client I use is: Filezilla and have tried both active and passive modes with no real gain over each other. The NAS box runs ProFTPD.

    Read the article

  • net.tcp Listener Adapter and net.tcp Port Sharing Service not starting on reboot

    - by Peter K.
    I am using the net.tcp protocol for various web services. When I reboot my Windows 7 Ultimate (64-bit) macbook pro, the service never restarts automatically, even though that is how they are set: The only relevant events I can see are in the System Event Log: Error 6/9/2011 19:47 Service Control Manager 7001 None The Net.Tcp Listener Adapter service depends on the Net.Tcp Port Sharing Service service which failed to start because of the following error: The service did not respond to the start or control request in a timely fashion." Error 6/9/2011 19:47 Service Control Manager 7000 None The Net.Tcp Port Sharing Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion." Error 6/9/2011 19:47 Service Control Manager 7009 None A timeout was reached (30000 milliseconds) while waiting for the Net.Tcp Port Sharing Service service to connect. This post suggests that it's something else blocking the port (in the post it's SCCM 2007 R3 Client which I don't use). What else could be the problem? If it's something else blocking the port, how do I figure out what? When I manually start the services, they start correctly. Dependencies are: Net.Tcp Port Sharing Service Net.Tcp Listener Adapter Still no luck, but I think the problem might be that my network connection takes too long to come up. I put in a custom view of the event log, and found these items: The first in the series says: A timeout was reached (30000 milliseconds) while waiting for the Net.Tcp Port Sharing Service service to connect.

    Read the article

  • queues in linux tcp stack

    - by poly
    I'm trying to understand the Linux kernel tcp_input/tcp_output and I'm lost. who create/control the queues, if the input is a thread and the out is another thread, who owns the queues in the TCP stack as there are many, I already asked about the retransmission queue before in this site, so the question would be who create this queue I know that this queue holds all sent packet to be retransmitted/deleted after ack later

    Read the article

  • What would cause my SendMail server not to acknowledge receiving a TCP Sequence?

    - by Mike B
    My TCP/IP Stack knowledge is a little rusty so please bear with me.... I have a CentOS 5.7 server with SendMail and am having seeing intermittent timeout issues sending email (particularly larger email) to other remote domains. It doesn't happen with all attachments or recipient domains. Just some. After some extended troubleshooting, I think I've narrowed it down to TCP Sequences not being acknowledged. Here's a breakdown of the TCP session from a packet capture I collected directly on my MTA (fooMTA): Packet 1 - 11: Standard TCP handshake followed by initial SMTP conversation. No errors. Packet #12 Recipient MTA: TCP sequence 231. Ack 91. Packet #13 FooMTA: TCP sequence 91. Ack 305. Packet #14 FooMTA: TCP sequence 1115. Ack 305. Packet #15 Recipient MTA: TCP sequence 305. Ack 2495. Packet #16 FooMTA: TCP sequence 2495. Ack 305. Packet #17 FooMTA: TCP sequence 5255. Ack 305. Packet #18: Recipient MTA: TCP sequence 305. Ack 5255. Packet #19: FooMTA: TCP sequence 6635. Ack 305. Packet #20: FooMTA: TCP sequence 8015. Ack 305. Packet #21: Recipient MTA: TCP Sequence 305. Ack 8015. Packet #22: FooMTA: TCP Sequence 10775. Ack 305. Packet #23: FooMTA: TCP Sequence 13535. Ack 305. Packet #24: Recipient MTA: TCP sequence 305. Ack 10775 Packet #25: FooMTA: TCP Sequence 14915. Ack 305 It keeps going like this with my server still thinking it hasn’t received sequence 305… in response the remote side eventually retransmits its prior data thinking that it never arrived. Eventually the gap gets so large that no new data is sent and the remote MTA keeps retransmitting old stuff. This contributes to an exponential backoff and eventually the remote side gives up. What’s strange to me is that I see the “missing” TCP sequence (305 in this case) arriving back to my server (via a packet capture collected directly from fooMTA) So I don’t get why my server keeps asking for it. Could this be firewall related? What would be the next step in troubleshooting?

    Read the article

  • How to get Passive FTP Working Through an Iptables Firewall?

    - by user1133248
    I have an iptables firewall running on a Fedora Linux server that is basically being used as a firewall router and OpenVPN server. That's it. We have been using the same iptables firewall code for YEARS. I did make some changes on 21 December to re-route a mySQL port, but given what has happened I've completely backed those changes out. Sometime after those changes were made and backed out passive FTP, served from a vsftpd process, stopped working. We use a passive ftp client to FLING (that's the name of the ftp client running under Windows! :-) ) images from our remote telescopes to our server. I believe it is something in the firewall code because I can drop the firewall and the FTP file transfer (and connecting to the ftp site with Internet Explorer to see the file list) works. When I raise the iptables firewall, it stops working. Again, this is code that we'd been using for years. However, I felt that maybe there was something I missed, so we had a .bak file from 2009 that I used. Same behavior, passive ftp does not work. So, I went and rebuilt the firewall code line by line to see what line was causing the problem. Everything worked until I put the line -A FORWARD -j DROP in very near the end. Of course, if I am correct, this is the line that basically "turns on" the firewall, saying drop everything except for the exceptions I've made above. However, this line has been in the iptables code probably since 2003. So, I'm at the end of my rope, and I still can't figure out why this has stopped working. I guess I need an expert on iptables configuration. Here is the iptables code (from iptables-save) with comments. # Generated by iptables-save v1.3.8 on Thu Jan 5 18:36:25 2012 *nat # One of the things that I remain ignorant about is what these following three lines # do in both the nat tables (which we're not using on this machine) and the following # filter table. I don't know what the numbers are, but I'm ASSUMING they're port # ranges. # :PREROUTING ACCEPT [7435:551429] :POSTROUTING ACCEPT [6097:354458] :OUTPUT ACCEPT [5:451] COMMIT # Completed on Thu Jan 5 18:36:25 2012 # Generated by iptables-save v1.3.8 on Thu Jan 5 18:36:25 2012 *filter :INPUT ACCEPT [10423:1046501] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [15184:16948770] # The following line is for my OpenVPN configuration. -A INPUT -i tun+ -j ACCEPT # In researching this on the Internet I found some iptables code that was supposed to # open the needed ports up. I never needed this before this week, but since passive FTP # was no longer working, I decided to put the code in. The next three lines are part of # that code. -A INPUT -p tcp -m tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --sport 1024:65535 --dport 20 -m state --state ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT # Another line for the OpenVPN configuration. I don't know why the iptables-save mixed # the lines up. -A FORWARD -i tun+ -j ACCEPT # Various forwards for all our services -A FORWARD -s 65.118.148.197 -p tcp -m tcp --dport 3307 -j ACCEPT -A FORWARD -d 65.118.148.197 -p tcp -m tcp --dport 3307 -j ACCEPT -A FORWARD -s 65.118.148.197 -p tcp -m tcp --dport 3306 -j ACCEPT -A FORWARD -d 65.118.148.197 -p tcp -m tcp --dport 3306 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 21 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 21 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 20 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 20 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 7191 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 7191 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 46000:46999 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 46000:46999 -j ACCEPT -A FORWARD -s 65.118.148.0/255.255.255.0 -j ACCEPT -A FORWARD -d 65.118.148.196 -p udp -m udp --dport 53 -j ACCEPT -A FORWARD -s 65.118.148.196 -p udp -m udp --dport 53 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 53 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 53 -j ACCEPT -A FORWARD -d 65.118.148.196 -p udp -m udp --dport 25 -j ACCEPT -A FORWARD -s 65.118.148.196 -p udp -m udp --dport 25 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 42 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 42 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 25 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 25 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -d 65.118.148.204 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -s 65.118.148.204 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -d 65.118.148.196 -p tcp -m tcp --dport 6667 -j ACCEPT -A FORWARD -s 65.118.148.196 -p tcp -m tcp --dport 6667 -j ACCEPT -A FORWARD -s 65.96.214.242 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -s 192.68.148.66 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # "The line" that causes passive ftp to stop working. Insofar as I can tell, everything # else seems to work - ssh, telnet, mysql, httpd. -A FORWARD -j DROP -A FORWARD -p icmp -j ACCEPT # The following code is again part of my attempt to put in code that would cause passive # ftp to work. I don't know why iptables-save scattered it about like this. -A OUTPUT -p tcp -m tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 20 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT COMMIT # Completed on Thu Jan 5 18:36:25 2012 So, with all that prelude, my basic question is: How can I get passive ftp to work behind an iptables firewall? As you can see, I've tried to get it working (again) and tried to do some research on the issue, but have come up...short. Any answers would be appreciated by both me and various variable star astronomers around the world! THANKS! -Richard "Doc" Kinne, American Assoc. of Variable Star Observers, [email protected]

    Read the article

  • Does data size in TCP/UDP make a difference on transmission time

    - by liortal
    While discussing the development of a network component for our game engine, a member of our team suggested that transmitting either 500 bytes or 1k of data using UDP makes no difference from performance perspective of the system (the time it takes to transmit the data). He actually said that as long as you don't cross the MTU size, the size of the transmitted data doesn't really matter as it's all the same. Is that true for UDP? what about TCP? That sounds just plain wrong to me, but i am not a network expert. *I've been reading about other companies' game networking architectures, and it seems they're all trying to keep transmitted data to a minimum, making my colleague's claims seem even more unreasonable.

    Read the article

  • HTTP, TCP, UDP and connectionless

    - by user132199
    I am a bit confused with HTTP lately. Some facts are that TCP can operate connection orientated or connectionless this I understand. TCP though is connection-oriented while UDP is connectionless which is used when the message itself can be fit into a single message. Question: If HTTP uses TCP, and TCP provides reliable conjnections for multiple message excahnge, and HTTP is said to be connectionless then how is this possible? TCP is connection-oriented? So how is HTTP connectionless????

    Read the article

  • Difference between tcp recv buffer and tcp receive window size?

    - by pradeepchhetri
    The command shows the tcp receive buffer size in bytes. $ cat /proc/sys/net/ipv4/tcp_rmem 4096 87380 4001344 where the three values signifies the min, default and max values respectively. Then I tried to find the tcp window size using tcpdump command. $ sudo tcpdump -n -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80 and host google.com' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:15:41.465037 IP 172.16.31.141.51614 > 74.125.236.73.80: Flags [S], seq 3661804272, win 14600, options [mss 1460,sackOK,TS val 4452053 ecr 0,nop,wscale 6], length 0 I got the window size to be 14600 which is 10 times the size of MSS. Can anyone please tell me the relationship between the two.

    Read the article

  • Shrinking Windows Size to 0 on Cisco ASA

    - by Brent
    Having an issue with any large file transfer that crosses our Cisco ASA unit come to an eventual pause. Setup Test1: Server A, FileZilla Client <- 1GBPS - Cisco ASA <- 1 GBPS - Server B, FileZilla Server TCP Window size on large transfers will drop to 0 after around 30 seconds of a large file transfer. RDP session then becomes unresponsive for a minute or two and then is sporadic. After a minute or two, the FTP transfer resumes, but at 1-2 MB/s. When the FTP transfer is over, the responsiveness of the RDP session returns to normal. Test2: Server C in same network as Server B, FileZilla Client <- local network - Server B, FileZilla Server File will transfer at 30+ MB/s. Details ASA: 5520 running 8.3(1) with ASDM 6.3(1) Windows: Server 2003 R2 SP2 with latest patches Server: VMs running on HP C3000 blade chasis FileZilla: 3.3.5.1, latest stable build Transfer: 20 GB SQL .BAK file Protocol: Active FTP over tcp/20, tcp/21 Switches: Cisco Small Business 2048 Gigabit running latest 2.0.0.8 VMware: 4.1 HP: Flex-10 3.15, latest version Notes All servers are VMs. Thoughts Pretty sure the ASA is at fault since a transfer between VMs on the same network will not show a shrinking Window size. Our ASA is pretty vanilla. No major changes made to any of the settings. It has a bunch of NAT and ACLs. Wireshark Sample No. Time Source Destination Protocol Info 234905 73.916986 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131981791 Win=65535 Len=0 234906 73.917220 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234907 73.917224 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234908 73.917231 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131984551 Win=64155 Len=0 234909 73.917463 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234910 73.917467 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234911 73.917469 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234912 73.917476 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131988691 Win=60015 Len=0 234913 73.917706 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234914 73.917710 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234915 73.917715 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131991451 Win=57255 Len=0 234916 73.917949 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234917 73.917953 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234918 73.917958 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131994211 Win=54495 Len=0 234919 73.918193 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234920 73.918197 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234921 73.918202 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131996971 Win=51735 Len=0 234922 73.918435 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234923 73.918440 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234924 73.918445 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=131999731 Win=48975 Len=0 234925 73.918679 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234926 73.918684 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234927 73.918689 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132002491 Win=46215 Len=0 234928 73.918922 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234929 73.918927 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234930 73.918932 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132005251 Win=43455 Len=0 234931 73.919165 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234932 73.919169 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234933 73.919174 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132008011 Win=40695 Len=0 234934 73.919408 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234935 73.919413 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234936 73.919418 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132010771 Win=37935 Len=0 234937 73.919652 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234938 73.919656 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234939 73.919661 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132013531 Win=35175 Len=0 234940 73.919895 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234941 73.919899 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234942 73.919904 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132016291 Win=32415 Len=0 234943 73.920138 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234944 73.920142 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234945 73.920147 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132019051 Win=29655 Len=0 234946 73.920381 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234947 73.920386 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234948 73.920391 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132021811 Win=26895 Len=0 234949 73.920625 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234950 73.920629 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234951 73.920632 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234952 73.920638 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132025951 Win=22755 Len=0 234953 73.920868 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234954 73.920871 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234955 73.920876 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132028711 Win=19995 Len=0 234956 73.921111 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234957 73.921115 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234958 73.921120 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132031471 Win=17235 Len=0 234959 73.921356 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234960 73.921362 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234961 73.921370 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132034231 Win=14475 Len=0 234962 73.921598 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234963 73.921606 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234964 73.921613 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132036991 Win=11715 Len=0 234965 73.921841 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234966 73.921848 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234967 73.921855 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132039751 Win=8955 Len=0 234968 73.922085 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234969 73.922092 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234970 73.922099 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132042511 Win=6195 Len=0 234971 73.922328 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234972 73.922335 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234973 73.922342 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132045271 Win=3435 Len=0 234974 73.922571 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234975 73.922579 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 1380 bytes 234976 73.922586 1.1.1.1 2.2.2.2 TCP ftp-data ivecon-port [ACK] Seq=1 Ack=132048031 Win=675 Len=0 234981 75.866453 2.2.2.2 1.1.1.1 FTP-DATA FTP Data: 675 bytes 234985 76.020168 1.1.1.1 2.2.2.2 TCP [TCP ZeroWindow] ftp-data ivecon-port [ACK] Seq=1 Ack=132048706 Win=0 Len=0 234989 76.771633 2.2.2.2 1.1.1.1 TCP [TCP ZeroWindowProbe] ivecon-port ftp-data [ACK] Seq=132048706 Ack=1 Win=65535 Len=1 234990 76.771648 1.1.1.1 2.2.2.2 TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] ftp-data ivecon-port [ACK] Seq=1 Ack=132048706 Win=0 Len=0 234997 78.279701 2.2.2.2 1.1.1.1 TCP [TCP ZeroWindowProbe] ivecon-port ftp-data [ACK] Seq=132048706 Ack=1 Win=65535 Len=1 234998 78.279714 1.1.1.1 2.2.2.2 TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] ftp-data ivecon-port [ACK] Seq=1 Ack=132048706 Win=0 Len=0

    Read the article

  • Tcp Port Open by Unknown Service

    - by Singularity
    Running openSUSE 11.2 x86_64. Here's what a nmap of my IP provides: PORT STATE SERVICE 23/tcp open telnet 80/tcp open http 2800/tcp open unknown 8008/tcp open http I would like to know How to view What service is causing Port 2800 to be opened? A few search engine results led me to believe that it is supposedly a port opened by a Trojan called "Theef". If it is indeed a Trojan, what can be done to weed it out? Is my desktop's security compromised?

    Read the article

  • why dstat failed with --tcp option?

    - by hugemeow
    why --tcp option failed? should i install some package? if yes, which package i should install? this question is not the same as http://stackoverflow.com/questions/10475991/tcp-sockets-double-messages dstat --tcp Module tcp has problems. (Cannot open file /proc/net/tcp6.) None of the stats you selected are available. what is the problem with module tcp, how to find the problem? what i should do in order to fix this issue?

    Read the article

  • TCP Handshake and port numbers

    - by Guido
    (I have a question about the TCP handshake and how port numbers are assigned, if this does not belong here, let me know.) Hi, I'm studying TCP/IP from the book "Internetworking with TCP/IP" by Douglas Comer. In the TCP chapter it mentions that TCP defines an "endpoint" as a pair (IP address, port number), and a connection is defined by two endpoints. This has a few implications, such as, a local TCP port could be in several connections at once, as long as there are no two from the same IP and the same remote port. This also means that the amount of established connections is almost limitless (2^16 for every IPv4 address. 2^48 in total). Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use, so the communication can happen and the listener socket remains free. This was also my belief before reading the book. Now I feel like I should obviously trust the book (It's Comer!), but is there any truth to the other explanation? Thanks

    Read the article

  • TCP/IP- what is it exactly?

    - by OckhamsRazor
    I know that this question sounds stupid, but over all these years, I still have difficulty explaining TCP/IP to people. I don't completely get it myself, and even after reading up on it, the distinction is not very clear. What I get so far is that IP deals with networks while TCP involves delivery of messages over that network. I'm not totally convinced though. Also, they reside on different layers of the Internet architecture. Could anyone disambiguate this distinction using a simple analogy or examples? Also, I read this somewhere The difference is that TCP is responsible for the data delivery of a packet and IP is responsible for the logical addressing. In other words, IP obtains the address and TCP guarantees delivery of data to that address. Is this correct? Thanks for helping me out. One last thing- Where does the ethernet come in all of this?

    Read the article

  • Proxy / Squid 2.7 / Debian Wheezy 6.7 / lots of TCP Timed-out

    - by Maroon Ibrahim
    i'm facing a lot of TCP timed-out on a busy cache server and here below my sysctl.conf configuration as well as an output of "netstat -st" Kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux Any advice or help would be highly appreciated #################### Sysctl.conf cat /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 fs.file-max = 65536 net.ipv4.tcp_low_latency = 1 net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.ipv4.ip_local_port_range = 1024 65000 fs.aio-max-nr = 131072 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 3 kernel.threads-max = 131072 kernel.msgmax = 32768 kernel.msgmni = 64 kernel.msgmnb = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 net.ipv4.ip_forward = 1 net.ipv4.tcp_timestamps = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.ip_dynaddr = 1 vm.swappiness = 0 vm.drop_caches = 3 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_ecn = 0 net.ipv4.tcp_max_orphans = 131072 net.ipv4.tcp_orphan_retries = 1 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.tcp_max_syn_backlog = 32768 net.core.netdev_max_backlog = 131072 net.ipv4.tcp_mem = 6085248 16227328 67108864 net.ipv4.tcp_wmem = 4096 131072 33554432 net.ipv4.tcp_rmem = 4096 174760 33554432 net.core.rmem_default = 33554432 net.core.rmem_max = 33554432 net.core.wmem_default = 33554432 net.core.wmem_max = 33554432 net.core.somaxconn = 10000 # ################ Netstat results /# netstat -st IcmpMsg: InType0: 2 InType3: 233754 InType8: 56251 InType11: 23192 OutType0: 56251 OutType3: 437 OutType8: 4 Tcp: 20680741 active connections openings 63642431 passive connection openings 1126690 failed connection attempts 2093143 connection resets received 13059 connections established 2649651696 segments received 2195445642 segments send out 183401499 segments retransmited 38299 bad segments received. 14648899 resets sent UdpLite: TcpExt: 507 SYN cookies sent 178 SYN cookies received 1376771 invalid SYN cookies received 1014577 resets received for embryonic SYN_RECV sockets 4530970 packets pruned from receive queue because of socket buffer overrun 7233 packets pruned from receive queue 688 packets dropped from out-of-order queue because of socket buffer overrun 12445 ICMP packets dropped because they were out-of-window 446 ICMP packets dropped because socket was locked 33812202 TCP sockets finished time wait in fast timer 622 TCP sockets finished time wait in slow timer 573656 packets rejects in established connections because of timestamp 133357718 delayed acks sent 23593 delayed acks further delayed because of locked socket Quick ack mode was activated 21288857 times 839 times the listen queue of a socket overflowed 839 SYNs to LISTEN sockets dropped 41 packets directly queued to recvmsg prequeue. 79166 bytes directly in process context from backlog 24 bytes directly received in process context from prequeue 2713742130 packet headers predicted 84 packets header predicted and directly queued to user 1925423249 acknowledgments not containing data payload received 877898013 predicted acknowledgments 16449673 times recovered from packet loss due to fast retransmit 17687820 times recovered from packet loss by selective acknowledgements 5047 bad SACK blocks received Detected reordering 11 times using FACK Detected reordering 1778091 times using SACK Detected reordering 97955 times using reno fast retransmit Detected reordering 280414 times using time stamp 839369 congestion windows fully recovered without slow start 4173098 congestion windows partially recovered using Hoe heuristic 305254 congestion windows recovered without slow start by DSACK 933682 congestion windows recovered without slow start after partial ack 77828 TCP data loss events TCPLostRetransmit: 5066 2618430 timeouts after reno fast retransmit 2927294 timeouts after SACK recovery 3059394 timeouts in loss state 75953830 fast retransmits 11929429 forward retransmits 51963833 retransmits in slow start 19418337 other TCP timeouts 2330398 classic Reno fast retransmits failed 2177787 SACK retransmits failed 742371590 packets collapsed in receive queue due to low socket buffer 13595689 DSACKs sent for old packets 50523 DSACKs sent for out of order packets 4658236 DSACKs received 175441 DSACKs for out of order packets received 880664 connections reset due to unexpected data 346356 connections reset due to early user close 2364841 connections aborted due to timeout TCPSACKDiscard: 1590 TCPDSACKIgnoredOld: 241849 TCPDSACKIgnoredNoUndo: 1636687 TCPSpuriousRTOs: 766073 TCPSackShifted: 74562088 TCPSackMerged: 169015212 TCPSackShiftFallback: 78391303 TCPBacklogDrop: 29 TCPReqQFullDoCookies: 507 TCPChallengeACK: 424921 TCPSYNChallenge: 170388 IpExt: InBcastPkts: 351510 InOctets: -609466797 OutOctets: -1057794685 InBcastOctets: 75631402 #

    Read the article

  • TCP Tweaking options and Results: Any suggestions?

    - by krishnakumar
    I first tried with the default windows XP TCP option(It doesn't have TCPWindowSize option and TCP1323 in its Registry setting). I dynamically set those options using TCP optimizer. Here I list out the result with and without TCP Tweaking option. I see no major improvements in TCP after increasing window size optimally too. What value should I set to increase the performance? Results: Without any window size and MTU setting from server to client (receiving) TCPWindowSize : MTU : TTL: Size:586 MB total duration : 03:47 With window size extension from server to client (receiving) Bandwidth :100 Mbps Latency: 100ms BDP :1250000 TCPWindowSize : 1250000 MTU :1500 TTL:128 Size:586MB total duration : 03:44 With window size extension from server to client (receiving) TCPWindowSize :64240 MTU :1500 TTL :112 Size: 586MB total duration : 03:49

    Read the article

  • Is TCP/IP encapsulation MSB or LSB?

    - by Justin
    Application data sent over TCP experiences multiple encapsulations: The application data is encapsulated within one or many TCP fragments The TCP fragment is encapsulated within one or many IP datagrams The IP datagram is encapsulated within one or many Ethernet frames It turns out Ethernet frames are sent most-significant byte first, and within each byte, most-significant bit first. What about the multiple encapsulations? Are they performed MSB first or LSB first?

    Read the article

  • How passively monitor for tcp packet loss? (Linux)

    - by nonot1
    How can I passively monitor the packet loss on TCP connections to/from my machine? Basically, I'd like a tool that sits in the background and watches TCP ack/nak/re-transmits to generate a report on which peer IP addresses "seem" to be experiencing heavy loss. Most questions like this that I find of SF suggest using tools like iperf. But, I need to monitor connections to/from a real application on my machine. Is this data just sitting there in the Linux TCP stack?

    Read the article

  • TCP Windows Size vs Socket Buffer Size on Windows

    - by Patrick L
    I am new to Windows networking. When people talk about TCP tuning on Windows platform, they always mention about TCP Window Size. I am wondering whether Windows uses the concept of "Socket Buffer Size"? On Windows XP, the TCP window size is fixed. We can set it using the TCPWindowSize registry value. How about Socket Buffer Size? How can we set Socket Buffer size on Windows? Can we set it to a value different from TCP window size?

    Read the article

  • Manually forcing TCP connection to retry

    - by Vi.
    I have a TCP connection (SSH session to some computer for example) Network suddenly goes down and drops all packets (disconnected cable, out of range). TCP resends packets again and again, retrying with increasing delays. I see the problem and plug the cable back (or restore network somehow). TCP connection finally successfully resends some packet and continues. The problem is that I need to wait for a some timeout on point 5. I want to use my opened SSH session now and not wait for 5-10 seconds until it finds out that connection is working again. How to force all TCP connections to resend data without delays in GNU/Linux?

    Read the article

  • Manually forcing TCP connection to retry

    - by Vi
    I have a TCP connection (SSH session to some computer for example) Network suddenly goes down and drops all packets (disconnected cable, out of range). TCP resends packets again and again, retrying with increasing delays. I see the problem and plug the cable back (or restore network somehow). TCP connection finally successfully resends some packet and continues. The problem is that I need to wait for a some timeout on point 5. I want to use my opened SSH session now and not wait for 5-10 seconds until it finds out that connection is working again. How to force all TCP connections to resend data without now in GNU/Linux?

    Read the article

  • Random TCP Resets

    - by allenwei
    We got randomly TCP "reset" error when we send request to remote server. Log from remote server Cisco TCP Connection Terminated,Nov 05 14:43:39 EST: %ASA-session-6-302014: Teardown TCP connection 640068283 for Outside:xxxx to xxxx duration 0:00:00 bytes 4160 TCP Reset-O One my local machine I saw when I use netstat 100703 connections reset due to unexpected data 324186 connections reset due to early user close I also use tcpdump to see what's wrong with it, I saw xxxx.https: Flags [R.], seq 290, ack 1369, win 136, options [nop,nop,TS val 2871790533 ecr 1897173283], length 0 The problem just happened today, we didn't change anything on our server. Anyone know what's wrong with it? Is it related to code we wrote send out request or related to linux configuration?

    Read the article

  • Accessing mySQL from two ports: Problems with iptables

    - by marekventur
    Hi! I'm trying to make my mySQL-server (running on Ubuntu) listen on port 3306 and 110, because I would like to access it from a network with very few open ports. So far I've found this answer telling me to do iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 110 -j REDIRECT --to-port 3306 but all I got is: # mysql -h mydomain.com -P 3306 -u username --password=xyz Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 68863 Server version: 5.0.75-0ubuntu10.5 (Ubuntu) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> exit Bye # mysql -h mydomain.com -P 110 -u username --password=xyz ERROR 2003 (HY000): Can't connect to MySQL server on 'mydomain.com' (111) I'm not an expert with iptables, so I not sure where to look for the problem. I'm googling around for quite some time, but haven't found anything to help me yet. This is what iptable tells me: # iptables -t nat -L -n -v Chain PREROUTING (policy ACCEPT 32M packets, 1674M bytes) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 redir ports 3306 Chain POSTROUTING (policy ACCEPT 855K packets, 55M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 837K packets, 54M bytes) pkts bytes target prot opt in out source destination # iptables -L -n -v Chain INPUT (policy DROP 7 packets, 340 bytes) pkts bytes target prot opt in out source destination 107K 5390K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `INPUT INVALID ' 131K 6614K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x05/0x05 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x11/0x01 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x18/0x08 0 0 MY_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x30/0x20 6948K 12G ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 151M 34G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 32M 1666M ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 1833 106K ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 603 29392 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25 1 60 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:465 24 1180 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:110 1 60 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:995 7919 400K ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143 1 60 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:993 0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:119 1 60 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 7 517 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53 1110 65364 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 139K 8313K ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 10176 499K ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3306 2 80 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123 0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:6060 4 176 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:6667 20987 1179K MY_REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2159 284K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `OUTPUT INVALID ' 2630 304K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 6948K 12G ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 181M 34G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 0 0 MY_REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain MY_DROP (7 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `PORTSCAN DROP ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain MY_REJECT (2 references) pkts bytes target prot opt in out source destination 13806 652K LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `REJECT TCP ' 18171 830K REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 912 242K LOG udp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `REJECT UDP ' 912 242K REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 1904 107K LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `DROP ICMP ' 1904 107K DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 2/sec burst 5 LOG flags 0 level 4 prefix `REJECT OTHER ' 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Is there anyone who can give ma a hint where to look for the problem? Thank you!

    Read the article

  • FreeBSD slow transfers - RFC 1323 scaling issue?

    - by Trey
    I think I may be having an issue with window scaling (RFC 1323) and am hoping that someone can enlighten me on what's going on. Server: FreeBSD 9, apache22, serving a static 100MB zip file. 192.168.18.30 Client: Mac OS X 10.6, Firefox 192.168.17.47 Network: Only a switch between them - the subnet is 192.168.16/22 (In this test, I also have dummynet filtering simulating an 80ms ping time on all IP traffic. I've seen nearly identical traces with a "real" setup, with real internet traffic/latency also) Questions: Does this look normal? Is packet #2 specifying a window size of 65535 and a scale of 512? Is packet #5 then shrinking the window size so it can use the 512 scale and still keep the overall calculated window size near 64K? Why is the window scale so high? Here are the first 6 packets from wireshark. For packets 5 and 6 I've included the details showing the window size and scaling factor being used for the data transfer. Code: No. Time Source Destination Protocol Length Info 108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1 115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489 116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338 117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1 118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU] Details: Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309 Source port: http (80) Destination port: 49190 (49190) [Stream index: 4] Sequence number: 1 (relative sequence number) [Next sequence number: 310 (relative sequence number)] Acknowledgement number: 425 (relative ack number) Header length: 32 bytes Flags: 0x018 (PSH, ACK) Window size value: 130 [Calculated window size: 66560] [Window size scaling factor: 512] Checksum: 0xd182 [validation disabled] Options: (12 bytes) No-Operation (NOP) No-Operation (NOP) Timestamps: TSval 2617517423, TSecr 945617490 [SEQ/ACK analysis] TCP segment data (309 bytes) Note: originally posted http://forums.freebsd.org/showthread.php?t=32552

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >