pci id 14e4:4727 (bcm4313) status?

pci id 14e4:4727 (bcm4313) status?

[Jason]

All,

I have a pci-express card that shows itself as pci_id 14e4:4727.  According to [1], it says partial support since 2.6.33 (b43/wl/brcm80211).  I was hoping that meant b43 since it has much better mac80211 integration than brcm80211.  I didn't think brcm80211 was in 2.6.33. 

However, compat-wireless (built from tarball) doesn't see it.  grep the source code doesn't pull up '4727' in b43... I tried to update my wireless-testing-2.6 tree, but it looks like it's still having trouble, latest is 229aebb... from Oct 24th.

So, what will it take to get it up and running?  I've contributed some patches to staging, but they're mainly janitorial/checkpatch stuff for brcm80211.  Are there some beginner tasks for b43 (ie dig through brcm80211 and port over) that might help out?

thx,

Jason.

[1] http://linuxwireless.org/en/users/Drivers/b43#Known_PCI_devices

pci id 14e4:4727 (bcm4313) status?

[Gábor Stefanik]

On Wed, Nov 3, 2010 at 5:28 PM, Jason <b43@lakedaemon.net> wrote:
> All,
>
> I have a pci-express card that shows itself as pci_id 14e4:4727. ?According
> to [1], it says partial support since 2.6.33 (b43/wl/brcm80211). ?I was
> hoping that meant b43 since it has much better mac80211 integration than
> brcm80211. ?I didn't think brcm80211 was in 2.6.33.
> However, compat-wireless (built from tarball) doesn't see it. ?grep the
> source code doesn't pull up '4727' in b43... I tried to update my
> wireless-testing-2.6 tree, but it looks like it's still having trouble,
> latest is 229aebb... from Oct 24th.
>
> So, what will it take to get it up and running? ?I've contributed some
> patches to staging, but they're mainly janitorial/checkpatch stuff for
> brcm80211. ?Are there some beginner tasks for b43 (ie dig through brcm80211
> and port over) that might help out?
>
> thx,
>
> Jason.
>
> [1] http://linuxwireless.org/en/users/Drivers/b43#Known_PCI_devices


Hi,

AFAIK 4313 is an SSB-less device, so it will probably never be
supported by b43 (though expect eventual code sharing between the 2
drivers).

>
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

pci id 14e4:4727 (bcm4313) status?

[Larry Finger]

On 11/03/2010 11:28 AM, Jason wrote:
> All,
> 
> I have a pci-express card that shows itself as pci_id 14e4:4727. 
> According to [1], it says partial support since 2.6.33
> (b43/wl/brcm80211).  I was hoping that meant b43 since it has much
> better mac80211 integration than brcm80211.  I didn't think brcm80211
> was in 2.6.33.
> However, compat-wireless (built from tarball) doesn't see it.  grep the
> source code doesn't pull up '4727' in b43... I tried to update my
> wireless-testing-2.6 tree, but it looks like it's still having trouble,
> latest is 229aebb... from Oct 24th.
> 
> So, what will it take to get it up and running?  I've contributed some
> patches to staging, but they're mainly janitorial/checkpatch stuff for
> brcm80211.  Are there some beginner tasks for b43 (ie dig through
> brcm80211 and port over) that might help out?

That device is not supported by b43. As it now stands, b43 requires a device
with the SSB interconnect, which the BCM4313 does not have. If you did fix b43
to operate without the SSB, then you would still have no support for N PHY. That
one is being worked on so that N PHYs with SSB can be supported.

My interpretation of the "partially supported" statement is that bleeding-edge
compat wireless has been backported that far.

My latest pull of wireless-testing has 2.6.37-rc1 from November 1. It includes
brcm80211.

Larry

pci id 14e4:4727 (bcm4313) status?

[Ariel Pedraza]

I have the 14e4:4727 and using the brcm80211, this is an example of what I get and the status of each commands:

