Hi, On Sat, Jun 7, 2025 at 5:00 PM Ramon Fontes <ramonreisfontes@xxxxxxxxx> wrote: > > > There is a generic way by using netem qdisc and using AF_PACKET > without PACKET_QDISC_BYPASS, should do something like that. > If you really want to do something else there or only act on 802.15.4 > fields and you hit the limitations of netem then this is something > netem needs to be extended. > > Let’s say I’m quite familiar with netem - netem is indeed well-known > and has been used extensively with tc/ifb. However, it is primarily > suited for 1-to-1 communication scenarios. > In 1-to-n topologies, such as when node 0 communicates with both node > 1 and node 2, it becomes unclear which peer should serve as the > reference for applying delay, loss, or latency. That's why there exist addresses. > This limitation makes netem unsuitable for scenarios where > link-specific behavior is required, such as in ad hoc networks. > In such cases, a more precise per-link control - as provided by > wmediumd - becomes necessary. > Teach netem to deal with addresses on a generic filter hook. Maybe you can ask at batman project how they test things because they use 80211 mesh functionality? > > With that being said, however there are so few users of 802.15.4 in > Linux and adding your specific stuff, I might add it if this helps you > currently... but I think there are better ways to accomplish your use > cases by using existing generic infrastructure and don't add handling > for that into hwsim. > > Back in 2016, mac80211_hwsim had relatively few users. Today, I > maintain a community of approximately 1,000 users worldwide who rely > on mac80211_hwsim for their research - industry and academy. > The need for a realistic experimental platform is not a personal > requirement, but rather a broader gap in the ecosystem. Addressing > this gap has the potential to significantly advance research on IEEE > 802.15.4. > > > but I think there are better ways to accomplish your use > cases by using existing generic infrastructure and don't add handling > for that into hwsim. > > Honestly, based on my experience so far, there’s no better approach > available. Well - there is one: integrating all the wmediumd > functionality directly into the kernel module itself. But I fully > agree - that would be both unrealistic and impractical. > I looked more closely at the patches and there are a lot of question marks coming up, for example why there is virtio handling, when this patch should not do anything with virtio? Why do we introduce a second data structure to keep registered hwsim phys? Why do we have a lot of wording of "wmediumd" when this is the project/process part in user space? - Alex
