Oh dear, yes that example is a sticky wicket. The config file that failed out on you (`examples/Linux-LWIP/echo-config.json`) hasn't been updated in well over a year, and has a couple clauses in it that were deprecated in release v0.6.0-preview-6. I'm fixing that config file for the next release, at least.
I believe the only changes that are absolutely needed, btw, are changing `"default-policy-static"` to `"default-policy"`, and similarly `"default-event-static"` to `"default-event"`, in the `"default-policies"` section.
But even if you get it to load successfully, it won't quite work right, because the demo is just using libpcap to generate the raw input packets to lwIP. This allows you to exercise and explore the traffic evaluation dynamics of wolfSentry, which is particularly useful with `WOLFSENTRY_DEBUG_LWIP` and/or `DEBUG_ROUTE_LOOKUP` defined in the build.
But it doesn't allow actual filtration, because libpcap is just tapping the packet flow, not intercepting it. The Linux kernel (and its in-tree IP stack) still receives the traffic unfiltered. Worse yet, it still generates the regular replies to it, like ICMP echo reply and TCP unreachable-reset. With wolfSentry configured to generate its own replies, the client sees double replies. E.g. "DUP" ping replies. And in fact, lwIP and Linux can disagree on what to do, e.g. lwIP accepting a connection, but Linux resetting it. It's a mess.
We should probably remove this (2 year old) example because of these glitches, but it has proven useful for internal development+testing at least.
In `examples-notification-demo` there's an example that actually works right as-is, though it doesn't demo the lwIP integration.
Some time soon we'll be adding an updated turnkey lwIP-RTOS example, but for now you could do worse than just review the new documentation in `doc/freertos-lwip-app.md`.