On Wed, Dec 16, 2015 at 02:14:18PM -0800, Ben Greear wrote:
> On 12/16/2015 09:30 AM, Adam R. Welle wrote:
> >
> >>Well, it was always rather awkward since it was the *second* address :)
> >
> >Could somebody provide background information on why the decision was
> >made to use a second address for
> >> We could also set the address at creation time easily enough. Then
> >> it could still be unique across many machines if you managed it.
> >
> > I actually apply a patch for that. I have added a module parameter
> > which is used as the MAC address for the first radio, and I increment
> > the
On 12/16/2015 02:56 PM, Adam R. Welle wrote:
Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the
same address as was used for the non-netlink frames?
I would be fine with always using the first address instead
> > Could somebody provide background information on why the decision was
> > made to use a second address for the netlink frames instead of the
> > same address as was used for the non-netlink frames?
>
> I would be fine with always using the first address instead of the
> second, in case that he
On 12/16/2015 09:30 AM, Adam R. Welle wrote:
Well, it was always rather awkward since it was the *second* address :)
Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the same
address as was used for the non-ne
> > I should note that I am passing these frames between virtual machines
> > so the use of unique addresses (instead of hard-coded 0x42 addresses)
> > as a key simplifies things when determining which radio transmitted a
> > given frame and which radio needs to receive the frame. My app has
> > al
On Wed, Dec 16, 2015 at 05:30:20PM +, Adam R. Welle wrote:
>
> > Well, it was always rather awkward since it was the *second* address :)
>
> Could somebody provide background information on why the decision was
> made to use a second address for the netlink frames instead of the same
> addres
> Well, it was always rather awkward since it was the *second* address :)
Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the same
address as was used for the non-netlink frames?
I too have an obscure user-spac
On 12/16/2015 06:59 AM, Bob Copeland wrote:
On Wed, Dec 16, 2015 at 03:15:40PM +0100, Johannes Berg wrote:
On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
My code expected that the key was the MAC of the radio, not the
MAC of a vif. It set up mappings accordingly in the user-space
progra
On Wed, Dec 16, 2015 at 03:15:40PM +0100, Johannes Berg wrote:
> On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
>
> > My code expected that the key was the MAC of the radio, not the
> > MAC of a vif. It set up mappings accordingly in the user-space
> > program.
>
> I guess you were trying
On Wed, Dec 16, 2015 at 06:16:06AM -0800, Ben Greear wrote:
> Even so, I think it is more important to keep the kernel API stable than
> to work around issues in relatively obscure user-space apps.
Let's face it, everything using hwsim netlink api is already obscure :)
--
Bob Copeland %% http://
On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
> My code expected that the key was the MAC of the radio, not the
> MAC of a vif. It set up mappings accordingly in the user-space
> program.
>
> And, if I change a vif's mac address, the previous 'key' is no longer
> valid with the new patch.
On 12/16/2015 05:57 AM, m...@bobcopeland.com >> Bob Copeland wrote:
On Wed, Dec 16, 2015 at 05:27:44AM -0800, Ben Greear wrote:
Does this patch cause problems for your userspace implementation?
Yes, because I coded with the assumptions that the radio addr had nothing
to do with the vif addr.
On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
>
> > You can query the ID/index already through the netlink API, or even
> > from sysfs since the virtual device name is essentially
> > sprintf(name, "hwsim%d", idx)
>
> Good lord, please don't even suggest parsing the name. You can
> ea
On 12/16/2015 05:42 AM, Johannes Berg wrote:
On Wed, 2015-12-16 at 05:35 -0800, Ben Greear wrote:
Well, the old code used it as a key, and the old documentation used
it as a key, so it is a bit of a regression to change the behaviour
now.
But it's still used as a key, no? Just the value chang
On Wed, Dec 16, 2015 at 05:27:44AM -0800, Ben Greear wrote:
> >Does this patch cause problems for your userspace implementation?
>
> Yes, because I coded with the assumptions that the radio addr had nothing
> to do with the vif addr.
I see -- but looking back at wmediumd history (before I had any
On Wed, 2015-12-16 at 05:35 -0800, Ben Greear wrote:
> Well, the old code used it as a key, and the old documentation used
> it as a key, so it is a bit of a regression to change the behaviour
> now.
But it's still used as a key, no? Just the value changed. If you treat
it as a key then you'd jus
On 12/16/2015 05:25 AM, Johannes Berg wrote:
On Wed, 2015-12-16 at 05:13 -0800, Ben Greear wrote:
On 12/16/2015 01:17 AM, Johannes Berg wrote:
On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
This patch below was added to the kernel around 2/24/2015
I am curious mostly about the first cha
On 12/16/2015 05:21 AM, m...@bobcopeland.com >> Bob Copeland wrote:
On Tue, Dec 15, 2015 at 07:29:30PM -0800, Ben Greear wrote:
This patch below was added to the kernel around 2/24/2015
I am curious mostly about the first change: I thought the transmitter-addr
relates to the radio device, not
On Wed, 2015-12-16 at 05:13 -0800, Ben Greear wrote:
> On 12/16/2015 01:17 AM, Johannes Berg wrote:
> > On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
> > > This patch below was added to the kernel around 2/24/2015
> > >
> > > I am curious mostly about the first change: I thought the
> > >
On Tue, Dec 15, 2015 at 07:29:30PM -0800, Ben Greear wrote:
> This patch below was added to the kernel around 2/24/2015
>
> I am curious mostly about the first change: I thought the transmitter-addr
> relates to the radio device, not the vdev (sta, ap, etc).
>
> But, wouldn't using data from the
On 12/16/2015 01:17 AM, Johannes Berg wrote:
On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
This patch below was added to the kernel around 2/24/2015
I am curious mostly about the first change: I thought the
transmitter-addr relates to the radio device, not the vdev (sta, ap,
etc).
It
On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
> This patch below was added to the kernel around 2/24/2015
>
> I am curious mostly about the first change: I thought the
> transmitter-addr relates to the radio device, not the vdev (sta, ap,
> etc).
It doesn't, even on real hardware.
> But,
This patch below was added to the kernel around 2/24/2015
I am curious mostly about the first change: I thought the transmitter-addr
relates to the radio device, not the vdev (sta, ap, etc).
But, wouldn't using data from the header break that assumption?
Is there any actual advantage to havin
24 matches
Mail list logo
