Skip to main content
SEGGER emNet UDP flood protection architecture diagram for embedded TCP/IP stack

Built-In UDP Flood Protection in SEGGER emNet: How It Works

GSAS Engineering · · 4 min read

UDP floods are among the simplest denial-of-service attacks against networked embedded systems. An attacker sends a high volume of UDP packets to random or known ports on the target. For each packet, a traditional TCP/IP stack must receive it into a buffer, pass it through the IP layer, check the UDP port table, find no matching socket, generate an ICMP “port unreachable” response, and free the buffer. On a resource-constrained microcontroller, this sequence, repeated thousands of times per second, saturates the CPU and starves the application.

The device does not crash. It simply becomes unresponsive because every cycle is spent processing garbage packets.

Filtering at the Driver Level

SEGGER emNet addresses this with UDP flood protection that operates at the network driver level, below the IP stack’s main processing task. When a UDP packet arrives, emNet performs a lightweight check before passing it up to IP_Task for full processing.

The check examines two fields: the destination IP address and the destination UDP port. If the packet targets a unicast IP and the port does not match any open socket, emNet discards it immediately at the driver level. The packet never enters the IP_Task’s input queue, never triggers IP header parsing, never causes a socket table lookup, and never generates an ICMP response.

This is a meaningful architectural difference. In a stack that processes every packet through the full IP path, a UDP flood of 10,000 packets per second can consume 50-80% of a Cortex-M4’s CPU time. With emNet’s driver-level filter, the same flood consumes a fraction of that.

What the Filter Does Not Block

The filter is intentionally selective. It does not discard UDP broadcast packets on ports with open sockets. This is critical because protocols like DHCP rely on UDP broadcast, a DHCP client listens on port 68, and server responses are often broadcast.

emNet discards a packet only when all of the following are true:

  • The packet is UDP
  • The destination IP is unicast (not broadcast, not multicast)
  • No socket is bound to the destination port

Legitimate traffic to open ports is never affected, broadcast-based protocols continue to function, and multicast traffic is handled normally.

Available Since emNet 3.20

The UDP flood protection feature is available in emNet version 3.20 and later. Upgrading to a current emNet release through GSAS provides the protection along with other stack improvements.

Minimal Overhead

The per-packet overhead is minimal, two comparisons against the destination address and port, plus a socket list lookup. On a Cortex-M4 at 168 MHz, this adds single-digit microseconds per packet. The overhead of not having the filter, full stack processing for every flood packet, is orders of magnitude larger.

For systems where determinism matters (industrial control loops, real-time sensor acquisition), the difference between driver-level discard and full-stack processing can determine whether the application meets timing deadlines during a network attack.

Practical Implications

Any embedded device with an Ethernet or Wi-Fi interface on a shared network is a potential target, whether from intentional attacks, misconfigured devices, broadcast storms, or test equipment. Industrial PLCs, building automation controllers, IoT gateways, and medical devices all operate in environments where network traffic is not fully controlled.

emNet’s approach requires no configuration. No filter rules, no firewall tables, no application code changes. The protection is built into the stack and operates automatically.

emNet and SEGGER Networking in India

GSAS Micro Systems provides SEGGER emNet along with emSSL, emMQTT, emWeb, and emFTP with INR invoicing and local engineering support. Teams across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR can access technical consultation for networking stack integration and connected device development.

Explore SEGGER emNet | Request a Quote | Book a Demo

Interested in SEGGER tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Embedded engineering workstation in India, illustrating the debug, analysis and design steps where AI now runs inside the process, supported by GSAS
Industry Insights

AI Inside the Engineering Process: What Is Worth Automating, and What Still Needs an Engineer

Arm, SEGGER, Perforce and Siemens EDA have each put AI inside a step of the engineering process rather than on top of it: debug, remediation, design entry, inference on the part. GSAS sets out the position behind our coverage of each: which steps are now worth automating, and which keep a human because the cost of being wrong is a recall.

21 Sept 2026 · 11 min read
Embedded verification and unit test workflow, illustrating the economics of finding defects early, supported by GSAS Micro Systems in India
Technical Guides

Verification Economics: What a Late Defect Actually Costs, and What the Evidence Really Says

Finding a defect in month 2 instead of month 14 is a budget decision before it is a quality decision. This sets out what the published evidence supports, what it does not, including the 100x multiplier that traces back to a course handout rather than a study, and how an Indian embedded team builds the case on its own numbers.

21 Sept 2026 · 14 min read
Two test paths leaving the same device under test, one into a conformance suite that returns a passed report and one into a partner node that surfaces a field defect, showing why an ECU can clear a published suite and still fail in a vehicle, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Ethernet Conformance: TC8 and Testing Above It

Summarising TC8 as a layer 1 to layer 4 suite is wrong in both directions. The public OPEN Alliance ECU test documents run from transmitter distortion up to a SOME/IP chapter with its own standardised test stub, and they contain exactly one time synchronisation test case. This is what those documents enumerate, chapter by chapter, what genuinely lives above their boundary, why a passing ECU can still fail against a partner node, and how much pre-compliance work a Tier-1 in India can honestly do in-house before a test house visit. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 12 min read