Are there any sources where I can find different pcaps samples for IP fragmented data (WireShark compatible)?
See the files attached to the following Wireshark bug reports for examples of IP fragmentation.
I would note that IP fragmentation is IP fragmentation regardless of the
payloads carried over IP;
What are you looking for that you wish to see "IP fragmentation of FTP data, images, files, etc" ?
Is it actually TCP re-assembly that you wish to look at ?
Bug 2651: sas.cap
Bug 713: nfs_udp.pcap
Take a look at the Wireshark Sample Captures wiki and search for fragments... for instance, they have the Teardrop overlapping IP fragment attack
Sending that to PCs would lock up an unpatched Windows 95 machine...
EDIT
If you want to see general IP fragmentation, I can't think of a capture offhand, but you can simulate IP fragmentation with creative use of tcprewrite under *nix.
Related
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 am studying in traffic control and want to know how we can check packet dropped in a traffic control that I config it. Can we use ping icmp not?
You can use ping to check if there is currently some packet loss, but if you need to see if any packets were dropped before something like "netstat -s" or regularly checking the data in /proc/net/netstat (on unix-like systems) might be more useful.
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.
Monitoring the all network traffic from one port on the switch and captured the all traffic bu using wireshark.
Here i found all packet captured in the summary result and it has dropped packet information also. This is some thing lost packets in the network or at the wireshark point?
I was in ambiguous...i am testing in ethernet based and TCP/IP based protocol.
One more possible case if my server is installed with wireshark and its capturing the all packets coming and going from this point. At this point also found the packet dropped in the wireshark summary.
So any one help in this issue....any explanation appreciated.
thanks....
Chirug
Surely wireshark is only telling you about packets it has dropped? I can't see how it could possibly know about any others.
I'm trying to confirm a user a unplugged my embedded device from a network before performing some maintenance. I'm considering "ping"ing all IP address on my sub-net, but that sounds crude. Is there a broadcast/ARP method that might work better?
You can try a broadcast ping (this is from linux):
ping -b 255.255.255.255
Another option is to download Nmap and do a ping-scan.
You could use nmap. It's still crude, but at least it's using a tool designed to do it so you don't have to spend time on it.
If you can't get reliable link state information from your Ethernet device (which most chipsets should support these days, BTW...), sending an ARP request for each IP on your local subnet is a decent substitute. The overhead is minimal, and as soon as you get a single response, you can be sure you're still connected to a network.
The only possible problem I see here, is that if your device is on a /8 subnet, it can take quite a while to loop through all 4294967296 possible IPs. So, you may want to consider some optimization, such as only sending ARP requests for your default gateway, as well as all IPs currently in your ARP table.
If there's a peer you know you were connected to recently you could try pinging or arping that first. That could cut down on the traffic you're generating.
you could also run tcpdump -n to see what's active on the network too.
Not receiving any responses to ICMP pings or ARP requests is not a 100% guarantee that there's no network connection. For instances, there might be devices on the network that are firewalled off.
EDIT: May be you could access some lower-level information on your embedded device to check whether the network interface has its link up without actually sending any data.
Is there any chance that your device supports UPnP or Bonjour? Beside of the low-level protocols your should also have a look at these protocols which support some kind of plug-&-Play functionality. A UPnP device for example sends a message on the LAN before it is switched off (though, this doesn't help if it is just removed by unplugging it...).