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

[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