>
> > printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink"
> > " socket, switching to perfect channel medium\n");
> I wonder if we can do something better about them? Or perhaps if we
> should remove them, so other namespaces won't mess up the kernel log
This is in fact not
, even if they have been moved to other
network namespaces.
The wmediumd Netlink portid is tracked per net namespace. Additionally,
the portid is stored on all radios created in that net namespace to
simplify the portid lookup in the data path.
Signed-off-by: Martin Willi <mar...@strongswan.
registration from user namespaces.
Fixes: 7882513bacb1 ("mac80211_hwsimdriver support userspace frame tx/rx")
Signed-off-by: Martin Willi <mar...@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mac
Hi Johannes,
> So I think you should change the "wmediumd_portid" variable to live
> in struct hwsim_net and then allow HWSIM_CMD_REGISTER to be done
> inside the net namespace.
>
> With that, and making the other few wmediumd related operations
> namespace aware, we would be able to run
. This keeps the previous
behavior by returning them to the init namespace, but prevents unprivileged
users from creating radios in the initial namespace.
Signed-off-by: Martin Willi <mar...@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.c | 97 +--
1 file c
, add accessors.
* On namespace exit, do not destroy hwsim radios originally created in
the initial network namespace.
Martin Willi (2):
nl80211: Allow privileged operations from user namespaces
mac80211_hwsim: Allow managing radios from non-initial namespaces
drivers/net/wireless
ch implies a namespace aware lookup of the device. The only
exception is NL80211_CMD_SET_WIPHY, which explicitly uses a namespace aware
phy lookup.
Signed-off-by: Martin Willi <mar...@strongswan.org>
---
net/wireless/nl80211.c | 150 -
1 file change
> > Moving the radio back to the creators namespace would be the most
> > consistent behavior, so I'll check how difficult such a reverse
> > lookup is. We then would delete the radio only if it is in the
> > creators namespace, or if the creators namespace is gone. Does that
> > make sense?
>
> > +static __net_init int hwsim_init_net(struct net *net)
> > +{
> > + struct mac80211_hwsim_data *data;
> > + bool exists = true;
> > + int netgroup = 0;
> > +
> > + spin_lock_bh(_radio_lock);
> > + while (exists) {
> > + exists = false;
> > +
the same netgroup can
communicate even if not in the same namespace; This allows a controlling
namespace to create radios and move them to other namespaces for
communication.
Signed-off-by: Martin Willi <mar...@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.
ch implies a namespace aware lookup of the device. The only
exception is NL80211_CMD_SET_WIPHY, which explicitly uses a namespace aware
lookup.
Signed-off-by: Martin Willi <mar...@strongswan.org>
---
net/wireless/nl80211.c | 150 -
1 file change
such namespaces. Together, with these
patches an unprivileged test environment can create user/network
namespaces and set up abitrary simulated wireless networks.
Martin Willi (2):
nl80211: Allow privileged operations from user namespaces
mac80211_hwsim: Allow managing radios from non-initial
Hi Herbert,
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
our implementation or by one that is identical to us.
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still
Hi Steffen,
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm, without chaining with the IV.
Do you have any
14 matches
Mail list logo
