I am studying VLAN. After hours of searching, I know 802.1Q doesn't encapsulate the original frame, instead it adds a 32-bit field between the source MAC address and the“EtherType” field of the original frame. But I can't figure out why. Can somebody explain to me why 802.1Q doesn't encapsulate the original frame? Thanks a lot.
The predecessor to 802.1q was Cisco's ISL. ISL did fully encapsulate the frame. Which means when any device was receiving an ISL frame, it must be able to understand the ISL tag, or else the whole frame is considered malformed.
In 802.1q, the first 12 bytes of the frame, whether it is tagged or not, is always the same.
To illustrate exactly what the tag modifies, here is the Packet Capture of a frame without the tag, then the same frame with the tag:
The bracketed portion in orange is all from the original frame. The bracketed portion in green is what the 802.1q tag adds to the frame.
Notice that in both cases, the first 12 bytes are the Destination MAC address and the Source MAC address.
Moreover, in both cases, the next 2 bytes of the frame are a "EtherType" field, which indicate the next protocol encapsulated in the datagram.
This means that whether a transit device understands 802.1q tags or not, the processing for that frame does not change. Which means 802.1q tags will still "work" through a device that...
is older, and doesn't support or understand 802.1q tags
is not configured to read/look for a particular tag
is built to only inspect the first 12 bytes of any frame so it can make a line-speed decision on how to forward the packet, which is the strategy in Cut-Through switching.
Overall, it allows the implementation and standardization of VLANs and VLAN Tagging without having to patch every device ever created that does Layer 2 processing to teach them how to interpret a "fully encapsulated VLAN tagging strategy" (like ISL). Instead, the devices that need to support VLANs can be patched to understand 802.1q, and all the other devices in transit can simply continue to operate without any fuss.
Granted, these days it is pretty rare to come across a host or switch that doesn't understand VLANs, but consider it from the perspective from when the concept of VLANs and Tagging were first invented.
Related
When a computer X sends data through a network to computer Y the data goes down through the OSI layer. This is ok. I understand. But once the data is put on the media as eletric signals then how does the computer Y know what to reassmble, given the headers and trailers of the data model generated in OSI, once it is put on the electric media at layer 1 does not exist any more?
The physical layer is just 1's and 0's as you say - the trick is that there is a pattern that tells the receiver that this is the start of a packet. This is usual referred to as 'Framing'.
Once the receiver knows that, it simply reads in as many bits as its needs for the Layer 2 header and it then has that and so on.
The headers are clear in a typical OSI or networking diagrams, e.g. (https://www.ciscopress.com/articles/article.asp?p=2738463):
So the way the first two layers work on the receiver is:
layer 1 just recognises whether the signal is a one or a zero and creates the stream of ones and zeros.
layer 2 reads this stream and when it recognises the start pattern it then know the following bits are the header and so on and hence it can identify the frames.
You can see examples of start and stop patterns online e.g. (http://sinauonline.50webs.com/Cisco/Cisco%20Exploration%20Sem1Chap7.html):
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
I would like to know how to capture packets of a specific wireless network using wireshark.
I'm already able to capture all packets of different networks setting my wireless card in monitor mode but for a specific analysis i need to discard all the packets not related to my network during the capture procedure.
I know that exists display filters to do that but i need to filter them ahead (like with capture filters).
If i go to CAPTURE->OPTIONS i can set capture filters but i don't know the exact filter because they are different from display filter infact wlan.bssid==xx:xx:xx:xx:xx:xx
does not work.
any suggestions?
thanks
You could use an index from the start of the wlan packet.
It needs some coaxing, but the BSSID field is in a fixed, predictable position. By using brackets, you should be able to reference the proper positions in the packet.
The BSSID is at position 16, so if you wanted to emulate something like:
wlan.bssid=12:34:56:78:9a:bc
you would have to do something like this:
wlan[16:4] == 0x12345678 and wlan[20:2] == 0x9abc
You have to convert the first 4 octets into a int32 and the last 2 into an int16 and use 2 clauses, as BPF cannot express a 6 byte number, but I've used it and it works fine. This can also be adapted to other uses as well (you just need the offset).
Excellent question and something I've been trying to figure out also.
The short answer is the wireshark tools cannot filter on BSSID. Wireshark uses pcap, which uses the kernel Linux Socker Filter (based on BPF) via the SO_ATTACH_FILTER ioctl. There is no BPF filter for BSSID.
Another tool, airodump-ng, CAN capture by BSSID because it passes all 802.11 frames into user space and decodes/filters frames there. It works surprisingly well considering all the user-space processing.
But even a low-volume 80211 network is fairly noisy. For example, my SOHO captures 11K frames in under two minutes; and I still drop frames. Grabbing all the 80211 frames for the five visible (but small!) BSSIDs near me and I receive 141K frames (104MB) in just under three minutes.
I'm looking to do an embedded frame sniffer/injector using EMMC or SD flash so I need to be careful about pushing the limits.
So I'm trying to write a custom BDF filter to filter only the local BSSID frames. And I hope to extend it to drop a good amount of the "noisy" frames - most of the control and management frames can be filtered.
The BSSID address location in the frame is based on ToDS and FromDS control bits.
Anyway, hope I provided some breadcrumbs to the solution. It may just be an airodump user-space solution is the easiest.
There are a few things I don't understand about 64/66bit encoding, and failed to find the answers to on the web. Any help/links would be greatly appreciated:
i) how is the start of a frame recognised? I don't think it can be by the initial 10/01 bits called the preamble on wikipedia because you cannot tell them apart (if an idle link is 0, then 0000 10 and 000 01 0 look rather similar). I expect the end of a frame is indicated by a control word, with the rest of the bits perhaps used for the CRC?
ii) how do the scramblers synchronise, and how do they avoid scrambling the same packet the same way? Or to put this another way, why is not possible for a malicious user to induce substantial packet loss by carefully choosing a bad message?
iii) this might have been answered in ii), but if a packet is sent to a switch, and then onto another host, is it scrambled the same way both times?
Once again, many thanks in advance
Layers
First of all the OSI model needs to be clear.
The ethernet frame is a data link layer, while the 64b/66b encoding is part of the physical layer (More precisely the PCS of the physical layer)
The physical layer doesn't know anything about the start of a frame. It sees only data. (The start of an ethernet frame are data bytes which contain the preamble.)
64b/66b encoding
Now let's assume that the link is up and running.
In this case the idle link is not full of '0'-s. (In that case the link wouldn't be self-synchronous) Idle messages (idle characters and/or synchronization blocks ie control information) are sent over the idle link. (The control information encoded with 0b10 preamble) (This is why the emitted spectrum and power dissipation don't depend on if the link is in idle state or not)
So a start of a new frame acts like following:
The link sends idle information. (with 0b10 preamble)
Upper layer (data link layer) sends the frame (in 64bit chunks of data) to physical layer.
The physical layer sends the data (with 0b01 preamble) over the link.
(Note that physical layer frequently inserts control (sync) symbols into the raw frame even during a data burst)
Synchronization
Before data transmission 64b/66b encoded lane must be initialized. This initialization includes the lane initialization which the block synchronization. Xilinx's Aurora's specification (P34) is an example of link initialization.
Briefly receiver tries to match the sync character in different bit-position, and when it match multiple times it reports link-up.
Note, that the 64b/66b encoding uses self-synchronous scrambler. This is why the scrambler (itself) doesn't need to know anything about where we are in the data stream. If you run a self-synchronous (de-)scrambler long enough, it produces the decoded bit stream.
Maliciousness
Note, that 64b/66b encoding is not an encryption. This scrambling won't protect you from eavesdropping/tamper. (Encryption should placed at higher level of the OSI model)
Same packet multiple times
Because the scrambler is in different state/seed when you sending the same packet second time, the two encoded packet will differ. (Theoretically we can creates packets, which sets back the shift register of the scramble, but we need to consider the control symbols, so practically this is impossible.)
The Ethernet II frame format does not contain a length field, and I'd like to understand how the end of a frame can be detected without it.
Unfortunately, I have no idea of physics, but the following sounds reasonable to me: we assume that Layer 1 (Physical Layer) provides us with a way of transmitting raw bits in such a way that it is possible to distinguish between the situation where bits are being sent and the situation where nothing is sent (if digital data was coded into analog signals via phase modulation, this would be true, for example - but I don't know if this is really what's done). In this case, an ethernet card could simply wait until a certain time intervall occurs where no more bits are being transmitted, and then decide that the frame transmission has to be finished.
Is this really what's happening?
If yes: where can I find these things, and what are common values for the length of "certain time intervall"? Why does IEEE 802.3 have a length field?
If not: how is it done instead?
Thank you for your help!
Hanno
Your assumption is right. The length field inside the frame is not needed for layer1.
Layer1 uses other means to detect the end of a frame which vary depending on the type of physical layer.
with 10Base-T a frame is followed by a TP_IDL waveform. The lack of further Manchester coded data bits can be detected.
with 100Base-T a frame is ended with an End of Stream Delimiter bit pattern that may not occur in payload data (because of its 4B/5B encoding).
A rough description you can find e.g. here:
http://ww1.microchip.com/downloads/en/AppNotes/01120a.pdf "Ethernet Theory of Operation"