From: James Prestwood <prestwoj@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 1/3] hwsim: remove 'optimization' sending to only known MACs
Date: Mon, 8 May 2023 06:43:09 -0700 [thread overview]
Message-ID: <39610c47-eaba-2299-9b03-5217355e8d47@gmail.com> (raw)
In-Reply-To: <54ae38d6-cc94-9410-8121-44ece399b24c@gmail.com>
Hi Denis,
On 5/7/23 4:21 PM, Denis Kenzior wrote:
> Hi James,
>
> On 5/4/23 16:52, James Prestwood wrote:
>> Based on the comment hwsim would only send frames to known MACs
>> which on its face seems reasonable. But in reality there shouldn't
>> ever be frames going to unknown MACs, at least not unknown to the
>> kernel. We can hit this case, though, when using network namespaces.
>> Each namespace is siloed and hwsim instances only know about radios
>> in that namespace.
>
> First, can you explain what is the motivation behind this series?
I'd like to enable hwsim to work with namespaces. First in order to test
the roam before netconfig changes. And maybe future tests would need this.
>
> Second, if we're passing unicast frames, and the unicast frame is
> addressed to a radio in a different namespace, how does that radio get
> the frame? We don't have it in our radio_info queue?
The namespace bars hwsim from seeing radios in other namespaces via
GET_WIPHY. So yes, the radios are not in the radio_info queue. But since
the radios are on the same kernel any MAC the kernel knows about is
accepted when sending a frame, regardless of namespace.
>
> The comment for the code you're taking out makes it clear that the
> intent is for unicast frames to be sent only only to the radio with the
> target receiver address. And the optimization is simply about not
> sending frames to radios with addresses we know do not have the target
> address.
>
> What you're doing here seems to indicate that our implementation (and
> the comment) is completely bogus. And we can simply send any frame to
> any radio instance (once) and the frames will be forwarded
> automagically. If so, then you might want to explain this better and
> fix the code to reflect this.
Maybe I described this badly, but I was trying to make 2 points:
- Historically, before namespaces, hwsim should never be in a
situation where a frame is addressed to an unknown recipient. Hostapd
won't do this and IWD won't do this. So all that code was doing is
looping through the radios. Maybe there is some case I haven't thought
of, in which case the kernel would drop the frame anyways.
- Then with the introduction of namespaces we actually do hit this
case of having unknown destination addresses. Not because they are
bogus, but because hwsim simply cannot know about radios in other
namespaces.
Thanks,
James
>
>>
>> In order to support hwsim and namespaces, this restriction is
>> being removed.
>> ---
>> tools/hwsim.c | 33 ---------------------------------
>> 1 file changed, 33 deletions(-)
>>
>
> Regards,
> -Denis
next prev parent reply other threads:[~2023-05-08 13:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 21:52 [PATCH 1/3] hwsim: remove 'optimization' sending to only known MACs James Prestwood
2023-05-04 21:52 ` [PATCH 2/3] test-runner: allow hwsim in namespaces James Prestwood
2023-05-04 21:52 ` [PATCH 3/3] test-runner: fix __str__ for namespace processes James Prestwood
2023-05-07 23:21 ` [PATCH 1/3] hwsim: remove 'optimization' sending to only known MACs Denis Kenzior
2023-05-08 13:43 ` James Prestwood [this message]
2023-05-08 18:05 ` Denis Kenzior
2023-05-08 18:55 ` James Prestwood
2023-05-08 19:00 ` Denis Kenzior
2023-05-08 19:03 ` James Prestwood
2023-05-08 19:01 ` Denis Kenzior
2023-06-21 21:05 ` James Prestwood
2023-06-27 2:31 ` Denis Kenzior
2023-06-27 15:15 ` James Prestwood
2023-06-27 18:00 ` Denis Kenzior
2023-06-27 18:56 ` James Prestwood
2023-06-27 19:23 ` Denis Kenzior
2023-06-27 20:09 ` James Prestwood
2023-06-28 14:49 ` Denis Kenzior
2023-06-28 15:33 ` James Prestwood
2023-06-28 15:40 ` Denis Kenzior
2023-06-28 16:14 ` James Prestwood
2023-06-28 16:25 ` Denis Kenzior
2023-06-28 16:47 ` James Prestwood
2023-06-28 16:57 ` Denis Kenzior
2023-06-28 17:22 ` James Prestwood
2023-06-28 23:19 ` Andrew Zaborowski
2023-06-28 23:28 ` James Prestwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39610c47-eaba-2299-9b03-5217355e8d47@gmail.com \
--to=prestwoj@gmail.com \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox