As far as I know, we can sent request packets with the IP timestamp option enabled. By enabling the IP timestamp option in the request packets, the replied packets from the target machines included timestamps showing when the replied packets were generated in the target machines. I searched a lot but didn't find how to do this via code or script.
this paper proposed that this can be achieved with ping, but the details are not proposed. So how to use ping(or other ways) to get the timestamp of the target ip
Related
Inside an IP network IPv4 protocol is being used. When a datagram is being transported through the network (TTL=2), an error occurs inside the field which contains TCP-segment with the address of a web page. What will be the reaction of the router when reading such datagram?
I'm battling with this question for two days now.
What I know:
the router only reads the header of the datagram and if the checksum fails the datagram is being discarded by the router,
TTL is always decremented by one by the router if the header checksum is OK, after the -1, the datagram is being forwarded to the next router in the network
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
However there are three other possible answers to the questions:
The router sends ICMP to source with the error
the router repairs the mistake based on the header checksum and then forward the datagram
the router sends the datagram out of the network (discards the datagram)
Any help with clearing this problem?
The exact algorithms that must be implemented by IPv4 routers is described in RFC 1812 - Requirements for IP Version 4 Routers. According to the IETF RFC Index it still applies ("Status: BEST CURRENT PRACTICE").
The forwarding algorithm can be found in Section 5.2.1. The constraints determining the dependencies between the steps are (quoting):
(1) A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents of
the header. This allows the router to detect and discard bad
packets before the expenditure of other resources.
(2) Processing of certain IP options requires that the router
insert
its IP address into the option. [...]
(3) The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself, for
reasons mentioned in Section [4.2.2.9].
(4) More generally, when a packet is delivered locally to the
router,
its IP header MUST NOT be modified in any way [...].
The actual steps performed when receiving a packet are (quoting):
(1) The router receives the IP packet (plus additional information
about it, as described in Section [3.1]) from the Link Layer.
(2) The router validates the IP header, as described in Section
[5.2.2]. Note that IP reassembly is not done, except on IP
fragments to be queued for local delivery in step (4).
(3) The router performs most of the processing of any IP options.
As
described in Section [5.2.4], some IP options require additional
processing after the routing decision has been made.
(4) The router examines the destination IP address of the IP
datagram, as described in Section [5.2.3], to determine how it
should continue to process the IP datagram. There are three
possibilities:
o The IP datagram is destined for the router, and should be
queued for local delivery, doing reassembly if needed.
o The IP datagram is not destined for the router, and should be
queued for forwarding.
o The IP datagram should be queued for forwarding, but (a copy)
must also be queued for local delivery.
So it is clear that checksum verification of the IPv4 header is performed first. The exact steps are described in Section 5.2.2 IP Header Validation, but they are not important here. What matters is that only the IP header is checked, not the content. Therefore the router cannot detect the error.
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
Correct.
As for the other options:
The router sends ICMP to source with the error
No, there is no Time Exceeded error. As for other ICMP errors, there are none that signal to the sender packet corruption. So even if the router could detect packet corruption (say if the corrupted bit was in the IP header), it would still not send an ICMP message.
The router repairs the mistake based on the header checksum and then forward the datagram
No, the checksumming performed in IPv4 and TCP only allows error detection, not correction.
The router sends the datagram out of the network (discards the datagram)
It does not discard it because it does not detect the error.
Regarding what I said in the comment about link layer error detection, there are usually two sources of errors in transit: (1) from the transmission medium (interference, damaged cable, improperly connected plug etc.) and (2) from forwarding devices themselves (defective memory chips, firmware bugs, cosmic rays hitting a chip etc.). The link layer can usually detect and may even correct errors from (1), but obviously not from (2). So the scenario described in the question is indeed possible if a device malfunction corrupted the packet contents.
I'm trying to run tests on a simulated network I'm running on my machine and would like to get timing information on packets I'm sending and then receiving over local loopback.
When I run tcpdump -i lo I see two packets for every packet of data I send over local loopback: a data-carrying packet with a sequence number, and an associated ack packet. Each has only 1 timestamp associated with it.
I'd like to see when the data-carrying packet is sent and received, and when the ack packet is sent and received-- that is, 4 timestamps in total. I can't figure out how to do this in tcpdump no matter what Google searches I try or flags I pass it.
Right now I'm only getting 2 timestamps, one for each packet. I'm pretty sure they are both receive times for the packets.
I could probably run this test using two different machines, but I don't have another one on hand right now, and if I did that the clock between the two wouldn't be synchronized perfectly so the timestamps would be off.
It turns out what I'm asking for here is impossible. When sending over local loopback, the kernel uses a purely software layer, so there are no TCP packets actually being sent.
This is actually true for using any device and sending to yourself-- the kernel automatically optimizes and doesn't actually use the hardware to send packets.
In order to get send and receive times, you need to route through some other external agent. Alternatively, you can pretend there are two different interfaces running on your computer using netns, then connect them using virtual ethernet (veth) and then log tcpdump data over that connection.
See this blog post on setting up a connected netns namespace.
How do I trace the path of HTTP packets using Wireshark. When I filter out using keyword "HTTP", all I see is just the source and destination IP addresses, rather for every HTTP request I would want to see what path did it take with their IP addresses. I would like to see an output similar to traceroute.
It is impossible for a sniffer program to determine the full path that an IP packet took merely by looking at the packet, unless one of the IP "record route" options was used, so that the packet, as received by the program, contains the full route. That option is rarely, if ever, set.
In addition, that wouldn't help for packets sent by the machine running the sniffer program - you have to capture packets on the final machine in order for the recorded route to have the full path.
So, no, Wireshark can't do this, tcpdump can't do this, Microsoft Network Monitor can't do this, KSniffer can't do this, NetScout Sniffer can't do this, OmniPeek can't do this, no sniffer can do this.
I want to identify an UDP or TCP packet that have its source IP address faked. My guess is that even if the packet is faked with a program such has hping, the MAC src address is still the same on all the faked packets, is this correct?
If my idea is not correct, how can I identify such packets that are being faked and looks like it has different source for each and every packet?
Thanks.
MAC addresses can be faked too.
With TCP, its easy to identify / handle this. You'll reply to a fake SYN packet with a SYN-ACK. If it was a real client, it'd reply with an ACK to complete the handshake. Only caveat is that you'll have to implement syn-cookies so that you don't create state & use up resources while waiting for an ACK.
With UDP, there is no way to know, since the protocol is connection-less. If you send a reply to the fake packet, you're not guaranteed a response from a "real" client. So there is no way to identify a fake one.
The way I see it, UDP and TCP have nothing to do with this. You're talking about only layer 2 (MAC) and layer 3 (IP). Even at that though, you have no way of knowing, because the source MAC address should be that of the closest router to the recipient (assuming the packet did not originate in your subnet.) So you should see the same MAC address for most all inbound packets (again, internet traffic only).
Now there are profiling tools like p0f that work on signatures of packets, and you could try and do some heuristics based on that information, but nothing very concreted could be determined.
From the packet you can get the MAC address of the nearest node. Yeah you can send ACK packet to the fake source address(IP) and then use Traceroute command to know the path of the source packet, so that you can atleast find the location of the originating. It works well in TCP and you can have acknowledgement also.
I'm using sharppcap in order to send packets as part of a monitoring system. Usually it works well but I've encountered the strangest bug on a hosted vista machine and I would like your help.
On that virtual vista machine, injected packets are duplicated. That is, if I send a ping request using libpcap, it somehow gets duplicated and I get two requests on the destination machine. The two requests are almost identical byte-wise, and the only difference between them is that the second packet's TTL field is one minus the original packet's value.
Using wireshark I can see the packet gets duplicated before it (and its clone) leave the vista machine.
The problem is manifested even when using other tools for injecting packets using libpcap (namely PlayCap).
Any ideas?
The TTL field being one lower on the clone packet indicates that it has gone through one more routing hop than the other packet. This seems to indicate that the packet has gone through the Vista machine's input packet queue (and is routed back out) as well as directly to its output queue.