Frame formats | Networking tutorial (6 of 13)

[@tomhyatt345]

Seriously these videos are second to NONE. I am amazed at how your break this stuff down. For someone that wants a FULL understanding this is it!

[@paradoxicallyexcellent5138]

When you learn about the internet from the bottom up like this, you start to appreciate the fact that security and encryption is totally necessary, because there's no magical bit of hardware that let's someone send a bit of information with the guarantee that no one else is listening to that bit.

[@gFamWeb]

this ^ Honestly, I see it just as a fact of life that security is deliberate. A door can exist without a lock. Clothes can exist without being armor. It doesn't translate fully, but yeah.

[@thomasb1205]

I've been waiting to comment on how good these videos are. I was going to wait until I finished the playlist but I had to stop and comment because it's so good. I've learnt more about the higher level understanding of networks here in a few videos than an entire semester at university.

[@ozzpimp]

I've been trying to learn this on my own my whole life, these videos are incredible. Subscribed.

[@davehouser1]

Thank you for these videos. I have been in IT for over 15 years, and these videos really break down an understanding of how frames / packets really work. I found it helpful to follow along with some old Wireshark traces I had. I can see everything your discussing in a frame / packet. Never thought I would need the "Bytes View" till now :)

[@acpcardoso]

this series of videos is amazing, thank you so much for doing this with so much quality, i've learned a lot.

[@andie_pants]

I'm a civilian IT contractor for the USAF, and I'm recommending this video series to everybody who'll listen. And a few who'd probably rather not, but tough cookies. :-P

[@gloverelaxis]

congrats on helping to kill poor people for money!

[@andie_pants]

@gloverelaxis Thanks! 😚

[@rainerwahnsinn3262]

Awesome video series! Your explanations are so clear and understandable. Its perfect for learning! The one thing I was missing was a mention about the problems when transmiting data back and forth. We can't just transmit data whenever we want, but need to wait until the line is free, because signals (light waves, voltages, etc.) interfere and so having two computers transmit at the same time makes signals useless for all. As simple as this may sound, this introduces some complexity. For example, a signal takes some time until it reaches another computer, since it propagates with finite speed (the speed of light is still finite!). If another computer starts to transmit after you started a transmission but before your signal reached it, meaning it started while the line appeared to be free because your signal hasn't reached it yet, we have a collision and need to start over again. The collision handling using random wait times is quite clever, since you can't just tell the other computer "Wait, I'll go first", without having the basis for any communication. This is also a reason why the payload needs to have a minimum length, such that in case of a collision the signals reach both sender and receiver even in a long wire, such that both are aware of the collision and can start the collision handling. Here is a nice explanation on collision handling: en.wikiversity.org/wiki/Web_Science/Part1:_Foundations_of_the_web/Ethernet/Collision_detection

[@champion_life]

I am happy to see a video on youtube that explains the frame format in a simple way. However, you could have explained or given a brief about preamble/SFD in this as well as said some additional points about the ether type ( ex: pause frame format and what data ether type will hold in that case). Anyway, this is a really useful video. Keep up the good work!!

[@deveshsingh4214]

I think he did say about the preamble in his previous video, here:- kzbin.info/www/bejne/rqO5f2yggM98gbM

[@beautifulheartsoothingreci28]

Ben Eater u are just BRILLIANT at explaining this stuff! Keep going with ur amazing work! Cheers :)

[@jessecox8486]

Thanks for this! I'm creating a P2P social network over wireless ad-hoc and Linux. This has been amazing for finding everything I need.

[@galier2]

The address field on PPP was sometimes used to do multiplexing of virtual connections. In my former company in the 90 we built a ISDL router that could transmit data via a single PPP link. We had a Unix server on one side (in West-Germany) with 4 RS-232 ports à 19200 bps, they would enter our router, multiplexed on the PPP link over ISDL, so 128 KBps and demultiplexed on the other side (in East Germany) where 4 terminals were hooked on the router. The address field allowed to distinguish the 4 virtual channels. Worked a charm and was easy to implement.

[@Lalechugadeldia]

This series is gold! Keep up the good work

[@krisbis]

Wow! I'm so glad to have landed on your channel Ben. I have enjoyed every bit of all your networking tutorial series. Great details, great explanation. Your videos should be considered as golden standards for any educational purpose. I would like to keep in touch with you incase you plan to start anything around Cybersecurity.

[@sergiip619]

you saved me from reading hundreds pages of nonsense. this is as clear as it can get

[@menyasavut3959]

that's pretty ignorant. I suggest to read through hundred pages of RFCs and various other books (the things you call nonsense). do you seriously think you understand networking because you watched a 9 minute video?

