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.
Related
I'm struggling to get an embedded platform with fairly standard IPV4 networking running. I have a working prototype which obtains an IP via DHCP without problem on a point to point connection (single cat5 cable) attached to a test laptop.
On my new hardware I get the link up but no DHCP request gets to the server (monitoring with wireshark). However what I do see, 100% repeatable, when those packets should be received, is a couple of ICMPv6 packets from the test laptop. This happens every time, there is no other activity on that link at any other time.
It seems to me that those packets are trying to tell me something, but what? Perhaps the DHCP request is going out but malformed for some reason?
(I can't post the actual packet from my phone, will make a copy and do so later.)
Seems to be something generated by the laptop when it sees the link comes up. Turned out to be unrelated to the issue I had (which was hardware related).
I understand that it's different than a hub in that instead of packets being broadcasted to all devices connected to the device, it knows exactly who requested the packet by looking at the MAC layer.
However, is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch? Or is this only a problem with ethernet hubs that doesn't affect switches due to the nature of how a switch works?
On a slightly off topic side note, what exactly is classified as a LAN? For example, imagine two separate ethernet switches are hooked up to a router. Would each switch be considered a separate LAN? What is the significance of having multiple LAN's within the same network?
it knows exactly who requested the packet by looking at the MAC layer.
More exactly, the switch uses the MAC destination address to forward a frame to the port associated with that address. Addresses are automatically learned by looking at the MAC source address on received frames.
A switch is stateless, ie. is has no memory who requested which data. A layer-2 switch also has no understanding of IP packets, addresses or protocols. All a basic switch does is learn source addresses and forward by destination address.
is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch?
Yes. You'll need a managed switch supporting port mirroring or SPANning. This doesn't intercept frames, it just copies them to the mirror port. If you need to actually intercept frames you have to put your interceptor in between the nodes (physically or logically).
With a repeater hub, every bit is repeated to every node in the collision domain, making monitoring effortless.
what exactly is classified as a LAN?
This depends on who you ask and on the context. A LAN can be a layer-1 segment/bus aka collision domain (obsolete), a layer-2 segment (broadcast domain), a layer-3 subnet (mostly identical with an L2 segment) or a complete local network installation (when contrasted with SAN or WAN).
Adding to #Zac67:
Regarding this question:
is it still possible to use a packet sniffer like Wireshark to
intercept packets meant for other users of the switch?
There are also active ways in which you can trick the Switch into sending you data that is meant for other machines. By exploiting the Switch's mechanism, one can send a frame with a spoofed source MAC, and then the Switch will transfer frames destined to this MAC - to the sender's port (until someone else sends a frame with that MAC address).
This video discusses this in detail:
https://www.youtube.com/watch?v=YVcBShtWFmo&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=18
In general, I recommend the following video that explains this in detail and in a visual way:
https://www.youtube.com/watch?v=Youk8eUjkgQ&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=17
what exactly is classified as a LAN?
So indeed this is one of the least-well-defined terms in Computer Networks. With regards to the Data Link Layer, a LAN can be defined as a segment, that is - a broadcast domain. In this case, two devices are regarded as part of the same segment iff they are one hop away from one another - that is, they can switch frames in the second layer.
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.
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.
When two computers are set the same ip address in a LAN(such as 192.168.1.100), both of them may receive incomplete packets. How does tcp on them react to this situation ? Will they ask for retransmission ?
My understanding is that TCP will reset the connections because of sequence number errors. So, connections will mysteriously and randomly disconnect, depending on when the stack detects the sequence number error.
You have two situations that can occur from this, one of the computers will be able to communicate fine while the other cannot at all, or they both will not communicate (if it stored the MAC ADDRESS in the ARP cache it will still try to route to the first computer on the network). Also, depending on the direction, if a computer that does not have a duplicate address trying to contact one of the duplicates, it will not the correct computer because they will be fighting over who has the ip address. If you swap that scenario, it will be asking for re-transmissions but no guarantee that it will ever get them, which leads back to them fighting over the response of who do I send it back to.