Show HN: I made an Ethernet transceiver from logic gates(imihajlov.tk)
imihajlov.tk
Show HN: I made an Ethernet transceiver from logic gates
https://imihajlov.tk/blog/posts/eth-to-spi/
89 comments
I know of exactly one site which had a .tk TLD. Here’s why they switched to a .com in 2005:
https://tailsteak.com/archive.php?num=388
“tailsteak.com
Alright, so I'm finally fed up with Tokelau.
Don't get me wrong, it's a nice island, but they just aren't answering my mail.
I suppose most of you have noticed, by now, the fifteen-second ads that present you with beautiful women and fish when you surf to tailsteak.tk. Those are not my ads. I do not obtain revenue from them. Tokelau's domain name referral service just started putting them up there without so much as a by-your-leave. I have contacted their tech support and enquired if, perhaps, they might consider removing them for customers willing to pay a certain amount. They have not responded.
Of course, I have had access to tailsteak.com for some time now. So henceforth, I will be directing my viewers there. It's the same site, the same host, and, in truth, the .tk address has been sending you there for months. But now it's official. Note the change in title graphic:
tailsteak.com”
https://tailsteak.com/archive.php?num=388
“tailsteak.com
Alright, so I'm finally fed up with Tokelau.
Don't get me wrong, it's a nice island, but they just aren't answering my mail.
I suppose most of you have noticed, by now, the fifteen-second ads that present you with beautiful women and fish when you surf to tailsteak.tk. Those are not my ads. I do not obtain revenue from them. Tokelau's domain name referral service just started putting them up there without so much as a by-your-leave. I have contacted their tech support and enquired if, perhaps, they might consider removing them for customers willing to pay a certain amount. They have not responded.
Of course, I have had access to tailsteak.com for some time now. So henceforth, I will be directing my viewers there. It's the same site, the same host, and, in truth, the .tk address has been sending you there for months. But now it's official. Note the change in title graphic:
tailsteak.com”
Yeah. Cheap TLDs are very strongly correlated with spam.
Although I think .icu and .xyz are far bigger offenders than .tk these days.
Although I think .icu and .xyz are far bigger offenders than .tk these days.
Is it worth it though? Renewing a domain is yet another bottomless pit you throw money into, along with server hosting. For a site without ads or other revenue it's just more expense.
It very well might be, if you value publicity for your hobby, the greater reach might be worth it to you. If you can get 10,000 readers instead of 90 readers because your links are shareable...
If we think about potential dollars, though:
The bottomless pit isn't very deep, it's a few dollars a year.
If it nets you one single short-contract offer (nevermind a job) or worthwhile contact because someone found your work, it'll pay itself off many, many times over. Let's say one person found him and offered him a $3000 contract to do some electronic thing for a week, well, then the cost of the domain and hosting won't matter for the rest of his life.
The mere fact that this guy has an oscilloscope out means he has skills that someone might want to contact him about in relation to his blog.
Limiting yourself for want of a $10/year domain name is probably not a great idea, and again, it's something I learned the hard way.
If we think about potential dollars, though:
The bottomless pit isn't very deep, it's a few dollars a year.
If it nets you one single short-contract offer (nevermind a job) or worthwhile contact because someone found your work, it'll pay itself off many, many times over. Let's say one person found him and offered him a $3000 contract to do some electronic thing for a week, well, then the cost of the domain and hosting won't matter for the rest of his life.
The mere fact that this guy has an oscilloscope out means he has skills that someone might want to contact him about in relation to his blog.
Limiting yourself for want of a $10/year domain name is probably not a great idea, and again, it's something I learned the hard way.
[deleted]
The thing with TK is, it costs nothing upfront, but the internet is bursting with countless reports that if your site eventually becomes popular, TK domain admins might outright snatch it from you for their own ads, without the possibility of seeking retribution as it's all in their TOS ...
https://getfreedomain.name/domain/tk/
imihajlov.com would cost around 10 USD per month and as another reply mentioned, static site hosting is free. I guess it's a bottomless pit but it's "only" 10 USD and it's nice to have.
Surely you mean 10USD per year? If you are paying that per month just for the domain you are being ripped off :)
Correct, I meant per year
Sure, but that would add up to $1200 in a decade of hosting which is substantial and the timespan one'd likely run it for. People buy a $1k PC every 5 years and consider it a large expense, why not this?
I can find it for much lower though, like $8/year? Then again that's on namecheap who then raise rates when you go in to renew lol.
I can find it for much lower though, like $8/year? Then again that's on namecheap who then raise rates when you go in to renew lol.
I'm sure GP meant /year, not month. Pricing's always (as far as I've ever seen) per year for one thing, but also it's not 120 (or more) unless your name's Ford or something. (Damn it.)
The site is already being hosted, I was only talking about a domain name, so at ~$10/year or whatever it is now, that's only $100 a decade over whatever he is paying now for hosting using a free domain.
That's 10 years of benefiting from a real domain name for the cost of... a very long list of pointless $100 goods and services.
It's a couple of cents per day.
That's 10 years of benefiting from a real domain name for the cost of... a very long list of pointless $100 goods and services.
It's a couple of cents per day.
A .com domain for US$10 per *month*? That doesn't round right, it's not even that per year.
Yeah but what if it’s a cool domain? Then it’s a cool bottomless pit.
I need to find something to do with onlyfandans.com, even if it's probably only funny in Scotland.
The cooler the name, the deeper the pit.
I’m very proud of my site (and the URL) reboot dot love, which I haven’t done much with lately but I want to! Also yeah I need to fix my SSL cert. the server is giving me grief. Bottomless pit of time and money yaaay.
SSL certs can be free and auto-renewing. set and forget
Yep. Server is just having some weird issues. I’m using Lets Encrypt but something isn’t right.
Static hosting can be found free on sites like gatsby.
Ok yeah now that I think about it there are ways to host for free, github pages also comes to mind. Not exactly elegant solutions though. Makes the domain expense even worse in that respect.
> Not exactly elegant solutions though.
How come? I think services like GitHub pages are a great way to host a static site.
How come? I think services like GitHub pages are a great way to host a static site.
By large you tend to be severely limited by size and traffic. Github's also very slow to update changes and can't host private repos either.
I remember using 000webhost back in the day, their free plan had an uptime of "maybe". It was never up when I actually needed it.
I remember using 000webhost back in the day, their free plan had an uptime of "maybe". It was never up when I actually needed it.
Standard domains (com/net/org) are super cheap, around $1 per month.
This is a wonderful project! I'm old enough to remember the days when Ethernet adapters for commercial computers were made of individual logic gates. The Ethernet adapter in the VAX 11/750 I used in the early 80's was two large Unibus boards full of TTL logic: http://gunkies.org/wiki/Digital_Ethernet_UNIBUS_Network_Adap...
This blog post dives into another mostly TTL logic Ethernet board from the Xerox Alto: https://www.righto.com/2017/11/fixing-ethernet-board-from-vi...
It has a nice high level diagram of what each group of TTL chips is doing too:
https://lh3.googleusercontent.com/-DpUyda3g2Yk/WgB7G_7o54I/A...
It has a nice high level diagram of what each group of TTL chips is doing too:
https://lh3.googleusercontent.com/-DpUyda3g2Yk/WgB7G_7o54I/A...
The one that superseded that, the DELUA adaptor, was powered by a 68000 CPU that was generally faster than the machine hosting it :-D
That is crazy, the amount of space a network adapter took up.
First PC network card was only slightly smaller :)
3Com 10Mbps Ethernet 3C500 aka IBM Ethernet (IE) aka EtherLink from October 1982
https://static.wixstatic.com/media/a03cac_005e3e9eb62b47c292...
3Com 10Mbps Ethernet 3C500 aka IBM Ethernet (IE) aka EtherLink from October 1982
https://static.wixstatic.com/media/a03cac_005e3e9eb62b47c292...
And there were a few more boards for the disk controller, and another couple for the display controller…
Not to mention all the boards that the CPUs and RAM took up. Here's a nice photo of the insides of a VAX 11/780 - if you enlarge it all the way you can see the annotations showing which boards do what: https://upload.wikimedia.org/wikipedia/commons/e/ec/SPEC-1_V...
Note that those 16 huge memory boards each held 256K (kilobytes!) for a total of 4M of RAM.
Photo with people to show size of cabinets: https://photovault.com/363660
Note that those 16 huge memory boards each held 256K (kilobytes!) for a total of 4M of RAM.
Photo with people to show size of cabinets: https://photovault.com/363660
It’s always surprising to look back at these things, because it hardly seems like it would be economical to build and deliver such a huge monstrosity.
When the alternative is nothing or paying a lot of money for something you need to make a lot of money, people will pay a lot of money. It still crazy though. The 80s don't seem that long ago.
What a mervell of retro-computing. I think the author should definitely contact Ben Eater, as this is an excellent material for the next video.
Aside from this, Arduino shields for Ethernet are available for quite some time, but they often contain the more advanced chip than the atmega328p itself. Here OTOH the author builds from the ground up. Simply amazing!
That being said, I think most of the ppl that are serious about their arduino networking will use CAN as their network of choice (https://en.wikipedia.org/wiki/CAN_bus).
Aside from this, Arduino shields for Ethernet are available for quite some time, but they often contain the more advanced chip than the atmega328p itself. Here OTOH the author builds from the ground up. Simply amazing!
That being said, I think most of the ppl that are serious about their arduino networking will use CAN as their network of choice (https://en.wikipedia.org/wiki/CAN_bus).
Oh wow.
I had thought this was, "I simulated it in a high level HDL and synthesized it to gates".
No, this is... I built it with physical chips. Brilliant build and write-up!
Edit: This is beautiful for a second reason... The lack of regard for doing things "correctly". The ugly clock circuit is horrifically unreliable... But just reliable enough for it to still work.
It reminds me of Muntzing.
https://en.wikipedia.org/wiki/Muntzing
I had thought this was, "I simulated it in a high level HDL and synthesized it to gates".
No, this is... I built it with physical chips. Brilliant build and write-up!
Edit: This is beautiful for a second reason... The lack of regard for doing things "correctly". The ugly clock circuit is horrifically unreliable... But just reliable enough for it to still work.
It reminds me of Muntzing.
https://en.wikipedia.org/wiki/Muntzing
So all I need are link pulses to fake the other end of an Ethernet connection to keep it alive?
This makes building a data diode much simpler than I thought it needed to be. Thanks!
This makes building a data diode much simpler than I thought it needed to be. Thanks!
Yes, but this is only the case with 10BASE-T. Modern standards use more complicated Fast Link Pulses.
Also applies to 100Base-T which is still a usable solution for basic networking.
Wow, this is fantastic! I had a couple of questions. The author states:
>"According to the 10BASE-T spec, each frame starts with a fixed synchronization sequence of 64 bits, first 62 of which are alternating ones and zeroes and the last two are ones."
I believe the intention of the "preamble" is to provide clocking and synchronization for the circuit so that it knows where to find the start frame delimiter and subsequent fields. Is that correct?
My other question is at what point does the circuit drop frames that are not intended for it? Does that happen in layer 1 or layer 2? I realize this happens less in modern switched Ethernet networks but it is still possible for a host to get an Ethernet frame for where the destination MAC address does not match any of those burned-in addresses on the Ethernet adapter. Does the transceiver always read the entire Ethernet frame even when the destination MAC address field it reads is incorrect? The maximum Ethernet frame size is 1518 bytes which seems like a lot of data read if the MAC address is not valid for the host.
>"According to the 10BASE-T spec, each frame starts with a fixed synchronization sequence of 64 bits, first 62 of which are alternating ones and zeroes and the last two are ones."
I believe the intention of the "preamble" is to provide clocking and synchronization for the circuit so that it knows where to find the start frame delimiter and subsequent fields. Is that correct?
My other question is at what point does the circuit drop frames that are not intended for it? Does that happen in layer 1 or layer 2? I realize this happens less in modern switched Ethernet networks but it is still possible for a host to get an Ethernet frame for where the destination MAC address does not match any of those burned-in addresses on the Ethernet adapter. Does the transceiver always read the entire Ethernet frame even when the destination MAC address field it reads is incorrect? The maximum Ethernet frame size is 1518 bytes which seems like a lot of data read if the MAC address is not valid for the host.
Imagine you had 2 transceivers you wanted to bridge - if the transceiver dropped all unicast MACs but its own indiscriminately then it would not function properly. There is also a litany of other features that would not want this kind of offload always running (general MAC spoofing, packet capturing for debug/troubleshooting purposes, VMs, some IP redundancy protocols that keep the virtual IP's MAC consistent after failover, and the like).
Offloads such as this or other more advanced ones are implemented as optional hardware features (if at all) controlled by upstream signaling. This is usually a driver signaling things over a PCIe bus on modern systems but it can be anything including just "upstream logic gates". That way if it's a normal client-only PC not running e.g. Wireshark or VMs the CPU doesn't have to be interrupted for the types of traffic you mention but the other use cases can still work too.
Offloads such as this or other more advanced ones are implemented as optional hardware features (if at all) controlled by upstream signaling. This is usually a driver signaling things over a PCIe bus on modern systems but it can be anything including just "upstream logic gates". That way if it's a normal client-only PC not running e.g. Wireshark or VMs the CPU doesn't have to be interrupted for the types of traffic you mention but the other use cases can still work too.
Thanks, that makes perfect sense about things like VRRP and proxy arp, indeed they wouldn't work if the transceiver filtered on the destination MAC field of the Ethernet frame. I'm guessing this is exactly why this stuff is handled at L2 and in the kernel module for the NIC? I didn't understand your first example though:
>"Imagine you had 2 transceivers you wanted to bridge - if the transceiver dropped all unicast MACs but its own indiscriminately then it would not function properly"
I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
>"Offloads such as this or other more advanced ones are implemented as optional hardware features (if at all) controlled by upstream signaling."
Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
>"Imagine you had 2 transceivers you wanted to bridge - if the transceiver dropped all unicast MACs but its own indiscriminately then it would not function properly"
I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
>"Offloads such as this or other more advanced ones are implemented as optional hardware features (if at all) controlled by upstream signaling."
Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
> Thanks
Thank you! I love talking about bits and bytes on the network wire and it feels like I get to do it less and less the farther I get into my career... funny how that works. At least I haven't been moved into management yet!
> I'm guessing this is exactly why this stuff is handled at L2 and in the kernel module for the NIC?
Yep, generally the OS driver has a backup version of logic to handle everything beyond "packet receive" and "packet send" for exactly these kinds of reasons. On Linux you or any program with the rights can disable NIC filtering offloads by setting an interface to promiscuous e.g. "ip link set eth1 promisc on" and the packets all get punted to the CPU like it was a base level dumb NIC. Pulling an example early here is a patch making sure the broadcom driver for the NIC in the Raspberry Pi actually listens to this declaration and disables the ARP & ND filtering offloads https://patchwork.kernel.org/project/linux-wireless/patch/15...
> I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging.
Ideally the device (either NIC offload or upstream OS/further hardware logic) does some MAC learning as the above conversation goes on so things don't always remain unknown flooding past the first exchange but technically just forwarding the frame out all interfaces in the bridge group is valid too (just extremely inefficient). It's also worth noting usually in the real world higher layer discovery (like 2 IP addresses ARPing for each-other) triggers the unicast MAC learning with the ARP broadcast and unicast response but that's just a nicety of how things typically work, it's not always the case with any conversation between 2 Ethernet endpoints. Just knowing the MACs beforehand and not sending any broadcast is technically just as valid a way to do things at the Ethernet layer, albeit extremely rare in the world of IP.
> Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
More directly things like ARP and WoL offload so the CPU doesn't get interrupts every time some device in the subnet sends an ARP/WoL broadcast, particularly when it ends up being a broadcast intended for a MAC not owned by the local station. Both of those offloads are pretty common in consumer stuff too which is nice and that link I sent above shows a code change related to it for the Raspberry Pi adapter (albeit the Wi-Fi one, which has a whole different world of filters at the Wi-Fi layer before we even get to Ethernet filtering).
TCP offloading and whatnot can be examples as well but the level of abstraction (and varying levels of "what exactly is offloaded") makes it more difficult to discuss than the above examples which can stay within the Ethernet layer (as far as forwarding goes, the payloads may have information beyond that to deal with once delivered). That said I'll leave TCP offload with "the NIC may still need to know the VLAN tag and p-bit to put in the Ethernet header, as well as get the destination MAC of the next hop which could be a gateway or the destination client itself" but skip the examples or further corner cases/combinations since it can get hairy very fast and that already gives enough of an idea about Ethernet bits getting set by the offload too :).
Thank you! I love talking about bits and bytes on the network wire and it feels like I get to do it less and less the farther I get into my career... funny how that works. At least I haven't been moved into management yet!
> I'm guessing this is exactly why this stuff is handled at L2 and in the kernel module for the NIC?
Yep, generally the OS driver has a backup version of logic to handle everything beyond "packet receive" and "packet send" for exactly these kinds of reasons. On Linux you or any program with the rights can disable NIC filtering offloads by setting an interface to promiscuous e.g. "ip link set eth1 promisc on" and the packets all get punted to the CPU like it was a base level dumb NIC. Pulling an example early here is a patch making sure the broadcom driver for the NIC in the Raspberry Pi actually listens to this declaration and disables the ARP & ND filtering offloads https://patchwork.kernel.org/project/linux-wireless/patch/15...
> I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging.
Ideally the device (either NIC offload or upstream OS/further hardware logic) does some MAC learning as the above conversation goes on so things don't always remain unknown flooding past the first exchange but technically just forwarding the frame out all interfaces in the bridge group is valid too (just extremely inefficient). It's also worth noting usually in the real world higher layer discovery (like 2 IP addresses ARPing for each-other) triggers the unicast MAC learning with the ARP broadcast and unicast response but that's just a nicety of how things typically work, it's not always the case with any conversation between 2 Ethernet endpoints. Just knowing the MACs beforehand and not sending any broadcast is technically just as valid a way to do things at the Ethernet layer, albeit extremely rare in the world of IP.
> Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
More directly things like ARP and WoL offload so the CPU doesn't get interrupts every time some device in the subnet sends an ARP/WoL broadcast, particularly when it ends up being a broadcast intended for a MAC not owned by the local station. Both of those offloads are pretty common in consumer stuff too which is nice and that link I sent above shows a code change related to it for the Raspberry Pi adapter (albeit the Wi-Fi one, which has a whole different world of filters at the Wi-Fi layer before we even get to Ethernet filtering).
TCP offloading and whatnot can be examples as well but the level of abstraction (and varying levels of "what exactly is offloaded") makes it more difficult to discuss than the above examples which can stay within the Ethernet layer (as far as forwarding goes, the payloads may have information beyond that to deal with once delivered). That said I'll leave TCP offload with "the NIC may still need to know the VLAN tag and p-bit to put in the Ethernet header, as well as get the destination MAC of the next hop which could be a gateway or the destination client itself" but skip the examples or further corner cases/combinations since it can get hairy very fast and that already gives enough of an idea about Ethernet bits getting set by the offload too :).
Thanks, these are good points and well-explained. You lost me here though:
>"You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging."
In unknown unicast MAC flooding why would would the destination mac address ever be anything other than ff:ff:ff:ff:ff:ff? In your example the destination is 04:04:04:04:04:04. I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
>"You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging."
In unknown unicast MAC flooding why would would the destination mac address ever be anything other than ff:ff:ff:ff:ff:ff? In your example the destination is 04:04:04:04:04:04. I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
> In unknown unicast MAC flooding why would would the destination mac address ever be anything other than ff:ff:ff:ff:ff:ff? In your example the destination is 04:04:04:04:04:04.
Different nodes will have different ideas of what is known and what is unknown so it may be learned unicast on the sending node but unknown unicast on a middle node. E.g. imagine the bridge in the middle had it's table cleared for some reason, such as a reboot, or that client 1 had the destination MAC hardcoded in the sending logic but the bridge did not. In either case the client would know the unicast destination and put it in the packet and then it'd be unknown to the bridge in-between and be flooded. Remember beyond sending and receiving actual Ethernet frames with source/destination MACs in them bridges do not sync their learned MAC tables. The unknown flooding mechanism insures discoverability since the endpoints may not always know when a new bridge is between them or an existing bridge lost the entry.
In general there are 3 types of traffic that are flooded in Ethernet: BUM - Broadcast, Unknown, and Multicast. Broadcasts are explicitly created by setting the destination to ff:ff:ff:ff:ff:ff, unknown are a per node concept about a unicast destination not yet programmed in the local table (but may or may not be programmed elsewhere already), and multicast are reserved 23 bit range of MACs that are to never be programmed as learned so they flood permanently yet can have individual identifiers in the network. Sometimes a higher level protocol such as IGMP can be used to restrict this flooding to only nodes that ask for the specific multicast conversation to be sent to them but that's all optional and came later.
> I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
The relationship is that there is no relationship :). It doesn't matter that the assigned MACs are 0a:0a:0a:0a:0a:0a and 0e:0e:0e:0e:0e:0e since they aren't used in deciding if the 02:02:02:02:02:02 and 04:04:04:04:04:04 frames should be dropped when received. I.e. they are just there to show that if you did the "is this unicast packet destined to the locally assigned MAC? If not drop it" filtering all the time the interfaces would fail to bridge traffic correctly.
Walls of text can be lame so I created a visual scenario that minimally covers everything we talked about so far regarding learning and unicast MAC forwarding. It starts after the conversation has already started but it'll make sense why it starts there by the end: https://imgur.com/a/6vkaEgj
Different nodes will have different ideas of what is known and what is unknown so it may be learned unicast on the sending node but unknown unicast on a middle node. E.g. imagine the bridge in the middle had it's table cleared for some reason, such as a reboot, or that client 1 had the destination MAC hardcoded in the sending logic but the bridge did not. In either case the client would know the unicast destination and put it in the packet and then it'd be unknown to the bridge in-between and be flooded. Remember beyond sending and receiving actual Ethernet frames with source/destination MACs in them bridges do not sync their learned MAC tables. The unknown flooding mechanism insures discoverability since the endpoints may not always know when a new bridge is between them or an existing bridge lost the entry.
In general there are 3 types of traffic that are flooded in Ethernet: BUM - Broadcast, Unknown, and Multicast. Broadcasts are explicitly created by setting the destination to ff:ff:ff:ff:ff:ff, unknown are a per node concept about a unicast destination not yet programmed in the local table (but may or may not be programmed elsewhere already), and multicast are reserved 23 bit range of MACs that are to never be programmed as learned so they flood permanently yet can have individual identifiers in the network. Sometimes a higher level protocol such as IGMP can be used to restrict this flooding to only nodes that ask for the specific multicast conversation to be sent to them but that's all optional and came later.
> I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
The relationship is that there is no relationship :). It doesn't matter that the assigned MACs are 0a:0a:0a:0a:0a:0a and 0e:0e:0e:0e:0e:0e since they aren't used in deciding if the 02:02:02:02:02:02 and 04:04:04:04:04:04 frames should be dropped when received. I.e. they are just there to show that if you did the "is this unicast packet destined to the locally assigned MAC? If not drop it" filtering all the time the interfaces would fail to bridge traffic correctly.
Walls of text can be lame so I created a visual scenario that minimally covers everything we talked about so far regarding learning and unicast MAC forwarding. It starts after the conversation has already started but it'll make sense why it starts there by the end: https://imgur.com/a/6vkaEgj
>"Different nodes will have different ideas of what is known and what is unknown so it may be learned unicast on the sending node but unknown unicast on a middle node."
Yes, it's easy to forget that different hosts have different perspective of the network at different times.
Thanks for the image, it's very helpful indeed! I totally understand your point now.
At one time I used to work much much more with these types of details and now work up further in the stack. There is still lots of bridging but its all virtual bridge interfaces on Docker container networks and so things like this dicussion hardly come up anymore for me. This discussion really helped jog my memory and realize I've forgotten some things but also made me realize how fun and fascinating networking is! Cheers!
Yes, it's easy to forget that different hosts have different perspective of the network at different times.
Thanks for the image, it's very helpful indeed! I totally understand your point now.
At one time I used to work much much more with these types of details and now work up further in the stack. There is still lots of bridging but its all virtual bridge interfaces on Docker container networks and so things like this dicussion hardly come up anymore for me. This discussion really helped jog my memory and realize I've forgotten some things but also made me realize how fun and fascinating networking is! Cheers!
The preamble is intended for synchronization, the last two consequtive ones indicate the start of the data.
My circuit doesn't drop any frames, it simply converts serial Ethernet signal to SPI. FCS and MAC checking is done in software after receiving the whole frame.
You absolutely can get frames not addressed to you. Wireshark lets you do that. I debugged my adapter this way: I connected it to a dumb switch together with my computer and ran Wireshark on the computer which captured all frames regardless of their intended destination. On Linux you can even disable FCS checking and receive all rubbish from the wire.
My circuit doesn't drop any frames, it simply converts serial Ethernet signal to SPI. FCS and MAC checking is done in software after receiving the whole frame.
You absolutely can get frames not addressed to you. Wireshark lets you do that. I debugged my adapter this way: I connected it to a dumb switch together with my computer and ran Wireshark on the computer which captured all frames regardless of their intended destination. On Linux you can even disable FCS checking and receive all rubbish from the wire.
Thanks, I had another question after a second reading of your post:
>"The first bit of an Ethernet frame is always one, which means there might or might not be an extra edge in the beginning depending on the idle state of the amplifier. This extra edge, if it comes, needs to be filtered out."
Practically speaking what is the cause of the "extra" edge here? Would it be that the last bit of the FCS from the previous frame caused it to be a 1 and then the transceiver is immediately getting another edge from a preamble on a new Ethernet frame? Or am I confusing bits and edges?
>"The first bit of an Ethernet frame is always one, which means there might or might not be an extra edge in the beginning depending on the idle state of the amplifier. This extra edge, if it comes, needs to be filtered out."
Practically speaking what is the cause of the "extra" edge here? Would it be that the last bit of the FCS from the previous frame caused it to be a 1 and then the transceiver is immediately getting another edge from a preamble on a new Ethernet frame? Or am I confusing bits and edges?
A manchester-encoded bit 1 is a low-to-high transition: there should be "low" on the line which will change to "high". Before the "low" the line was idle (zero voltage difference), this state is interpreted by the differential amplifier as "high", so it's "high-low-high" at the beginning, but we are interested in the "low-high" edge and not in the "high-low" one.
Sync pulses are for PLL to sync with transmitter clock. Floppy sectors also start with a train of 64 sync pulses https://info-coach.fr/atari/hardware/FD-Hard.php#FDC_PLL
I love this stuff, well over my head but amazing read and so grateful for the scope captures!
However, some hardware I have sometimes produced longer preambles
How long were they, and did they happen to coincide with short frames? It's been a long time since I've worked with 10M Ethernet PHY but I vaguely remember some non-standard implementations would lengthen the preamble instead of padding the "tail" of the frame.
How long were they, and did they happen to coincide with short frames? It's been a long time since I've worked with 10M Ethernet PHY but I vaguely remember some non-standard implementations would lengthen the preamble instead of padding the "tail" of the frame.
The preambles were longer by a few bits (even less than 8). I didn't check which frames excatly caused this, but it happened only with one old 10 MBit switch.
It's possible that some PLLs might fail to lock in within a normal amount of time to acquire the full preamble. In which case varying the length of the preamble slightly shouldn't negatively affect receivers that are well designed to tolerate unusual conditions.
Its been way too long since I touched a breadboard, but what software was the post using to simulate this? I would expect that the requirement for ~ns precision (microwave frequencies) would involve a lot more tedious calculations for designing the circuit.
I used Falstad curcuit simulator (https://www.falstad.com/circuit/circuitjs.html) to try out some subcircuits (monostable, for example) and then tried them out on a breadboard.
Look on Hackaday for "Why do you need to use decoupling caps". I am not seeing any talk of decoupling caps in any of this persons writeups. Maybe they are there and I am just not seeing them. It used to be when designing with LS ttl you needed one per chip to make sure switching noise did not get onto your power supply rails.
Otherwise, a great project for learning.
The decoupling caps are there in the schematics shown alongside the symbols for the IC power inputs which is a common way of doing things.
IDK why something as fundamental as decoupling caps should be mentioned here at all though, anyone sufficiently knowledgeable to make use of this information would know that they're required already.
IDK why something as fundamental as decoupling caps should be mentioned here at all though, anyone sufficiently knowledgeable to make use of this information would know that they're required already.
Do you think they are worth mentioning? My post isn't a tutorial.
Wow the tech talent in Tokelau is insane!
A mistake: you refer to C9 in the monostable section, but it should be C5
Another mistake that doesn't deserve a top-level comment: the unit abbreviation for "second" is "s", not "S" (that one's the siemens = inverse ohm = former mho, which was a way better unit than the siemens, but that's another discussion...). Thus, "ms" and "ns" rather than "mS" and "nS". This may sound incredibly pedantic, and it is, but it's also one of the tests for attention to detail that I use when interviewing and evaluating an EE candidate, so, y'know, maybe worth learning to get right. Or not, life's short and building stuff out of discretes is more fun. Your call!
Hadn't heard of "mho" for conductivity, is that from when Bourne worked with electronics? :)
I would oppose a unit that starts with a prefix symbol (m=milli=0.001) on principle.
I would oppose a unit that starts with a prefix symbol (m=milli=0.001) on principle.
[deleted]
[deleted]
> I would oppose a unit that starts with a prefix symbol (m=milli=0.001) on principle.
The unit name isn't usually important. I think you're talking about the symbol? That's "℧", which has its own problems. But at least it's in Unicode now! Altogether I think the "℧" caused much less trouble than the "S" has. "S" is just stupid... as evidenced by this whole subthread. And, yes, I have read datasheets wrong because of this. Thanks, 14th CGPM!
The unit name isn't usually important. I think you're talking about the symbol? That's "℧", which has its own problems. But at least it's in Unicode now! Altogether I think the "℧" caused much less trouble than the "S" has. "S" is just stupid... as evidenced by this whole subthread. And, yes, I have read datasheets wrong because of this. Thanks, 14th CGPM!
Wikipedia dates the mho to 1883 and Lord Kelvin:
https://en.wikipedia.org/wiki/Mho#Mho
https://en.wikipedia.org/wiki/Mho#Mho
> I would oppose a unit that starts with a prefix symbol (m=milli=0.001) on principle
The fundamental SI unit of mass is the kilogram (kg).
The fundamental SI unit of mass is the kilogram (kg).
Thank you, fixed.
Thanks, fixed it.
This is sick. I also read their post about the making a discrete computer and didn’t expect them to be also writing a compiler from scratch. Something I’ve only been dreaming about.
classic hackernews. We need more of these
From Wikipedia:
> Manchester code was used in early Ethernet physical layer standards
So, not in later standards?
> Manchester code was used in early Ethernet physical layer standards
So, not in later standards?
Later standards use more efficient codes that map longer symbols to DC-free codes, and thus are more bandwidth-efficient. (8b/10b, 64b/66b codes, where manchester is basically a 1b/2b code)
Interesting timing for this post - I'm studying this for a new job at the moment and building myself my own little Wikipedia in order to learn it. 10BASE uses Manchester Encoding, 100BASE uses Non-Return-to-Zero, Invert-on-one (NRZI) encoding and Multiple Level Transition (MLT-3) with 4B5B translation, 1000BASE uses 8b/10b Encoding (8 bits for data, 2 for ECC).
More recent speeds all tend to use PAM4 encoding, meaning there's 4 voltage levels instead of 2! There's a great article on it here: https://blog.samtec.com/post/understanding-nrz-and-pam4-sign...
More recent speeds all tend to use PAM4 encoding, meaning there's 4 voltage levels instead of 2! There's a great article on it here: https://blog.samtec.com/post/understanding-nrz-and-pam4-sign...
Wanna read something bonkers? DDR6 memory coming in ~2025 is supposed to use PAM4 :o
I love these people bc they do all the esoteric stuff so that I don’t have to.
Cool! Have you submitted to Hackaday?
Nice work! Now do thicknet :P
What is the benefit of using all of these different components over using an FPGA?
It's a fun project. I feel like building stuff with logic gates.
It is hardware poetry.
(What is the benefit of rhymes, meter, etc over using prose?)
(What is the benefit of rhymes, meter, etc over using prose?)
How is this fairly nerdy piece, that no one has commented on, top of hn? What am I missing?
It's super cool.
The very best things speak for themselves, and need no amplifying comments.
[deleted]
That it's impressive.
the HN algorithm is a bigger mystery than the universe itself
No, i think most of its part is manual update database to set the rank of a post.
Some sites shadowban .tk, Reddit probably still does. Search engines probably downrank it. That's because it's free and has been used for a lot of spammy stuff.
This makes it harder for people to share and harder for people to find. That might just put a damper on your hobby, but it might also mean you won't get random emails about jobs you might want. (If you're interested in that.)
I only mention it because I learned that the hard way many years ago.