airmon-ng #ok
airmon-ng stop wlan0 #ok
ifconfig wlan0 #ok
macchanger --mac yy:yy:yy:yy:yy:yy wlan0 #ok
airmon-ng start wlan0 #ok
airodump-ng mon0 #ok
airodump-ng -c canal -w nomarch --bssid xx:xx:xx:xx:xx:xx mon0  #ok, no datas

In other terminal:
aireplay-ng -1 0 -a xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, autentication succesful
aireplay-ng -3 -b xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, supose to increment datas but NOP!!!

In other terminal:
aircrack-ng -b xx:xx:xx:xx:xx:xx nomarch.cap #ok, no datas...

So... when do you think that the brcm80211 implemetation will be ready to capture datas? 


      

pci id 14e4:4727 (bcm4313) status?

[Gábor Stefanik]

On Thu, Nov 4, 2010 at 1:21 PM, Ariel Pedraza <pedrazaa@yahoo.com> wrote:
> I have the 14e4:4727 and using the brcm80211, this is an example of what I get and the status of each commands:
>
> airmon-ng #ok
> airmon-ng stop wlan0 #ok
> ifconfig wlan0 #ok
> macchanger --mac yy:yy:yy:yy:yy:yy wlan0 #ok
> airmon-ng start wlan0 #ok
> airodump-ng mon0 #ok
> airodump-ng -c canal -w nomarch --bssid xx:xx:xx:xx:xx:xx mon0 ?#ok, no datas
>
> In other terminal:
> aireplay-ng -1 0 -a xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, autentication succesful
> aireplay-ng -3 -b xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, supose to increment datas but NOP!!!
>
> In other terminal:
> aircrack-ng -b xx:xx:xx:xx:xx:xx nomarch.cap #ok, no datas...
>
> So... when do you think that the brcm80211 implemetation will be ready to capture datas?

Hmm... filter configuration issue? Apparently the "pass other-BSS
data" filter flag is not getting written to the hardware. (Do we even
have such a flag in the brcm80211 FW?)

Can you see any data packets in Wireshark on the monitor interface?

>
>
>
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

pci id 14e4:4727 (bcm4313) status?

[Gábor Stefanik]

2010/11/4 Henry Ptasinski <henryp@broadcom.com>:
> On 11/04/2010 07:39 AM, G?bor Stefanik wrote:
>>
>> On Thu, Nov 4, 2010 at 1:21 PM, Ariel Pedraza<pedrazaa@yahoo.com> ?wrote:
>>>
>>> I have the 14e4:4727 and using the brcm80211, this is an example of what
>>> I get and the status of each commands:
>>>
>>> airmon-ng #ok
>>> airmon-ng stop wlan0 #ok
>>> ifconfig wlan0 #ok
>>> macchanger --mac yy:yy:yy:yy:yy:yy wlan0 #ok
>>> airmon-ng start wlan0 #ok
>>> airodump-ng mon0 #ok
>>> airodump-ng -c canal -w nomarch --bssid xx:xx:xx:xx:xx:xx mon0 ?#ok, no
>>> datas
>>>
>>> In other terminal:
>>> aireplay-ng -1 0 -a xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok,
>>> autentication succesful
>>> aireplay-ng -3 -b xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, supose
>>> to increment datas but NOP!!!
>>>
>>> In other terminal:
>>> aircrack-ng -b xx:xx:xx:xx:xx:xx nomarch.cap #ok, no datas...
>>>
>>> So... when do you think that the brcm80211 implemetation will be ready to
>>> capture datas?
>>
>> Hmm... filter configuration issue? Apparently the "pass other-BSS
>> data" filter flag is not getting written to the hardware. (Do we even
>> have such a flag in the brcm80211 FW?)
>
>>
>> Can you see any data packets in Wireshark on the monitor interface?
>
> The following flags should all work with the brcm80211 FW:
>
> ? ? ? ?MCTL_KEEPBADFCS
> ? ? ? ?MCTL_KEEPCONTROL
> ? ? ? ?MCTL_PROMISC
> ? ? ? ?MCTL_BCNS_PROMISC
>
> The only one that's hooked up in the driver at the moment is
> MCTL_BCNS_PROMISC (for FIF_BCN_PRBRESP_PROMISC). ?I haven't taken a look at
> what it would take to enable monitor mode in the driver yet (setting up the
> monitor interface, etc).

