When using a specific datalink layer technology, for example Ethernet, do we have limitations of the used medium (i.e. Ethernet). Can we use radio connections to connect two LANs over Ethernet?
Ethernet (IEEE 802.3) is a series of layer-1/2 protocols used on various media. I don't believe there is currently an approved standard for ethernet over radio. One obstacle to that is that radio is a shared medium, and ethernet must be able to simultaneously send and listen for collisions on a shared medium, but the limitations of radio prevent that.
The IEEE has defined several other standards for radio LAN communications (802.11, 802.15, 802.16, etc.). These standards are not ethernet, but completely different LAN protocols. The best known are Wi-Fi (802.11) and Bluetooth (802.15.2).
Related
I have a captured LLDP packet.
LLDP has a list of enabled capabilities (Router, Bridge etc.) but none of the capabilities in the list is Switch. The question is how can I know if the source which the packet arrived from is a Switch Device?
If there is no a concrete answer, proximate assumption will do.
Disclaimer: I cannot actively address the switch, I'm sniffing packets...
LLDP has a list of enabled capabilities (Router, Bridge etc.) but none
of the capabilities in the list is Switch.
A switch is a bridge. The original bridges only had a few interfaces (usually two), and bridging was done with software. When technology advanced to bridging in hardware, and the electronics became cheap enough to increase the interface density on a bridge, a vendor coined the marketing term, "switch."
Modern switches are transparent (all interfaces use the same protocol) bridges. There are also translating bridges, e.g. a WAP (Wireless Access Point), which translates between ethernet and Wi-Fi.
I'm new to networking.I have seen that it's possible to capture packets through wireshark.Having seen it a question arises in my mind.
Is wifi a hub?.I mean,if im able to receive(but ignore by system since those packets aren't intended for me as a client) what another client on the same NAT is receiving doesn't that mean that wifi connection works like a hub since hubs don't filter the destination.
Sorry for the bad way of asking and explaining!!
And thank you in advance!
Wi-Fi (IEEE 802.11) is a set of protocols that use a shared medium (radio waves). Because the medium is shared, much like the old ethernet (IEEE 802.3) 10BASE-2 coax, all hosts on the medium can hear all traffic on the medium. Neither uses a hub.
A hub is something that was created to allow ethernet to use UTP in the same manner that ethernet could use coax cable. Ethernet has multiple standards to allow it to use different media, but many don't have hubs (specific to a medium and some ethernet standards), and neither does Wi-Fi.
I'm a novice in this area looking for clarification. I believe that CDMA would be classified as part of the physical layer, so what is used for the data link layer (according to the OSI model) in cellular networks? Is TCP/UDP used in cellular networks? If so, in what capacity?
On a CDMA network (and some others, such as GPRS and HSPA), PPP is used at the Data Link Layer (layer 2).
TCP/UDP (or more generally, IP) is indeed used in CDMA networks to mostly for connection to the CMDA providers ISP network for Internet access by phones and "data sticks".
These data sticks usually provide an emulated modem on a serial port over USB, which is used in a very similar manner to dial-up modems of days gone by. You'd use the same "AT commands" to establish a connection, the only difference being the relatively high speed of the emulated serial port.
I was wondering if it is layer 7 for websocket as the application is actually the browser.
Websocket depends on TCP (OSI#4) and only the handshake phase is initialized by HTTP (OSI#7) 1. Although it uses TCP port 80 only.
According to the runtime behavior, I have to say WebSocket should be a special OSI#7 protocol. Then we can put SSL/TLS into OSI#6 (see wikipedia), and the implementation inside browser into OSI#5.
It is better to understand the layer using TCP/IP model rather than OSI model. WebSocket layers on top of TCP, considered as transport layer in TCP/IP model, and one can layer application layer protocol on top of WebSocket.
HTTP, SSL, HTTPS, WebSockets, etc. are all application layer protocols.
But the OSI protocol stack doesn't apply to TCP/IP, which has its own layer model: same names, different functions. It isn't helpful to keep using the obsolete OSI stack as though it actually reflected any reality. It doesn't.
Only the Handshake is interpreted by https server by upgrade request. Apart from that Websocket is independent TCP-based protocol. So i would say host layer #4 and #7.
https://www.rfc-editor.org/rfc/rfc6455#page-11
L1 does not have a map where a cable is digged in the soil (how deep, where), nor in wich cable certain wires delivering information is flowing, or where is is layed in cable self, nor it dictates how cable is marked. L1 is only physical layer, not where and how the wires are layed. So L0 is needed.
L1: "The physical layer is responsible for the transmission and reception of unstructured raw data between a device and a physical transmission medium. It converts the digital bits into electrical, radio, or optical signals. Layer specifications define characteristics such as voltage levels, the timing of voltage changes, physical data rates, maximum transmission distances, modulation scheme, channel access method and physical connectors. This includes the layout of pins, voltages, line impedance, cable specifications, signal timing and frequency for wireless devices. Bit rate control is done at the physical layer and may define transmission mode as simplex, half duplex, and full duplex. The components of a physical layer can be described in terms of a network topology. Physical layer specifications are included in the specifications for the ubiquitous Bluetooth, Ethernet, and USB standards. An example of a less well-known physical layer specification would be for the CAN standard."
Why is it must that all interfaces (routers and bridges) involved support LRO/TSO technique ?
Routers don't. Bridges do.
External routers, hubs, switches or anything else that is externally connected to the network will not see the effects of TSO, only interfaces inside the device with TSO will experience any effects - it's a software thing.
A router is an external device which is connected to the network by ethernet cables, fibre optic cables, wireless comms etc. These communication mediums adhere to internation standards such as 803.2 for ethernet or 803.11 for wireless - they're hardware devices, and hardware devices have very strict rules on how they communicate.
A bridge is an internal software construct and is specific to your OS.
Let's use 803.2 (ethernet) and a linux host for an example.
An application calls for a socket to be created and then pushes a large data chunk into the socket. The linux kernel determines which interface this data should be transitted on. The kernel will next interrogate the driver for this interface to determine its capabilities, if the interface is TSO capable the kernel will pass an sk_buff with a single "template" header and a huge chunk of data (more than 1 packets worth) to the interface driver.
Let's consider a standard interface straight to a hardware NIC first:
Some interfaces have fake TSO (they segment the packet in the driver) and some have true TSO (the template header and data are passed to the hardware with minimal alterations). At this point ether the driver or the NIC hardware will convert this large segment of data into multiple, standard compliant, 803.2 ethernet frames, it is these compliant frames that an external device, such as a router, hub, switch, modem or other host will see on the wire.
Now let's consider several NICs behind a software bridge:
Although the kernel is aware of each NIC at a low level, the network stack is only aware of the bride, thus only capabilities that ALL of the underlying NICs have should be passed up to the bridge. If an sk_buff is passed to a bridge, then ALL the interfaces in the bridge will receive the same sk_buff. We'll assume that the kernal has once again passed our large TSO sk_buff to a bridge, if any of the underlying interfaces does not support TSO then the packet will most likely be dropped by the hardware NIC in question.
In summary:
Worst case scenario is the bridge will repeatedly retry to send the same data chunk on the broken interface and the whole bridge will lock up until the application decides to give up. Best case scenario, the non TSO NIC will simply appear to be dead.
That said, if the NIC has unsafe code in its driver then this could cause a segmentation fault that could bring the whole system down.