> That's why there exist addresses. The addresses are really important here. However, that still requires the entire emulation logic, including per-link delay, loss, and interference modeling to be implemented and managed manually in user space. The approach proposed here aims to offload this complexity by providing an integrated solution at the PHY level, before packets reach the MAC, where interference and delivery decisions can be made consistently and transparently, without requiring user space to replicate the entire logic. In that sense, while addresses do help identify the destination, they are not sufficient alone to handle the broader scope of realistic wireless emulation, especially when topology-aware behavior and MAC feedback are needed. > 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? I'm familiar with the BATMAN project, as well as IEEE 802.11s, OLSR, Babel, and other mesh routing protocols. In fact, I authored a book chapter in 2022 specifically on these protocols, focusing on their use in wireless networking. That work was centered on wireless network emulation, where I provided practical examples of how to deploy and test these protocols in Linux-based environments. That said, all the netem-based approaches, while useful, are not sufficient on their own to address the broader requirements of realistic wireless emulation. They lack integration with physical layer behavior, cannot model per-link dynamics based on distance or interference, and offer limited support for topological asymmetry and MAC-level feedback, which are essential for accurate and reproducible wireless testing. Book chapter ref: https://digital-library.theiet.org/doi/10.1049/pbte101e_ch1 > 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? I agree with you. That's actually something I had been thinking about as well. I believe we can remove the virtio-related handling for now, as it doesn’t belong in the scope of this patch. If needed, we can revisit it separately in a follow-up patch that properly addresses its purpose. > Why do we introduce a second data structure to keep registered hwsim phys? The second data structure, in this case, (the rhashtable?), was introduced to allow efficient lookup and management of registered hwsim PHYs based on attributes such as the portid or virtual address. The existing hwsim_phys list is sufficient for basic iteration over all PHYs, but it becomes inefficient and cumbersome when we need: - Fast lookup by a unique identifier (e.g., portid, ieee_addr); - To support operations like remove_user_radios() efficiently; - To associate radios with specific users or namespaces (net), particularly when cleaning up after NETLINK_URELEASE or network namespace shutdown. Additionally, this follows the same architectural pattern used in mac80211_hwsim, where similar per-radio or per-user management is needed. So the rhashtable is not a replacement but a complementary structure optimized for use cases that require fast indexed access or conditional cleanup, while the existing list remains useful for ordered traversal and general-purpose iteration. Honestly, I chose to keep the existing structure to ensure I wasn’t changing the current behavior of mac802154_hwsim. The intention was to maintain compatibility and avoid introducing any regressions, while extending the functionality in a non-intrusive way. > Why do we have a lot of wording of "wmediumd" when this is the > project/process part in user space? I should probably reconsider the title of the PR, especially since mac802154_hwsim already supports user-space interaction independently. As for the use of the term "wmediumd", I chose to reuse it because the new functionality aligns closely with the goals and structure of the original wmediumd project for mac80211_hwsim. Since both mac80211_hwsim and mac802154_hwsim serve a similar purpose, enabling kernel-level virtual radios for wireless experimentation, it felt natural to extend the naming convention to indicate compatibility and continuity. I didn’t see the need to reinvent something new when the existing model worked well and was familiar to the community. -- Ramon Em dom., 8 de jun. de 2025 às 22:49, Alexander Aring <aahringo@xxxxxxxxxx> escreveu: > > 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 >