For raw monitor mode, all but KEEPBADFCS are needed. If the "fcsfail"
monitor mode flag is also set, KEEPBADFCS should be enabled too.
For cooked monitor, AFAIK only KEEPCONTROL (and perhaps BCNS_PROMISC)
are needed.

However, do not set these based on interface type - use the FIF_ flags instead.

>
> - Henry
>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

pci id 14e4:4727 (bcm4313) status?

[Gábor Stefanik]

2010/11/4 G?bor Stefanik <netrolller.3d@gmail.com>:
> 2010/11/4 Henry Ptasinski <henryp@broadcom.com>:
>> On 11/04/2010 07:39 AM, G?bor Stefanik wrote:
>>>
>>> On Thu, Nov 4, 2010 at 1:21 PM, Ariel Pedraza<pedrazaa@yahoo.com> ?wrote:
>>>>
>>>> I have the 14e4:4727 and using the brcm80211, this is an example of what
>>>> I get and the status of each commands:
>>>>
>>>> airmon-ng #ok
>>>> airmon-ng stop wlan0 #ok
>>>> ifconfig wlan0 #ok
>>>> macchanger --mac yy:yy:yy:yy:yy:yy wlan0 #ok
>>>> airmon-ng start wlan0 #ok
>>>> airodump-ng mon0 #ok
>>>> airodump-ng -c canal -w nomarch --bssid xx:xx:xx:xx:xx:xx mon0 ?#ok, no
>>>> datas
>>>>
>>>> In other terminal:
>>>> aireplay-ng -1 0 -a xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok,
>>>> autentication succesful
>>>> aireplay-ng -3 -b xx:xx:xx:xx:xx:xx -h yy:yy:yy:yy:yy:yy mon0 #ok, supose
>>>> to increment datas but NOP!!!
>>>>
>>>> In other terminal:
>>>> aircrack-ng -b xx:xx:xx:xx:xx:xx nomarch.cap #ok, no datas...
>>>>
>>>> So... when do you think that the brcm80211 implemetation will be ready to
>>>> capture datas?
>>>
>>> Hmm... filter configuration issue? Apparently the "pass other-BSS
>>> data" filter flag is not getting written to the hardware. (Do we even
>>> have such a flag in the brcm80211 FW?)
>>
>>>
>>> Can you see any data packets in Wireshark on the monitor interface?
>>
>> The following flags should all work with the brcm80211 FW:
>>
>> ? ? ? ?MCTL_KEEPBADFCS
>> ? ? ? ?MCTL_KEEPCONTROL
>> ? ? ? ?MCTL_PROMISC
>> ? ? ? ?MCTL_BCNS_PROMISC
>>
>> The only one that's hooked up in the driver at the moment is
>> MCTL_BCNS_PROMISC (for FIF_BCN_PRBRESP_PROMISC). ?I haven't taken a look at
>> what it would take to enable monitor mode in the driver yet (setting up the
>> monitor interface, etc).
>
> For raw monitor mode, all but KEEPBADFCS are needed. If the "fcsfail"
> monitor mode flag is also set, KEEPBADFCS should be enabled too.
> For cooked monitor, AFAIK only KEEPCONTROL (and perhaps BCNS_PROMISC)
> are needed.
>
> However, do not set these based on interface type - use the FIF_ flags instead.

BTW, please consider a KEEPBADPLCP flag in the next firmware release -
it is needed for implementing the "plcpfail" monitor flag.

>
>>
>> - Henry
>>
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)