Any micros with ETH and hardware incoming packet filtering by IP?

[peter-h]

Currently I have a 32F417 whose ETH is feeding packets to LWIP and this filtering of traffic not addressed to your IP is done up in LWIP.

In the embedded world one is unlikely to get deliberately DOS'd, and most "RJ45 boxes" connect to a port of a switch, not a hub, so only packets addressed to your MAC should be reaching you, but all broadcasts will reach you and there is a possibility of overload.

This was actually a real issue with some of the RJ45-to-serial modules (intended to make adding ETH to an old style Z80-type board which can't run a TCP/IP stack) which could not deal with any significant incoming traffic not addressed to their IP.

I guess one could hook up the ETH DMA and have an ISR dumping the packets down there, which is better.

Just wondering why such an apparently obvious feature was left out.

[nctnico]

Currently I have a 32F417 whose ETH is feeding packets to LWIP and this filtering of traffic not addressed to your IP is done up in LWIP.

Just wondering why such an apparently obvious feature was left out.

It isn't. The hardware seems to be perfectly capable of doing all kinds of filtering. It is just left out at the driver level  .

[westfw]

Not receiving broadcasts would be a bad thing.  ARP would break, for example (although, those aren't even IP packets.)  Multicasts are typically filterable, either as a whole, or via a table of hashes.

If your network has a large quantity of broadcast IP packets, you should probably figure our why, and maybe change things at the network level.  There used to be a thing called "broadcast storms", but they should have been eliminated a long time ago.

I guess one could hook up the ETH DMA and have an ISR dumping the packets down there

Yes, you can save many cycles and dramatically improve performance by discarding packets that are "not useful" as early as possible.

[wek]

Currently I have a 32F417 whose ETH is feeding packets to LWIP and this filtering of traffic not addressed to your IP is done up in LWIP.

Just wondering why such an apparently obvious feature was left out.

It isn't. The hardware seems to be perfectly capable of doing all kinds of filtering. It is just left out at the driver level  .

Can you please point me to the description of IP-level filtering in RM0090? All I can see is ETH level SA/DA filtering as described in 33.5.5. MAC filtering subchapter.

Sure, in purely LAN setting, there may be a nearly 1:1 relationship between MAC and IP addresses, but I am not sure how could this apply generally.

JW

[westfw]

The hardware seems to be perfectly capable of doing all kinds of filtering.

All sorts of MAC address filtering (multiple unicast addresses - nice!)
I don't see any filtering capabilities above the MAC layer.

[Berni]

Handling the IP protocols on top is a lot more complicated, so it very rarely done in hardware.

What you are supposed to use is MAC filtering. If you don't want to see broadcast messages then you just disable the broadcast MAC of FF:FF:FF:FF:FF:FF

Handling large amount of traffic is not that hard if the software is well written. One test i do with ethernet on MCUs is that i set up a loopback port that sends back anything you send to it then fire full 100Mbit worth of data at that port. They seam to be able to maintain that even while doing other stuff.

[voltsandjolts]

Well, I'm no ethernet expert, but these days aren't ethernet switches used almost exclusively, rather than the old fashioned ethernet hubs? If you're connected through a switch, you already got ip filtering for free?

[westfw]

If you're connected through a switch, you already got ip filtering for free?

Not of broadcasts.


I’ll repeat - if your  Net has a high level of broadcast IP packets, that you hoped to filter out by IP address, something is probably wrong with “other hosts” on the net.

[peter-h]

Well, I'm no ethernet expert, but these days aren't ethernet switches used almost exclusively, rather than the old fashioned ethernet hubs? If you're connected through a switch, you already got ip filtering for free?

I think that's true for most LAN (e.g. factory floor) installations.

Doesn't stop a flood of broadcast packets though, which at 100mbps would pretty well finish off the ISR handling ETH RX (which is not a trivial ISR) and one needs to decide whether this vulnerability is worth addressing.

In the product I am working on this was solved by polling for RX packets, at 100Hz, resulting in a 250kbyte/sec data rate cap, which is fine for the application. I can't explain why 2500 bytes are transferred each time; it isn't a multiple of anything...

If using an RX interrupt (which everybody says you must ) then this can be solved by the ISR disabling the IRQ for a bit, setting a timer, and then re-enabling the ETH IRQ from a timer ISR. Which is... hey pretty much what I am doing with polling Well, you could make it more cunning, like run flat out for up to 100ms and then start backing off the IRQ.

something is probably wrong with “other hosts” on the net.

For sure, but that doesn't help you

[Berni]

The ethernet controller on the STM32F4 series has a specific bit for broadcast the BFD(Broadcast frames disable) inside ETH_MACFFR. You won't even get a interrupt in that case.

But if you have somehow broadcast traffic at 100Mbit directed at your own MAC address then you have a really weirdly configured network. I can always denial of service a 100Mbit device on a network by simply sending a massive amount of traffic towards it using a 1Gbit link. The switch itself won't have the capacity to fit the data into the 100Mbit link so packets will be dropped inside the switch before they even get to you.

But yes if you are worried about the ethernet ISR eating so much CPU time that your main thread stops the easy fix is to add a counter inside the ISR and disable it when it gets called too often, then later on turn it back on (by timer or in the main loop)

If you want to be more selective you could also add a "firewall" in the ISR that doesn't even pass packets over to LWIP unless they look useful. You can do a few quick checks at fixed offsets in the packet to determine it as a IPv4 TCP packet for a certain port. But you have to be careful to not block any of the other housekeeping traffic like DHCP and IP discovery packets as otherwise the network you are on might not be able to find you.

[nctnico]

Currently I have a 32F417 whose ETH is feeding packets to LWIP and this filtering of traffic not addressed to your IP is done up in LWIP.

Just wondering why such an apparently obvious feature was left out.

It isn't. The hardware seems to be perfectly capable of doing all kinds of filtering. It is just left out at the driver level  .

Can you please point me to the description of IP-level filtering in RM0090? All I can see is ETH level SA/DA filtering as described in 33.5.5. MAC filtering subchapter.

Sure, in purely LAN setting, there may be a nearly 1:1 relationship between MAC and IP addresses, but I am not sure how could this apply generally.

I missed the 'IP' part but it wouldn't surprise me if MAC filtering has not been enabled so that would be a good first step. Still it wouldn't protect against a broadcast storm (but IP filtering doesn't protect against that either).

[2N3055]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

TCP/IP was conceived to run on UNIX workstation... IOT was not it's design target, and it shows..

Broadcasts are nominal part of how network works,  ARP broadcasts for instance..
As said, good switch's job is to pass only packets for your MAC, which include all broadcasts.

Any cleanup of traffic needs to happen inside network equipment.

DOS will kill all equipment. Network equipment can (should) have built in tools to fight that..

Once network is complicated (or screwed up) enough you need to hire network expert to sort it out for you.. Networking is complicated and hard enough, and it is a full time job, on anything more than dozen of hosts on a home router....

[nctnico]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

TCP/IP was conceived to run on UNIX workstation... IOT was not it's design target, and it shows..

There are switch chips / processors aimed at routers that have handling of layer 3 in hardware. The idea is not that outlandish. A possible solution is to add a switch chip as a phy to a microcontroller and use the layer 3 handling in the switch chip as some kind of firewall / filter. A super low cost switch chip like the IP175DLF already supports some L3 filtering.

Also don't forget that tcp/ip and IPv4 where never designed with any network security in mind and that a modern day microcontroller runs circles around those old Unix workstations (from the 90's) where it comes to processing power.

[2N3055]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

TCP/IP was conceived to run on UNIX workstation... IOT was not it's design target, and it shows..

There are switch chips / processors aimed at routers that have handling of layer 3 in hardware. The idea is not that outlandish. A possible solution is to add a switch chip as a phy to a microcontroller and use the layer 3 handling in the switch chip as some kind of firewall / filter. A super low cost switch chip like the IP175DLF already supports some L3 filtering.

Also don't forget that tcp/ip and IPv4 where never designed with any network security in mind and that a modern day microcontroller runs circles around those old Unix workstations (from the 90's) where it comes to processing power.

Yeah exactly what I said... Those are networking equipment specials, nothing to do at all with embedded microcontrollers running  LWIP.. Which is not even a full IP protocol stack.

Answer to OP question is what I said, what he wanted is NOT obvious feature to be added and it is not there by design. And all the complexity you propose would only serve his fear "it might get in problems if we get hacked"...

I'm not saying that in theory what you say is wrong (it's not) but it is shooting a fly with cannon, and not really needed. And all the complexity added is explanation why it is NOT done.