[@codychhay6665]

I love your videos. They are super helpful. Please make more videos for example on Hamming distance, Error detection and correction... Cheers

[@arsnakehert]

The ACM or IEEE should create a prize for recognizing people spreading computer and electronics knowledge on the internet, and they should inaugurate it giving it to this guy

[@mattt2684]

You are an excellent teacher!

[@Felipe-53]

the sheer quality of these videos 😍😍😍😍😍

[@PankajKumar-zr3tv]

Ben...could we talk over Gmail? You are the best teacher I have ever got.

[@scienceblossom6197]

Very awesome tutorial really. This channel is a treasure! One

[@nemusmaximus9583]

Thank you for taking the time to teach us.

[@EvilSandwich]

My wife, after watching this: "But if it's only 6 bytes, won't we eventually run out of MAC addresses?" Me, knowing full well the sheer size of 2^48: Oh... Oh, you sweet summer child...

[@swiftlyexplained703]

Thanks for making such informative content free!

[@javierbg1995]

I have a question about the PPP frame format that was shown. In the diagram it is shown that the frame starts and finishes with this special code "01111110". As you explained earlier this is used for syncronization of both ends, so whenever you hear this "01111110" string you know it's the start of a frame. When this happens inside the frame, like you explained, a bit is "sutffed" in between to break the sequence, and so if the reciever starts hearing midway through they won't be confused. My question is: what if the reciever starts hearing midway through (say, during the payload) and then hears the "01111110" finishing the frame? Wouldn't they interpret it as the start of a new frame?

[@corollayanki4832]

Then right after this the receiver will hear another "01111110" for the start of another frame. I wonder if the receiver will realize it missed a frame. I know the first frame will be corrupted and dropped and or some higher level protocol like TCP (layer 4) will check for corrupted data and request a resend. If not TCP, then there will be something on the upper level that will realize the data is bad and will initiate another request. But I think there will be an ARP or some other frame sent first to make sure the destination MAC address exists on the network before sending frames with data in them. In communication, there's always a request and response to initiate the conversation first, so that the receiver is ready and listening. I think the reason for escaping every 5th one bit with a zero in the data portion is so the receiver doesn't interpret this as the end of the frame. I still wonder if the receiver will recognize it's off with reading the flags or not. Also, I'm still wondering about how bit stuffing works. So, it inserts a zero for ever 5th one, but isn't it modifying the data! But at the end of the data, when another flag is read, the receiver is probably smart enough to know there's extra bits added to its bytes of data (only 8 bits per byte of data, but bit stuffing will make a weird 9 or more bit for it's last byte). I know it's just an escape character like " \ ", but it would be nice to know how the receiver will parse through this and how it deals with picking up a frame halfway (should not happen due to the ARP or the first frame to initiate communication). Maybe I'm answering my own question. Also, PPP is used for ISP's and other point to point networks, so most of us will not have to deal with PPP. We will be using ethernet, with its preamble instead. Please correct me if I'm wrong about any of this.

[@corollayanki4832]

Oh, and the frame has its own Frame Check Sequence at the end, so this will probably let the receiver know that the frame is bad and it would hopefully request it again without having to go up the TCP/IP stack. The FCS is probably the answer. And we don't get to collisions yet. I need to read more. These videos are amazing and help me digest TCP/IP Illustrated by W. Richard Stevens better.

[@corollayanki4832]

It will not request another frame after comparing the FCS with the sender's! It just ignores it. Then the higher level protocols will have to deal with a missing frame. Should have finished watching the video first before responding, My bad.

[@corollayanki4832]

And, there's also a link control protocol or LCP used for PPP to establish, config, and test the connection before sending data. ARP is used on multipoint ethernet networks and is used to resolve IP address (layer 3) to MAC addresses (layer 2). In a point to point connection they don't even use the address field, because there's only two ends in this network. I kept thinking about ethernet frames during my first response, so please ignore my first answer.

[@MrNahazz]

this is far the best explanation for this stuff! thanks ben

[@leandrormor]

that's fantastic, you could do something like that about OS (specifically linux), it'd be awesomE

[@saquibkhan6498]

Awesome video just love the way you explained everything.

[@Aemilindore]

also we can use macchanger on linux to change the MAC to whatever we need :-) Excellent video!

[@nithyavasudevan272]

Dear Sir, I have watched almost every of your videos. I kindly request you to build a series on internet connection on the custom hardware like the 8 bit computer or the 6502 computer. I am currently building a 32 bit computer with vga output and a usb keyboard, mouse input. I am also planing to build an OS for it. From your kind subscriber. Thank you for your kind support.

