Wireless Daemon for Linux
 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 12:03:29 -0700	[thread overview]
Message-ID: <d2d0841b-62a0-c8df-924f-851df5f88203@gmail.com> (raw)
In-Reply-To: <7fdc5d67-e740-d593-253b-564bdf92048f@gmail.com>



On 5/8/23 11:55 AM, James Prestwood wrote:
> Hi Denis,
> 
> On 5/8/23 11:05 AM, Denis Kenzior wrote:
>> Hi James,
>>
>>>> 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.
>>>
>>
>> I get this part.  What bothers me is that the current dispatch code 
>> seems to be completely wrong?
>>
>>>>
>>>> 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.
>>
>> Sure.  To put it another way, hwsim works today by doing roughly the 
>> following:
>>
>> Suppose we have a setup with a single namespace, with 3 radios.
>>
>> Radio A with address aa
>> Radio B with address bb
>> Radio C with address cc
>>
>> When a _unicast_ frame with target 'cc' is seen by hwsim, it loops 
>> over A, B, C and compares the addresses.  If the addresses do not 
>> match, then no HWSIM_CMD_FRAME is issued for that radio.  So we'd only 
>> issue HWSIM_CMD_FRAME with Radio C's HWSIM_ATTR_ADDR_RECEIVER.
> 
> Ah ok, I see where you're coming from now. I overlooked that part. I can 
> re-work this and if the destination is a known radio then only forward 
> to that radio. If the destination is to an unknown radio I think we have 
> to forward it regardless.
> 
>>
>> What you're doing in this patch is to now issue the frame to each and 
>> every known radio.
>>
>> So suppose you change this to 2 namespaces, with Radio A+B in 
>> namespace A, Radio C in namespace C, etc.  Are you running 2 instances 
>> of hwsim? One per namespace?
> 
> Yes, a separate hwsim instance per-namespace.
> 
>>
>> How does it help if namespace A receives a frame with target 'CC'? It 
>> doesn't know about Radio C, so how would radio C even receive the 
>> message? And if it somehow does anyway, then it would seem like the 
>> above dispatch logic is bogus in the first place?
> 
> If a client in namespace A sends a frame to target CC then the hwsim 
> instance in namespace A gets this frame. It doesn't know about target CC 
> but the kernel does. So it forwards into the kernel and target CC 
> receives it.
> 
> I don't think there is anything wrong with the dispatch logic. There is 
> just a disconnect between what information hwsim knows vs the kernel. I 
> think tweaking the optimization I removed (described above) effectively 
> keeps things the same (assuming clients are sane and don't send frames 
> to completely bogus addresses).

Ok, actually I see your confusion now. Removing that block of code would 
send the frame to all *known* radios only... So this actually should not 
work, but it does.

Its like the kernel is disregarding ATTR_RECEIVER_ADDR and just looking 
at the frame contents. Anyways, I'll investigate.

> 
> 
>>
>>>
>>>   - 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.
>>>
>>
>> Right, I get that.  But this is not what my question is about :)
>>
>> Regards,
>> -Denis

  parent reply	other threads:[~2023-05-08 19:03 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
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 [this message]
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=d2d0841b-62a0-c8df-924f-851df5f88203@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