[peter-h]

"it might get in problems if we get hacked"...

I didn't say that.

[2N3055]

"it might get in problems if we get hacked"...

I didn't say that.

Than I misunderstood. If you are not under DDOS or broadcast storm, no need to worry...

[wek]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

Pity somebody did not tell this to Synopsys. So, they by mistake built in IP and even ICMP/UDP/TCP header checksum offload into the ETH/MAC IP which is used in the STM32s...

Given this, it would be entirely possible to add IP address (both source and destination) filtering/steering/whatnot, even TCP/UDP port-based one. Maybe in some incarnations of this IP they did (Synopsys IP are usually widely configurable when deployed), maybe even in some STM32 ('H7 perhaps?). I'm just not interested enough to look it up.

[EDIT] OK, maybe not interested but curious :-D From RM0433 ('H743):
The MAC supports Layer 3 and Layer 4 based packet filtering. The Layer 3 filtering refers to the IP Source or Destination Address filtering in the IPv4 or IPv6 packets whereas Layer 4 filtering refers to the Source or Destination Port number filtering in TCP or UDP.

OK so this answers the OP's question, I guess.
JW

[2N3055]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

Pity somebody did not tell this to Synopsys. So, they by mistake built in IP and even ICMP/UDP/TCP header checksum offload into the ETH/MAC IP which is used in the STM32s...

Given this, it would be entirely possible to add IP address (both source and destination) filtering/steering/whatnot, even TCP/UDP port-based one. Maybe in some incarnations of this IP they did (Synopsys IP are usually widely configurable when deployed), maybe even in some STM32 ('H7 perhaps?). I'm just not interested enough to look it up.

[EDIT] OK, maybe not interested but curious :-D From RM0433 ('H743):
The MAC supports Layer 3 and Layer 4 based packet filtering. The Layer 3 filtering refers to the IP Source or Destination Address filtering in the IPv4 or IPv6 packets whereas Layer 4 filtering refers to the Source or Destination Port number filtering in TCP or UDP.

OK so this answers the OP's question, I guess.
JW

It does not.
There are lot of "maybes" and "coulds" in your answer. Those don't make a product.
Or shall I say, maybe that is an answer.

Unless you are volunteering to rewrite LWIP to use these features..
Like I said. Theory is one thing.
There is plenty of silicon that has these kinds of features.

None in a ready made form combination of hardware/software that OP can simply use in his scenario. This kind of filtering is not dev time setup, but run time setup. So you would not only need to make new stack that supports it, but also access table management tools etc etc. It gets complicated quick. For a concern that (normal) broadcasts on a network might overload IP stack...


Most of the time, people are trying to use development tools to make products, not spend time developing development tools, or tools in general.

[nctnico]

You are overthinking it. If what wek writes is correct, then those hardware filtering options already provide a lot of possibilities to get rid of traffic that doesn't interest you. Just look what a typical Windows PC broadcasts on a network. If the hardware can already filter those ports out, then you already got rid of quite a bit of traffic. Same goes for multicast traffic that might hit your device.

And you don't need to rewrite Lwip (or whatever network stack you use) or develop tools. Just add a few lines of code that setup the filters at startup and be done with it. The network stack doesn't need to know anything about what filtering is going on.

Another possibility is to add IP and port based filtering in the network driver layer. At least you won't be feeding a lot of data into network stack that gets discarded but it depends on how the network stack is organised whether this is an improvement or not.

[mikeselectricstuff]

Currently I have a 32F417 whose ETH is feeding packets to LWIP and this filtering of traffic not addressed to your IP is done up in LWIP.

In the embedded world one is unlikely to get deliberately DOS'd, and most "RJ45 boxes" connect to a port of a switch, not a hub, so only packets addressed to your MAC should be reaching you, but all broadcasts will reach you and there is a possibility of overload.

This was actually a real issue with some of the RJ45-to-serial modules (intended to make adding ETH to an old style Z80-type board which can't run a TCP/IP stack) which could not deal with any significant incoming traffic not addressed to their IP.

I guess one could hook up the ETH DMA and have an ISR dumping the packets down there, which is better.

Just wondering why such an apparently obvious feature was left out.

Can it actually cause an overload/overrun in practice ?
If the IP  stack is reasonably efficient, e.g. not transferring any payload of packets not of interest, I'd have thought a 168MHz processor would be able to deal with anything a 100mbit interface can throw at it. Even if it is DMAing the whole packet into double-buffered RAM with, say, a 50 byte packet, that's roughly 5uS of line-time,  so over 750 cycles to deal with it, which ought to be enough.

[westfw]

So much wrong information here..

Yep.

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

Nope.   "Upper level filtering", "Checksum offload", and other "layer violating features" have been incorporated into "advanced"  Ethernet controllers for decades now.  Frequently, they end up unused, because it would require too much effort at the driver level, and too many level-violating hacks in the OS, to make use of.

TCP/IP was conceived to run on UNIX workstation...

Nonsense.  TCP/IP was designed well before "Unix workstations" even existed.  It was designed for mainframes!
(The TCP/IP Transition of ARPANet/Milnet was 1/1/83 - "production deployment" after years of R&D.  So was the AT&T breakup that led to the easy commercialization of Unix as an OS.)

IOT was not it's design target, and it shows..

I dunno.  Wireless Packet Radio, running on relative small ("mobile", in the sense that you could put it on a smallish truck or airplane) was always a goal, and there were pre-TCP projects that ran on things like PDP11s.  Today's microcontrollers are considerably more powerful than those early networking nodes.  More changes have been added to the protocol suite to accommodate bigger, faster computers than to adapt to smaller systems.  Although I guess the stack generally assumes a "RAM Rich" environment that is less common on microcontrollers.

[peter-h]

And you don't need to rewrite Lwip (or whatever network stack you use) or develop tools. Just add a few lines of code that setup the filters at startup and be done with it. The network stack doesn't need to know anything about what filtering is going on.

Yes it would be good for building a simple firewall function - one that actually works in the face of lots of incoming data. The CPU ETH hardware can deal with 100mbps data rate.

Can it actually cause an overload/overrun in practice ?
If the IP  stack is reasonably efficient, e.g. not transferring any payload of packets not of interest, I'd have thought a 168MHz processor would be able to deal with anything a 100mbit interface can throw at it. Even if it is DMAing the whole packet into double-buffered RAM with, say, a 50 byte packet, that's roughly 5uS of line-time,  so over 750 cycles to deal with it, which ought to be enough.

It depends on how long the RX ISR is. Probably 10-20us. Then you have the higher level processing in LWIP, checking whether the packet is for us. So this would hang the target pretty well.

Frequently, they end up unused, because it would require too much effort at the driver level, and too many level-violating hacks in the OS, to make use of.

LWIP has an option to use hardware checksums, and I have them all enabled in my project.

[Berni]

Can it actually cause an overload/overrun in practice ?
If the IP  stack is reasonably efficient, e.g. not transferring any payload of packets not of interest, I'd have thought a 168MHz processor would be able to deal with anything a 100mbit interface can throw at it. Even if it is DMAing the whole packet into double-buffered RAM with, say, a 50 byte packet, that's roughly 5uS of line-time,  so over 750 cycles to deal with it, which ought to be enough.

That was my first point in the thread. I used Ethernet on STM32 chips before and i could throw 100Mbit of traffic at it while it is sending 100Mbit of traffic back at me and yet everything just kept running.

There is a different exploit if you want to intentionally bring a network device to its knees. You can send a flood of the smallest possible packets that the device might still care about. That way you can fit as many packets as possible in a given link speed. The data can be moved fast but the packet headers the device sometimes has to think about. For example you can crash most home routers (even pretty expensive ones) by sending it a huge flood of TCP SYN packets for a few seconds. It is only the real deal professional networking gear that survives that. So i don't think it is reasonable to design your device to survive this. If the network is spewing too tons of junk at you it is the network admins job to get there shit together.

[nctnico]

So much wrong information here..

IP layer is layer 3. It lives in application processor, and Ethernet controller is completely oblivious of it by design...
TCP/IP stack is software stack. Period. OSI layers and such nonsense..

TCP/IP was conceived to run on UNIX workstation... IOT was not it's design target, and it shows..

There are switch chips / processors aimed at routers that have handling of layer 3 in hardware. The idea is not that outlandish. A possible solution is to add a switch chip as a phy to a microcontroller and use the layer 3 handling in the switch chip as some kind of firewall / filter. A super low cost switch chip like the IP175DLF already supports some L3 filtering.

Yeah exactly what I said... Those are networking equipment specials, nothing to do at all with embedded microcontrollers running  LWIP..

On the contrary. I have used various switch chips as a phy in several projects with a microcontroller running a network stack. As soon as there is a requirement to be able to daisy chain network devices, a switch chip is super handy to use.

[westfw]

This was actually a real issue with some of the RJ45-to-serial modules (intended to make adding ETH to an old style Z80-type board which can't run a TCP/IP stack) which could not deal with any significant incoming traffic not addressed to their IP.

This is becoming a pointless discussion without having more details on the original problem.  We have:

• DoS is likely always possible.
• Receiving broadcasts is important.
• Broadcast density on a properly operating LAN should be low.

IIRC, there were SOME ethernet controllers that were sufficiently broken WRT to receiving some desirable packets that the fix was to operate them in promiscuous mode (receives ALL packets) and filter entirely in SW.  But that was a long time ago, and the ubiquity of switches should make even those less problematic...

(Ah, memories!  Sending broadcast pings with IP options on the InterOp show net, back when no one implemented IP options, and when that wouldn't get you kicked out of the show...)

[wek]

is is becoming a pointless discussion without having more details on the original problem

It's always a pointless discussion without precise problem formulation in the mcu realm. But it's fun to discuss vaguely defined problems. Well, that's a point, after all, I guess.... :-)

Receiving broadcasts is important.

Maybe not. Microcontrollers are not small computers (same as children are not small people). In quite typical mcu TCP/IP usage, you need to listen to broadcasts only while somebody "tries to find you" (ARP); once connection is established, you can filter broadcasts reception off if possible, for benefit of the unicast communication.

Broadcast density on a properly operating LAN should be low.

Tell the manufacturers of common office equipment (yes, Canon, I see you).

JW

[mikeselectricstuff]

Receiving broadcasts is important.

Maybe not. Microcontrollers are not small computers (same as children are not small people). In quite typical mcu TCP/IP usage, you need to listen to broadcasts only while somebody "tries to find you" (ARP); once connection is established, you can filter broadcasts reception off if possible, for benefit of the unicast communication.

..except you never know when a remote host may get reset and need to do another ARP request

[wek]

Receiving broadcasts is important.

Maybe not. Microcontrollers are not small computers (same as children are not small people). In quite typical mcu TCP/IP usage, you need to listen to broadcasts only while somebody "tries to find you" (ARP); once connection is established, you can filter broadcasts reception off if possible, for benefit of the unicast communication.

..except you never know when a remote host may get reset and need to do another ARP request

While talking to me?

JW

[mikeselectricstuff]

Receiving broadcasts is important.

Maybe not. Microcontrollers are not small computers (same as children are not small people). In quite typical mcu TCP/IP usage, you need to listen to broadcasts only while somebody "tries to find you" (ARP); once connection is established, you can filter broadcasts reception off if possible, for benefit of the unicast communication.

..except you never know when a remote host may get reset and need to do another ARP request

While talking to me?

JW

No, but trying to decide when to listen for broadcast, and do the right thing in all situations is tricky.

[wek]

No, but trying to decide when to listen for broadcast, and do the right thing in all situations is tricky.

EnableBroadcastRx();
while(1) {
  if (SomebodyWantsToTalkToMe()) {
    DisableBroadcastRx();
    do {
      Talk();
    } while (IsThereStillAnythingToTalkAbout());
    Disconnect();
    EnableBroadcastRx();
  }
}

?

JW

[nctnico]

You might want to handle ARP requests from other hosts. Some DHCP implementations use ARP to verify IP addresses are available. So ARP might not be the best example. IMHO you should make sure your device doesn't discard basic network management messages (ARP, Ping) on purpose. There is still a huge amount of other broadcast traffic that can be filtered though.

[mikeselectricstuff]

No, but trying to decide when to listen for broadcast, and do the right thing in all situations is tricky.

EnableBroadcastRx();
while(1) {
  if (SomebodyWantsToTalkToMe()) {
    DisableBroadcastRx();
    do {
      Talk();
    } while (IsThereStillAnythingToTalkAbout());
    Disconnect();
    EnableBroadcastRx();
  }
}

?

JW

The devil is in the detail - things like "IsThereStillAnythingToTalkAbout()" inevitably involve timeouts and other decisions which could come back to bite you down the line. 

[peter-h]

The danger isn't in getting hit with broadcasts at 1Hz or even 10Hz, 24/7, because nobody will notice that. It is whether you are happy to have your product more or less hang if some other bit of kit on the LAN has a bug and starts emitting broadcasts at 10kHz.

The average customer will probably not have the on site capability to discover what is going on.

The solution, as already mentioned, is to either poll the ETH RX, or use interrupts for ETH RX and have a scheme for backing off the IRQ enable according to some rule (which is a bit of work, especially as you need to actually test it ).

In the embedded world, actually very few products need 100mbps data rates. We are not building routers (which are mostly linux boxes nowadays, with fairly decent CPUs). I bet you most embedded (IOT) stuff would be just fine with 1mbps. I am polling at 100Hz and getting 2.5mbps.

If you put your IOT on an open port, you will be getting login attempts (dictionary attacks) at 1Hz-5Hz 

[wek]

The devil is in the detail - things like "IsThereStillAnythingToTalkAbout()" inevitably involve timeouts and other decisions which could come back to bite you down the line. 

You've just described the gist of mcu programming, regardless of IP/ETH/filtering/whatever... ;-)

JW