boiz and girlz
I`ve been learning networking for a couple of days, namely about TCP/ip and OSI levels.
And i have a question:
When a frame arives in my LAN from the Internet, it will be decapsulated, so that a router can understand whom he should deliver it to, but doesnt it mean that that frame will no longer contain a Physical level, which wont let it get to its destination? (I can suppose, that after decapsulation that frame will be once again incapsulated on a router, so that it can arrive the destination with Physical level)
As far as i understand, Physical level is a way to transfer frames.
One more thing: "Why does everyone use the 'Packet Loss', when there should be 'Frame Loss(NOT RELATED TO FPS)'?"
//Just want to find out what i`ve missed and missunderstood.
Thanks in advance.
It's called packet loss because it's experienced at the network level (i.e. IP level). What hosts see is just an IP packet disappearing somewhere on the path.
There are actually two way a packet can be lost:
The frame can be lost in transmission at the data link level (for instance, the frame couldn't be transmitted on WiFi successfully because of interference).
The packet could be dropped at the network level (for instance, an IP router is experiencing congestion because the downstream link has insufficient bandwidth).
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.
Recently I dug a bit deeper into the matter of network protocols and the OSI model, when noticed, that incoming TCP datagrams (correct me if this is the wrong term) are splitted into several parts, when they exceed a certain size - in this case it's propably my router's MTU. I captured those datagrams using SharpPcap in order to extract some information i am looking for, if you are wondering where I got this information from.
Anyway I was wondering if the reassembly of fragmented packets shouldn't be task of the IP layer, since it definitely provides information to accomplish this (id, fragmentation flags, fragment offset). Furthermore I read, that the TCP layer is to be interpreted as a stream-based protocol. But this actually implies, that it's up to the TCP layer to care about filling the application's buffer the right way, so that the initial piece of information is reconstructed and may be flushed "up" all further layers.
Before I made this observation I actually thought, that the TCP layer should care about reassembling those datagrams, but none of the mentioned layers does...
This leads to the following question(s):
Why are the TCP datagrams I receive not reassembled and what layer SHOULD actually take care about this?
The ip layer handles fragmentation and reassembly, http://en.wikipedia.org/wiki/IP_fragmentation.
When you use a tool like SharpPcap that uses winpcap/airpcap/libpcap, you are receiving the raw datagrams from the device you are capturing on. For many adapters this is an ethernet datagram that then contains an ip frame etc.
This is in contrast to data received after processing by the networking stack, where the reassembly is performed.
So, its expected that you won't get reassembled datagrams from SharpPcap (or many other capture libraries) because the data is being captured at the adapter level, not inside of our as an output of the networking stack that is performing reassembly.
You can perform the reassembly after capture either yourself or using a library that provides this functionality. You could also add such a component to Packet.Net (the packet processing library that SharpPcap is using) to provide this reassembly.
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.
One of my networks course projects has to do with 802.11 protocol.
Me and my parther thought about exploring the "hidden terminal" problem, simulating it.
We've set up a private network. We have 2 wireless terminals that will attempt to send a file
to a 3rd terminal that is connected to the router via ethernet. RTS/CTS will be disabled.
To compare results, we'd like to measure the number of packet collisions that occured during the transfer so as to conclude that is due to RTS being disabled.
We've read that it is imposible to measure packet collisions as it is basically noise. We'll have to make do with counting the packets that didnt recieve an "ACK". Basically, the number of retransmitions.
How can we do that?
I suggested that instead of sending a file, we could make the 2 wireless terminals ping the 3rd terminal continually. The ping feature automatically counts the ping packets that didnt recieve the "pong". Do you think its a viable approach?
Thank you very much.
No, you'll get incorrect results. Ping is an application, i.e. working at application (highest) level of the network. 802.11 protocol operates at MAC layer - there are at least 2 layers separating between ping and 802.11. Whatever retransmissions happen at MAC layer - they are hidden by the layers above it. You'll see failure in ping only if all the retransmissions initiated by lower levels have failed.
You need to work on the same level that you're investigating - in your case it's the MAC layer. You can use a sniffer (google for it) to get the statistics you want.
For a homework assignment, I was tasked with creating a "Ping Pong" layer that sits right above the Ethernet stack.
I was able to easily complete the task but when I tested my application over my wireless connection and tried communication with my desktop computer (ethernet) on the same network I found some odd behavior.
It seems like the packet is being padded with information I did not add.
From wireless->ethernet I get something like the following (as a hex output of the data received, taking off the ethernet header, periods are unprintable characters).
3-468...lkin54g......$
0Hl.........*../..2..
When my desktop responds to my laptop (ethernet->wireless) I get something like the following
3-468................
.....................
Is this expected behavior?
Yes. Valid Ethernet frames have a minimum size of 64 bytes (including the Ethernet header and a 4-byte checksum at the end).
When you send packets across the network, the data you are sending is wrapped up into successively larger data structures at each level of the OSI network layer model. When your operating system receives the packets of information, it unwraps the data as it goes up the layers. Reading more about the OSI model could be useful for better understanding.
Here is a picture that illustrates what is going on at each layer, from an ebook.