Message-ID: <CAK8U23brCSGZSVKZC=DcHMGKYPyG3SHOd9AoX0MdhbyfroTkWQ@mail.gmail.com>
Date: Sat, 7 Jun 2025 18:00:12 -0300
From: Ramon Fontes <ramonreisfontes@...il.com>
To: Alexander Aring <aahringo@...hat.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	linux-wpan@...r.kernel.org, alex.aring@...il.com, miquel.raynal@...tlin.com, 
	netdev@...r.kernel.org
Subject: Re: [PATCH] Integration with the user space

> 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.
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.

> 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.

--
Ramon

Em sáb., 7 de jun. de 2025 às 16:51, Alexander Aring
<aahringo@...hat.com> escreveu:
>
> Hi,
>
> On Sat, Jun 7, 2025 at 1:47 PM Ramon Fontes <ramonreisfontes@...il.com> wrote:
> >
> > Hi Alex, thanks for the feedback!
> >
> > You're right, using AF_PACKET raw sockets on a monitor-mode wpan_dev
> > is indeed sufficient for user-space access to the raw PHY, and we’ve
> > also tested that setup successfully for basic communication.
> >
> > However, if the use case focuses on evaluating realistic wireless
> > scenarios, where connectivity and interference vary across links. For
> > that, we rely on wmediumd, which integrates at the PHY level
> > (mac802154_hwsim) and controls per-link delivery based on configurable
> > SNR values and propagation models (e.g., log-distance, shadowing).
> > This allows us to emulate asymmetric topologies and partial
> > connectivity, something raw sockets alone cannot provide (or can?),
> > since all virtual radios are fully connected by default.
> >
>
> It sounds to me like you want to do some specific 802.15.4 things and
> the raw socket interface is too generic to do your tests.
>
> > In this context, wmediumd becomes essential for simulating:
> >
> > - Packet loss due to weak signal or distance;
>
> 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.
>
> > - Asymmetric links (e.g., node A hears B, but not vice versa);
>
> You can do that already with mac802154_hwsim, it is a directed network
> graph. A->B and B<-A need to be there so that A<->B can talk to each
> other, you can drop one of the edges and it is asymmetric.
>
> > - Controlled interference between nodes;
>
> netem again? Or any kind of tc egress action with a ebpf script.
>
> > - Link-specific behaviors needed for higher-layer protocol evaluation.
> >
>
> That can mean anything. I need more information.
>
> > Additionally, by inducing realistic transmission failures, wmediumd
> > allows us to test MAC-layer features like retransmission (ARET) and
> > ACK handling (AACK) in a meaningful way, which would not be triggered
> > in a fully-connected environment.
> >
>
> There is no ACK handling in mac802154 as it needs to be handled by the
> hardware, but I agree that there can be something similar like netem
> in 802.15.4 that only fake reports about missing acks, or failed
> retransmission to the upper layer. (whoever the user currently is and
> there is only one I know that is MLME association).
>
> > Let me know if you'd like me to elaborate further or clarify anything
> > about this.
> >
>
> I am not sure about this as there exists generic network hooks which I
> believe can be used to reach your use cases in e.g. tc. In combination
> with a ebpf program you can do a lot of specific 802.15.4 frame
> handling and do whatever you want. If you hit some limitations in
> those generic hooks then the right way is to extend those areas.
>
> Maybe the "fake" ack reporting is something that hwsim needs to
> support as this is usually implemented by the driver to ask the
> hardware for.
>
> 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.
>
> - Alex
>

Powered by blists - more mailing lists