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.
Related
I'm am facing to an issue when sniffing on the loopback interface when using a JTAG debug probe, which uses a TCP socket. It completly flood the loopback, and freeze Wireshark after a few seconds.
As a workaround, I have made a dummy LUA dissector for this case (redlink-server protocol). Wireshark is no longer freezing, but it produces like 8Gb of packets in a few minutes...
(the plugin consists in an empty dissector function, add register this dissector for TCP port 3490)
Is there a simple way to delete those packets from dump file not to overflow my RAM ?
Tanks by advance
Thomas.
You can apply a capture filter, not a display filter, to avoid capturing the traffic. In your case, the capture filter to exclude the unwanted traffic would be not tcp port 3490.
Refer to pcap-filter for more information on capture filters, as well as the Wireshark User Guide, Section 4.10. Filtering while capturing.
I need to exercise some hardware by sending a network traffic with it. While it is doing it I will probing some of the lines with an oscilloscope. Need to verify signaling. The problem is that I won't be able to connect to any server during the test. Many reasons for that, one of each is that hardware isn't complete yet.
Does anyone know if there is a away to generate network traffic with iperf without using a server? All I need is to just send some data, don't need to know if it was received. If there isn't can someone point me to a tool that can do that.
iperf UDP will do it you just need to make sure there is an arp entry for the destination (enter it manually) or use a multicast destination which doesn't require ARP, e.g. iperf -u -c 239.1.1.1 -b 10M
I have a packet trace that I forge with scapy and resend with tcpreplay. I recompute IP and transport-layer checksums with Scapy, save the packets to disk on pcap file and call tcpreplay on it.
By running tcpdump in parallel I noticed that all IP checksums of those outgoing packets have no value at all. It seems that tcpreplay is removing it each time.
Now, does this happen on purpose? Am I missing something?
Checksums should be correct, so I don't think tcpreplay removes them because a check on it failed.
You didn't specify the actual tcpreplay command you are using, but tcpreplay never edits packets. You can use tcpreplay-edit or tcprewrite to edit packets, but not tcpreplay. And even then tcpreplay-edit/tcprewrite will calculate/fix your checksums; not zero them out.
Have you opened up the original pcap generated by scapy in Wireshark and verified there are actually checksums there? Honestly, this sounds like a simple case of garbage in, garbage out.
FWIW, I'm not aware of anything that would zero out your checksums... at least I can't imagine why the kernel would do that for packets sent via the PF_PACKET interface- that would be a bug IMHO.
If you figure it out, let me know.
I'm not really sure about what's going on but i suspect that tcpreplay detect that the interface is going to use to send out the packet has the Offload Checksum active and let the NIC to calculate the right checksum.
Try to disactivate the offload checksum with
ethtool -K eth0 rx off tx off
then retry and let us know
You can solve this issue using the tcpreplay-edit which is included in the same package that tcpreplay, in particular this option:
-C, --fixcsum Force recalculation of IPv4/TCP/UDP header checksums
Desactivating the offload checksum of the interface is a non sense: when the packet goes out it would be rejected by the next machine having checksum checking enabled (+99%)
There is an old program a member of this online community made for everyone to use, but he is no longer around and no longer supports it. I wanted to help the community by extending it's features somewhat. To do that, I need to know how data is sent from it. How can I capture the network traffic it sends, and determine what it's sending?
WireShark is your friend. Available for UNIX and Windows.
Wireshark is a network packet analyzer. A network packet analyzer will
try to capture network packets and tries to display that packet data
as detailed as possible.
Wireshark User's Guide
#Kerrek SB's Tip: use tcpdump -s0 -w /tmp/data -i eth3 or so to create the dump file, and analyze it with Wireshark later as an unprivileged user.
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...).