netdev - Re: [PATCH] Integration with the user space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK-6q+g-A4T4RBg_BiRxR+G2k0_=Ma9nPZ1y=H=-F2FYDCUTMw@mail.gmail.com>
Date: Sun, 8 Jun 2025 21:49:28 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Ramon Fontes <ramonreisfontes@...il.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

Hi,

On Sat, Jun 7, 2025 at 5:00 PM Ramon Fontes <ramonreisfontes@...il.com> 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