All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.