I had an opportunity to work with wireshark.
I installed wireshark on my VMware and made some tests on it, I found an interesting thing.
I sent the HTTP request to non-existing computer and captured all the packet flow with wireshark.
The first packet was SYN packet, the second one was re-transmission packet.(the system hadn't received any response from the targeted computer).
But surprisingly, RST packet from the target computer reached.
I couldn't understand where this packet came from, so I tested for 2 target computers, and in both cases, I had the RST packet.
So are there anyone who can tell me about those suspicious RST packets?
Thanks for reading.
Regards.
https://ask.wireshark.org/upfiles/img2_fpJSr9b.png
https://ask.wireshark.org/upfiles/img3_Rxmvejp.png
Related
Recently i was writing a packet-sniffer code in c but the packet sniffer showed only those packets which were directed to PC ip and only showed some packets of IGMP protocol of other users.Based on recommendation from some person i tested out with wireshark and the results are exactly the same.Is there anything i'm missing out on the functionality of wireshark or is there a flaw in my NIC?
I have an issue to receive a data from my sensor with TCP retransmission message.enter image description here
Any idea please?
enter image description here
The retransmissions that you are seeing are the SYN packet. This indicates that the server to which the packets are being sent is not responding at all.
If the server were responding, you would expect to see a SYN/ACK indicating that the connection attempt is being accepted or a RST/ACK indicating that the connection attempt is being rejected.
From what you have posted, I would look to see what the firewall rules look like on 192.168.0.39. I would expect to find that it is silently dropping inbound SYN packets on port 55838.
I use raw socket to create TCP packets, with focus on the sequence number and TCP flags(SYN, ACK)
I used one machine S to send a tcp ACK packet (flag ACK is set to 1) and another machine R to receive it these two machines are in different subnets, all in my school
meanwhile, I used tcpdump to capture the packets.
Strange things happens! On machine S, the captured packet is as expected, it is an ACK packet however, on the receiving machine R, the packet becomes a SYN packet, and the sequence number is changed, the seq no is 1 smaller the expected and the ack_seq become 0!
what are potential problems?
my guess is that the router/firewall modified the ACK packet to a SYN packet because it never sees a SYN SYN/ACK exchange ahead of the ACK?
is it possible or not?
the two captured packets are:
https://docs.google.com/file/d/0B09y_TWqTtwlVnpuUlNwUmM1YUE/edit?usp=sharing
https://docs.google.com/file/d/0B09y_TWqTtwlTXhjUms4ZnlkMVE/edit?usp=sharing
The biggest problem you will encounter will be that the receiving TCP stack in each case will receive the packet and possibly reply to it. What you are attempting is really not possible.
I have a router1-switch-router2 connection. My problem is if I send a packet from router1 to router2, it is not received at router2. I am sure the ipaddress/subnet address are correct. And am also sure that packets are going out the router1. And I am also sure of the internal port connections of the switch. I have access to the onpath switch. Is there any specific command that can be used in the switch to check whether the packet is received or not? ARP itself not getting resolved
You can have a packet capture app running on both the sender and receiver that would tell the incoming and outgoing packets on both boxes.
In this case probably your packet is getting dropped either on the sender or receiver side. There can be million reasons for a packet drop. But this is a good step to start with.
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.