[@mritunjayyadav3788]

first of all thanks for this awesome series . i have a question is there any hardware in our laptops or something which decode these signals into meaningful data or these are programs like drivers which do the decoding ?

[@retpolanne]

Thanks! I finally understood that framing is not rocket science :)

[@JamesPTG]

@ben eater which "Black board" software are you using to create your videos ? (who are btw amazing !)

[@abdullahahmed7781]

sketchbook express

[@darrylkid210]

If bit stuffing is done in PPP, then wouldn't there be an additional bit in the address field that's usually set to ff?

[@breakingkamelot]

5:35 was it suppose to be 64 because u said 64-1500 in the previous video. Thanx for the videos, they are really insightful.

[@Adam-wm3cn]

Probably not since 6 + 6 + 2 + 46 + 4 = 64 (which would then be the total minimum frame size like he said in the last video).

[@slaye2202]

Thank You for your series super useful!

[@PiyushRobotics]

YOU DEFINITELY DESERVE A SUB😄

[@nollix]

With regards to bit stuffing: A 0 is inserted into a bit string that looks like the flag so that it can't be mistaken for the flag. Okay. Now how do you know it's a stuffed bit string as opposed to an actual piece of data that looks identical to the bit stuffed flag? Doesn't this now run into the same problem?

[@silleetram]

these videos are amazing. ty ty ty!

[@moussatouhami7567]

4:18 i guess that the switch knows the MAC address of each computer on the network so it will pass the data only to the specific selected destination based on the MAC address

[@fabianalwis]

The switch has a MAC address table. By examining the incoming traffic via a given port and the source MAC address information in the traffic, it associates the port with the MAC address and updates this data in the table. The switch can then use this data to route frames as required.

[@fabianalwis]

​@@The-Fish Correct. The complete behavior is: (a) The switch maintains a MAC address table that maps the MAC address and the switch interface information to make switch forwarding decisions. (b) When an incoming frame is received, the switch examines the source MAC address. (c) If the MAC address is absent, the switch updates the MAC address and the interface information to the MAC address table as a new entry (d) If MAC address and interface information is already present, the age of the entry is reset. Typically, a MAC address entry is maintained for 300 seconds and will be removed upon expiry. (e) If the MAC address is present, but under a different interface, the switch will purge the existing entry and create a new entry for the MAC address under the current interface (look up MAC flapping). There will only be one occurrence of a MAC address value in the MAC address table. However, a switch interface may have several MAC addresses registered as the interface could be connected to another switch that serves multiple hosts.

[@Chaos1373]

Out of curiosity, how do the 6 bytes in the MAC address get converted into a pair of letters/numbers each, instead of just a single value?

[@SoaringSuccubus]

Why is it required to flag both the beginning and the ending of a frame in PPP, when in ethernet it was enough to merely mark the beginning of each frame?

[@ryzenrog1139]

Hey ! What software is he using to draw ?

[@TheGiantHog]

So the payload is run through a hash algorithm for the frame check sequence?

[@chitoiup]

What interprets the ethernet data format? Is it the operating system, the hardware (ethernet card), or something else?

[@eamorimjr]

+chitoiup it is the protocol stack inside operating system, nowadays IP stack...

[@tdya1]

Great video Would you mind if i ask about the software you are using for these videos. I mean the black canvas you write on.

[@justinli19901027]

love the series. thank you

[@littlenarwhal3914]

Wouldnt the frame check sequence be the same across different messages? The capacity for being unique of it is 2^32 while the capacity for the message to be unique can go up to more than 2^10000... how can the frame check sequence account a different computation for all messages?

[@teakew8217]

Imagine you're painting a map of the world but you only have five colours of paint. You want to make sure that there's no confusing borders where both the countries along that border use the same colour. Obviously there's a lot more than five countries - but it doesn't matter whether two countries that aren't near each other use the same colour. So I can't paint France and Germany both in blue, but I can paint France and Poland in blue, and Germany in red. Errors in transmission (unless your link is complete garbage) will normally lead to relatively small changes in the message - a few bits or bytes get read incorrectly, etc. Because of this, you don't need to account for all possible messages having a unique frame check sequence. It's sufficient that the frame check for a given message is different to the frame check for any message it can be corrupted into. In IP, checksums (which are a type of hash function) are normally used for this. Hash functions have the property that a small change to the input (in this case, the message in the frame) will result in a large change to the output (in this case, the frame check sequence). A _large_ change to the input can result in the same output (this is known as a hash collision), but for a well chosen hash function the chance of this happening from an error in transmission should be very small.

