From: "Nikita N." <nikitan@operamail.com>
To: Arend van Spriel <arend@broadcom.com>
Cc: hauke@hauke-m.de, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org, Kalle Valo <kvalo@codeaurora.org>,
Pat Erley <pat-lkml@erley.org>,
brudley@broadcom.com, Franky Lin <frankyl@broadcom.com>,
meuleman@broadcom.com, linville@tuxdriver.com,
pieterpg@broadcom.com, hdegoede@redhat.com, wens@csie.org,
netdev@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: brcmsmac not compliant to 802.11 for BCM4313
Date: Wed, 04 Mar 2015 07:39:30 -0800 [thread overview]
Message-ID: <1425483570.3947119.235432705.0D7855AE@webmail.messagingengine.com> (raw)
In-Reply-To: <1424163814.3140549.228461101.1C2E5AB1@webmail.messagingengine.com>
Dear Arend,
as followup to my last inquiry, since it's passed more than 2 weeks, I'm
afraid I didn't receive any answer.
As from subject, I finally discovered that brcmsmac is not compliant to
802.11 regulations for BCM4313.
So, as purchasing customer, and member of Linux users community, I try
to propose my questions to you again now, 3 in total:
1) Regulatory domain - you wrote "brcmsmac does assure tx power is
within regulatory limits by enforcing a world regulatory domain"
That affirmation is *FALSE*.
I spent the whole weekend putting brcmsmac under heavy trace, all
functions, above all the phy ones.
Some code "supposes" to enforce a regulatory domain, but the effect is
total null.
I tried recompile the regulatory domain database, those functions did
not retrieve the new values.
Whatever values I set for domain 00, the effect was null - BCM4313 kept
functioning independently.
The functions, phy and not, which are "supposed" to set the eeprom
registries for regdomain enforce, have effect null - the BCM4313 kept
functioning independently.
I tried setting random numbers in those functions and registries, the
effect was null - the BCM4313 kept functioning independently.
At the edge of my frustration, I started commenting away from the code
those whole phy functions, the effect was null again - the BCM4313 kept
functioning independently.
I don't know for what Broadcom hw device were written and *tested* those
functions - but sure is, they do *NOT* work for BCM4313.
Could you please explain how/where the BCM4313 is supposed to "enforcing
a world regulatory domain" ?
2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
I informed you about this issue more than 1 year ago, and again 2 weeks
ago.
The issue still reproduces, and no sign of any fix.
When/in what backports version, this issue is supposed to be fixed
finally?
3) I explicitly purchased this BCM4313 already 1 year ago, with the
following specs: 0x4313 rev 0x01 package 0x08, 3 cores ChipCommon,
IEEE802.11 and PCIe.
I have been searching for any technical datasheet specification document
about BCM4313 on Broadcom website and others.
Did not find any.
Could you please send me a detailed technical datasheet specification
document about BCM4313, for programming/dev purposes?
Thank you & Greetings
On Tue, Feb 17, 2015, at 01:03 AM, Nikita N. wrote:
> Hi Arend,
>
> > brcmsmac does assure tx power is within regulatory limits by enforcing a
> > world regulatory domain. So what is not supported is modifying tx power
> > settings through user-space.
>
> Yes, I believe that could be right, *a* world regulatory domain looks
> indeed enforced, the USA one only, which is pre-set default inside
> EEPROM registries device, isn't it?
>
> > I know, but that driver is not fully open-source as it links in a binary
> > blob.
>
> AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
> those nothing works.
> Isn't it the same concept?
>
> > I totally lost track of this one. I am using brcmsmac in monitor mode
> > using bcm43224 which captures 11n frames just fine. I will give it a try
> > with a bcm4313. The assoc response in your capture shows undefined MCS
> > set so maybe there really are no 11n MCS rates used (?).
>
> If that was a suggestion about to purchase a bcm43224 or any other
> Broadcom Corp. product, isn't really convincing, seen the overall
> support quality Customers are experiencing in here...
> About my capture file, in the case it was really incomplete someone
> could have informed me at least a year ago.
> But anyway no respectable QA Testing team needs a purchasing Customer to
> help in verifying such enormous issue, isn't it?
>
> > Our team consist of two man working full-time on the upstream linux
> > drivers. So our "customer care" is something that we try to deal with on
> > the side and admittedly things slip between the cracks.
>
> Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
> values the Linux community?
> Needles to remind, even if Linux users don't pay for the OS license as
> Windows do, they do pay allright for any Broadcom hardware they
> purchase!
> Internet startups which sell a button on internet, they have Dev and QA
> team 5 times bigger than that!
> I sense a very gross capacity and resource planning competence issue in
> here.
> I kindly ask you, please forward that mail to your higher Managers, on
> my personal behalf, Thanks.
>
> --
> http://www.fastmail.com - Same, same, but different...
>
--
http://www.fastmail.com - Or how I learned to stop worrying and
love email again
next prev parent reply other threads:[~2015-03-04 15:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1424007136.2042747.227726249.45B6A0E2@webmail.messagingengine.com>
2015-02-16 13:53 ` brcmsmac: TX power blocked in BCM4313 Nikita N.
[not found] ` <54E2107F.4000709@broadcom.com>
2015-02-16 18:53 ` Nikita N.
[not found] ` <54E24B48.80601@broadcom.com>
2015-02-17 9:03 ` Nikita N.
2015-03-04 15:39 ` Nikita N. [this message]
2015-03-04 17:13 ` brcmsmac not compliant to 802.11 for BCM4313 Pat Erley
[not found] ` <54F7486B.7050608@broadcom.com>
2015-03-05 8:23 ` Nikita N.
[not found] ` <54F824D2.9030504@broadcom.com>
2015-03-05 18:50 ` Nikita N.
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=1425483570.3947119.235432705.0D7855AE@webmail.messagingengine.com \
--to=nikitan@operamail.com \
--cc=arend@broadcom.com \
--cc=brcm80211-dev-list@broadcom.com \
--cc=brudley@broadcom.com \
--cc=frankyl@broadcom.com \
--cc=hauke@hauke-m.de \
--cc=hdegoede@redhat.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=meuleman@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pat-lkml@erley.org \
--cc=pieterpg@broadcom.com \
--cc=wens@csie.org \
/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
all inboxes | Powered by JetHome®