Firstly a few thoughts.

A question often asked is “why mess around in L2E?”

One answer is “we can get rid of a lot of networking”.

Of course the next question is usually “why get rid of networking?”.

“Because sometimes we want to be off the network, or rather, just on it”.

Its worth exploring this last point a little further.

Once a device has joined or been discovered on a network it can attract all sorts of useful but also understandable attention.

For example, we may have some small telemetry devices with “chip based” network stacks. These are typically very limited and cannot withstand much traffic.

Imagine if one of these devices was connected to a “dumb switch” and someone unwittingly attaches a device that generates multicast traffic (audio for example).

The dumb switch will simply flood the ports and…down go all the tiny devices. Of course a “proper switch” (managed) will employ IGMP Snooping etc, but we can’t rely on this.

Its important to note that whilst disabling higer network levels may make a device “invisible” to much of the network, managed switches (layer 2 devices) will still be aware of their presence.

We will implement the above ideas in the projects.

---

Getting a bit “off the track”.

If you decide to head off and create many of your own Layer 2 Ethernet (L2E) projects remember that L2E operates on a “best effort basis” (no guarantee of delivery).

We, the programmer will have to provide error recovery etc. which can end up becoming quite a lot of work.

So if you find yourself after many hours with pages and pages of code, it may be a hint that you’d be better off just re-enabling full networking.

Alternatively for those who grew up in the days when “RS232 serial” was everywhere, and was required to write complete sub systems, error recovery etc in L2E will be fairly straight forward.