I got the first three records when I run command 'telnet 192.168.10.109 802' in my mac, then I key 'quit' to the telnet, and I got the next three records. Most people say tcp connection termination need 4-way-handshake, other words the fifth record should be sent in two parts, but this is not the case with my experiments. what is the truth of the case?
wireshark picture
I have found a answer in TCP/IP Protocol Suite, as shown in the picture
picture
Related
I am working on a tool that takes a pcap file (from wireshark in this case), and attempts to parse out data from the TCP packets.
Now in this case, I only care about the data in one direction. So my logic was to sort out each wireshark captured packet into a list by the protocol-destIP-sourceIP-destPort-sorcePort.
So from this point, I now have a list of only packets for one direction on a particular port.
From there I just want to be able to walk through the bodies of the TCP payloads in order. is it as simple as then going in order by Sequence numbers?
I would simply take the first sequence number captured, add the payload size to it and expect that to be the next TCP packet sent? Is there more to this that I am missing?
I was noticing when sorting the interfaces this way, eventually I would come up to a sequence that dosent make sense. I guess I could just assume that is the start of the next stream? I know it becomes more difficult if I have to consider traffic going back and forth... but in this case I only want to watch packets in one direction.
Wireshark captures the packet on the wire. It might happen that the packets don't arrive in sequential order, that packets are corrupt (bad checksum), that there are duplicate packets ... - and this is ignoring possible attacks designed to confuse the analysis. The TCP stack will take care of all these problems so that the application gets the right packets, but Wireshark works outside the TCP stack. Thus, while in most cases your simple procedure will likely work (assuming that you at least check TCP flags for start and end of connection), it might fail in some cases.
I am doing host discovery only (-sn) option, trying to determine active hosts that are up and running.
My first command was:
nmap -sn -PS21,22,25,53,80,443,3389,8000,8080,42000 -PA80,443,8080,42000 -PU53 xxx.xxx.xxx.xxx/27
I am scanning public IP's and the above command produces a result stating that 18 hosts are up.
However, when I run the above command with --data-length "option" (either 32 or 56), it produces a result with only 8 hosts up.
I was expecting to see more hosts, if anything... but not less. (The data-length option adds a bytes of data to every packet to simulate the ping tool and it may help evade firewall rules set to drop 0 byte packets).
I am reading Fydors book however I am having trouble understanding the behavior above.
Any ideas?
Thanks
--data-length adds data to every packet. Your TCP discovery options (-PS, -PA) are sending packets that do not usually contain data. In this case, these packets are more likely to be dropped or ignored since they are unusual. The case where --data-length is useful is for the -PE (ICMP Echo Request) discovery option. ICMP Echo Request datagrams are usually sent with some data payload, but Nmap defaults to empty probes, so IDS products like Snort will sometimes block or alert on these probes.
I have a strange one.
A number of data items are being collected by collectd and appear correctly with
collectdctl -s /var/run/collectdctl listval|getval and so forth.
These are then rendered into graphite effectively for most items.
Recently, the collectd-graphite connection ceased to be operational
for several recently added items. While it appears in collectd and
is queryable via collectdctl, it remains not on the graphite page.
I am asking to find out how you would approach this.
Thanks for any comment.
There's probably a number of ways you can troubleshoot this, but I end up almost always resorting to tcpdump, sigh. First enable debug logging in collectd just to make sure it really doesn't spit out an error message (LogLevel "debug" https://collectd.org/wiki/index.php/Plugin:LogFile although often collectd is compiled with debug logging disabled).
Then run tcpdump on the graphite server using the -s0 -X flags to tcpdump so you get the packet contents. (You can also use a more sophisticated network sniffer that prints the tcp data stream.) Check whether you see the data items that are missing the packets and whether they look appropriate (see https://collectd.org/wiki/index.php/Plugin:Write_Graphite). Typically this step allows me to quickly determine whether the problem is the sending collectd or the receiving service.
I am working on a project involving correlations in distance of the server in relation to pings and traceroutes. So I am getting the number of hops and the average ping time for different web sites. I am using puTTy and unix code to achieve this, when I traceroute the website (traceroute australia.gov.au -m 255) I allow for the maximum number of hops. I get about 18 hops, and then i get 237 numbers with three asterisks next to them. At first I assumed that this was a result of the -m 255 extension to the command, but it doesn't occur with websites like youtube or google. Is this timed out hops/connections? Also when i ping this website (ping australia.gov.au -c 25), I get no respsonse for about a minute (near 2000ms) and then the print out says that 25 packets were sent and 0 were received, what is the explanation for this?
Lots of places all over the internet block ICMP, meaning that australia.gov.au might have a valid routable IP, but just doesn't send back echo reply.
Three asterisks line from traceroute, as far as I can remember, means a packet with given TTL did not get a reply. That again probably indicates that the host/router does not want to be bothered replying to arbitrary ICMP and/or UDP packets.
I am reading 《Internetworking with TCP/IP》 by Douglas Comer,and when talking about creating a tcp connection ,there is a problem:
Suppose an implementation of TCP use
initial sequence number 1 when it
creates a connection,Explain how a
system crash and restart can confuse a
remote system into believing that the
old connection remained open.
I can't figure out why,please help me,Thanks.
Consider why a connection may get duplicate sequence numbers normally.
Then consider how the receiving system would handle a packet with a "duplicate" sequence number (because the transmitting system started reusing sequence numbers in packets it is using try to re-establish a connection).
*Edit: *
OP says:
but when re-establish the connection,the transmitting system will send a segment with SYN code bit set(and the sequence number be set 1 of course),won't that(SYN code bit set) inform the receiving system it is a new connection trying to be established ?see wiki for Transmission_Control_Protocol,it says that "Only the first packet sent from each end should have this flag(SYN) set."
But packets get lost and delayed and arrive out of order. You can't simply say everything arriving after the packet with the SYN flag is new. Lets say some of the old packets are delayed and arrive after establishment of a new connection. How do you distinguish whether a packet with sequence number #10 is from the old connection or new one? The worse case scenario is that it's from the old connection and the receiving system accepts it as from the new connection. When the real new connection packet #10 arrives, it's ignored as an unnecessary retranmission. The stream is corrupted without any indication of it.
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentSequenceNumberSynchroniz.htm
... The problem with starting off each connection with a sequence number of 1 is that it introduces the possibility of segments from different connections getting mixed up. Suppose we established a TCP connection and sent a segment containing bytes 1 through 30. However, there was a problem with the internetwork that caused this segment to be delayed, and eventually, the TCP connection itself to be terminated. We then started up a new connection and again used a starting sequence number of 1. As soon as this new connection was started, however, the old segment with bytes labeled 1 to 30 showed up. The other device would erroneously think those bytes were part of the new connection.
... This is but one of several similar problems that can occur. ...
The other issue with a predictable initial sequence number, such as starting at 1 every time, is that the predictability presents a vulnerability:
A malicious person could write code to analyze ISNs and then predict the ISN of a subsequent TCP connection based on the ISNs used in earlier ones. This represents a security risk, which has been exploited in the past (such as in the case of the famous Mitnick attack). To defeat this, implementations now use a random number in their ISN selection process.
Mitnick attack - http://www.cas.mcmaster.ca/wiki/index.php/The_Mitnick_attack
It's far worse than that though anyway - being predictable with sequence numbers makes spoofing and injecting an order of magnitude easier
After restart, if the first TCP connection is towards the same remote system, and since the sequence number will again be 1 - consider what that will cause.