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.
Related
I have used google for the above questionair but I still couldn't find the answer for the above question. Please help me out on this.
Networking packets are quite a complicated subject, but I will try to explain them to the best of my ability.
Each packet has a source IP and a destination IP, and a body. That’s all it actually needs. Most packets also have a protocol. I don’t know every major protocol, but the basic ones are ICMP, TCP, and UDP(TCP and UDP might be built on ICMP, not sure). Tcp and UDP packets also have a source port and destination port. Using some Linux trickery, you can define your own protocol, but your router probably won’t know what to do with traffic coming in as it isn’t programmed to know whether it should let it in. TCP gives the illusion of a byte stream, but everything is still split into packets. ICMP is just a simple packet, used for pings and similar things. UDP is the most basic of the 3, and is similar to ICMP but with ports, as far as I can tell.
Back to TCP, it splits into multiple packets, because too large of packets are more likely to get lost. TCP also makes sure all packets arrive and in the right order. A stream is nessesary for this, as if you were to try to send your own packet, it wouldn’t have a check for how large, and could get lost very easily if not done right.
A UDP listener simply tells the OS to listen for UDP packets on that port instead of discarding them. When you send a UDP packet, the router remembers the source and destination, and allows the other end to communicate back for a certain length of time.
A TCP listener accepts packets requesting a UDP connection, and sends them to a different port. The router uses a similar strategy to UDP to know if a packet should be let in. Unfortunately, if one side terminates, there is no way for the other side or the router to know. Thus the router will often continue letting in packets to a stream that was closed, which could pose a risk.
This is my understanding, it is very much flawed. Hope I could help nonetheless!
I am developing a logic core to perform data transfer between a FPGA and a PC over ethernet, using a LAN8710 PHY on my FPGA board.
I've achieved to transfer some UDP data packets from the FPGA to the PC. It's a simple core that complies with the PHY transfer requirements. It builds the UDP package and transfer it to the PC.
To check the reception on the PC, I am using Wireshark and as said above, I receive the packets correctly. I've checked the reception with a simple UDP receiver written by myself.
But, I've noticed that I only receive these packets when Wireshark is running on the PC. I mean, if Wireshark is ON, my application receives the packets too, and the counter of received packets of the following picture increases. (This picture is not mine, just one from the internet)
http://i.stack.imgur.com/wsChT.gif
If I close Wireshark, the PC stops receiving packets and the counter of received packets stops. My application stops receiving too.
Although novice on networking topics, I suspect that this issue is related to PC-side. Seems like Wireshark is "opening/closing" the ethernet communication channel, or something like that. Does anyone knows about this issue?
To build a functional core to transfer data between a PC and the FPGA, I've developed a core to transfer and receive UDP packets. Next step will be ARP implementation (to let the PC identify my FPGA board, as I understand). What protocols are necessary to perform full-duplex data transfer between this 2 devices?
Thank you very much in advance,
migue.
Check whether you are able to get appropriate receive interrupt at ethernet driver level on PC-side for a single transmitted packet by FPGA. If you do not get the receive interrupt, check on the transmit side(FPGA) for appropriate transmit interrupts for packet that is being transmitted. This should mostly help you in cornering the issue.
As far as i know, wireshark is just a packet analyzer/sniffer. However, if wireshark is suspected, one option could be to try with alternate packet sniffer to rule out if any such scenario is happening.
A handy tool for determining problems in network and also for determining the network statistics shall be netstat. netstat -sp udp shall list down the statistics only for UDP. There are many other parameters that can be used with netstat for diagnosis.
After many months I solved it, I post to help someone stucked in the same point.
Finally I figured out that Wireshark uses a tool to access the network link layer of the computer. This tool allows Wireshark to sniff all incoming and outgoing packets at a specified network device. To do this, the first step is to OPEN the network device, and that's why my program only worked if Wireshark was open.
Regards.
In my college lab, all the PCs are connected via a hub. I want to capture data packets using Wireshark, but it only displays the interface of my own PC. How can I capture the packets of other PCs?
I've tried all the interfaces, and I can't get it to work.
Odds are you're connected to a switch rather than a hub. The problem there is that only packets intended for your network card's hardware (MAC) address and broadcast packets will be sent to your PC. The switch remembers the hardware address of devices plugged into it and performs packet forwarding based on those addresses. This vastly increases the potential bandwidth of your network segment, but makes snooping on other traffic more difficult. You will need to perform what's called ARP cache poisoning. Basically you need to trick every other computer connected to the switch to send its traffic to you rather than its true destination. You will then need to forward those packets not actually for you onto the correct destination otherwise it will take down the entire segment you're on and people will get nosy.
This type of redirection is possible, but it seems like you'll need to do quite a bit more research and understand exactly what is going on before attempting it. To get started, look into the Address Resolution Protocol; understand what a "layer 2" switch is doing; find out how to inject and reroute packets on the network; think about the consequences of getting caught.
If you're serious about moving forward, check out http://www.admin-magazine.com/Articles/Arp-Cache-Poisoning-and-Packet-Sniffing for some starting tips.
I wanted to simulate a situation where when I send some packets say ping x.x.x.x, some of my packets outgoing from my Linux box should be dropped out and number of dropped packets should be then captured through Tx dropped packets in ifconfig tool.
I know some of option/rule that we can provide in iptables but not sure about them.
Can anybody let how to simulate packet drop and dropped packet capture in Linux?
netem provides functionality to simulate various network related situation like emulate wide area network, packet loss/drop/delay.
Please refer this excerpt for more information on packet drop as your have provided less requirements.
Also see SO answer
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.