[@guilhermebaird7910]

How do you know the computer's MAC address that you want to send the message?

[@havehalkow]

Is Ether Type part of the frame somehow related to TCP/IP Port number?

[@Felipe-53]

You are the best!

[@pagola]

so ethernet frames don't deal with logical ip addresses?

[@magicpeterpalmer]

Correct me if I‘m wrong, but shouldn‘t a Switch Send packages that are adressed to a certain mac adress only to this network interface they are adressed to instead of sending it to everyone?

[@Fergobirck]

MagicPeterPalmer Yes, that is correct. A switch mantains an internal addressing table and only sends packets to the destination on a specific Ethernet port. The behavior described by the author is common to a hub, which is a "dumb" device that broadcasts all packages it receives to all nodes connected to it.

[@gabiold]

@@Fergobirck While it is true, it is good to know that if the switch haven't seen that destination MAC yet, it does not know which port to sent it on, so it broadcastas on all ports. Then if the target responds back, it remembers on which port was it. It is also interesting that one port could connect to other downlink switch, so in reality there could be any number of destinations on a port. Any half-decent switch nowadays could remember enough MAC addresses per port so you probably never have to care with this, but it's still works behind the scenes.

[@torinstorkey]

How does a computer know what frame type it just received?

[@strssko]

why these addresses are so long? why for example 4 bytes arent enough?

[@tsmupdatertsm7633]

Lets say you transmitt a payload of 1500bytes. What is the chance of getting a correct frame check although you know that your payload has wrong bits inside ? (If the right bits are flipped it gets a worng positive frame check). I cannot beleve that this is possible, we use data-transmission for everything. I feel we need to be absolutely sure that we receiving the correct data.

[@gabiold]

If the payload is a TCP/IP packet, then the IP header has a 16 bit checksum too. Then the underlying TCP also has 16 bit checksum for the header. You probably could find a collision where the ethernet payload would check against the FCS, but that payload probably will not be a valid IP packet and/or valid TCP packet, because the inner checksums will not match. So the ethernet layer will not drop the frame, but the TCP/IP stack will. And there are other sanity checks. For example, you maybe find a collision, but the destination address will be something random. If the destination interface gets this packet, although it is valid, it will ignore it as it's address isn't match address in the frame. The same could apply to one layer up in the TCP/IP stack. If IP spoofing protection is enabled, the stack drops all packets whose IP address isn't belong to the interface it received on. And on and on and on... In the real world, most of the time you won't rely on a single thing, any well-written computer software consists of 70% of error and consistency checking and 30% of solving the actual problem.

[@afshinommi1682]

Is mac address different from ip address?

[@anupambhatt4825]

Yes totally. MAC address is baked into the hardware (Network interface / ethernet card). It does not change. IP address is a virtual addressing concept. A computer or network connected hardware can be assigned any ip address when the network connection is established.

[@amnest1ac]

Indeed, it is baked into the hardware. This said, it's not true that it cannot be changed. It can.

[@gabiold]

@@amnest1ac He said it doesn't change, not can not be changed. While it can be (if the network interface allows you to do), practically you very rarely ever have to change it, because it doesn't matter (that much) in typical networks. In 'that much' I mean, you could use the MAC for serving fixed IP address using DHCP or filtering traffic based on the MAC, or prohibiting a switch port to talk to any other MAC you specified... And almost all the time if you ever want to change it, it is becaue you want to cheat on these security features. 😉

[@ivanpiro999]

5:42 "EtherVegeta, what the oscilloscope says about the payload size?" "IT'S OVER EIGHT THOOOUSAAAAND" (sorry.)

[@JT-nq9vh]

Thank you Ben

[@hirbodkhatami9906]

amazing you are

[@TheOneWhoHasWallnuts]

you can actually choose the MAC address on many cards (these days anyways)

[@fwang3695]

how to know payload length?

[@marvellousx4421]

up主很厉害。

[@karthikmahadevaiyer]

Ben, can you please teach us Anycast and BGP ?

[@LunaMarlowe327]

awesome

[@munirfrehmand6784]

thanks alot

[@ramirez368]

Payload is the data??

[@stephanekundig2126]

Yes

[@retpolanne]

Here's a sort of an analogy: the tank of a gas truck is full of fuel. The fuel is actually called the payload and it is "encapsulated" by the tank. Same goes with networking, the payload is what is "interesting" to some application.

[@3iggystheorem232]

good

[@sundhaug92]

Note: Ethernet addresses aren't always unique

[@arnavgarg7662]

pee pee pee hehe

[@leoyousif1]

I need to send you money