bes2600 driver

[explit]

OK, the Problem with random MAC-Address is known:
https://gitlab.com/TuxThePenguin0/bes2600/-/issues/5

[diederik]

The Mac randomization is coming from the bes2600 driver every boot and that is very weird

Maybe some of the other Pinetab2 Users here can tell, if they have the same Problem ?

PS: By the way, i tested SailfishOS Port from @piggz
The port itself is very stable, but the same problem with the random MAC-Addresses...

They should as it's a bug in the driver (or firmware).

It was not the best decision to choose BES2600 Chip for the PineTab2. In 2023, a chip which have only 802.11a/b/g/n and has not been tested on modern kernels is really very weird.
PineTabV has normal Realtek Chip with 802.11a/b/g/n/ac/ax
Why the hell?

Supply chain issues is the cause for the BES2600 driver. I agree that not having ac was disappointing.
The PineTab-V uses the same chipset as used by various other Pine64 devices and is and works fine.

The Gitlab page with source code for the bes2600 is maintained by 1 Person. Last commit was 4 month ago. I am very doubt, we will ever see a stable bes2600 for the Pinetab2

Because the Problem is complex, because the chip is mess and because its maintained only by one person (which done a very good job, but stil...)

Maybe Pine64 will see the Problem and will bring out replacement mainboards for PineTab2 with a normal wifi chip.

I would be VERY surprised if Pine64 would bring out replacement boards.

Unless someone(s) start working on the driver (which could mean writing a new one from scratch), I don't think we'll see any change in the (poor) state of the bes2600 driver.

IIRC, the 'maintainer' of that driver has said he has no interest in working on it. Consequently ...

The driver is MONTHS away from being useful ...

... I now think I was WAY too optimistic when I wrote that.

[tophneal]

it is most unfortunate that Tux's initial interest in tackling this driver has waned, and given it's started to stagnate with no other driver developers actively/openly working on it, I wonder if the community would be able to create a bounty (or something similar) to attract and compensate other developers to help us get a working mainline driver for the bes2600.

i've attempted to setup something similar in the early days of the PBP, but i'll be the first to admit i was ignorant to the best method and platforms to achieve this. if the community thinks this is worth a try, i'd be happy to set it up if anyone can suggest a good platform for the request/commision.

[gregb49]

it is most unfortunate that Tux's initial interest in tackling this driver has waned, and given it's started to stagnate with no other driver developers actively/openly working on it, I wonder if the community would be able to create a bounty (or something similar) to attract and compensate other developers to help us get a working mainline driver for the bes2600.

i've attempted to setup something similar in the early days of the PBP, but i'll be the first to admit i was ignorant to the best method and platforms to achieve this. if the community thinks this is worth a try, i'd be happy to set it up if anyone can suggest a good platform for the request/commision.

Maybe some sort of crowdfunding campaign, but I've not set up one myself so have no experience to offer.

[mattpenn]

It's a good idea and at the very least would demonstrate if a bounty funded approach has legs to solve some of these issues. It would be nice if Pine64 could match donations up to some ceiling too.

[459below]

In context of the whole "random mac address" topic I want to point out that it looks very much like whoever wrote it mean this as a feature and not a bug. If anyone with the proper understanding wishes to hard code their mac address into the driver, they can easily.

One might find in lines 

https://gitlab.com/TuxThePenguin0/bes260...=heads#L41

and

https://gitlab.com/TuxThePenguin0/bes260...heads#L262

We first set a template, i.e. 02:80:e1:00:00:00, for the mac address and in the second mentioned line we check whether the last 3 bytes of the currently set mac address are all equal to zero. Only if the mac address has all zeros at the end, the randomization is set. So, if one just changes the template to not have all zeros in the end, the randomization function is not called and the mac address will effectively remain as the one set as the template.

Changing this and recompiling the driver worked for me to achieve a stable mac address. Of course this is a workaround and not a clean solution to the issue. I agree with Kevin Köfler saying we should be honoring userspace override of the mac address https://gitlab.com/TuxThePenguin0/bes2600/-/issues/5

[explit]

Thank you very much, this worked like a charm!

@piggz Maybe you can do the same for the SailfishOS Build as well?

Thanks

[tllim]

it is most unfortunate that Tux's initial interest in tackling this driver has waned, and given it's started to stagnate with no other driver developers actively/openly working on it, I wonder if the community would be able to create a bounty (or something similar) to attract and compensate other developers to help us get a working mainline driver for the bes2600.

i've attempted to setup something similar in the early days of the PBP, but i'll be the first to admit i was ignorant to the best method and platforms to achieve this. if the community thinks this is worth a try, i'd be happy to set it up if anyone can suggest a good platform for the request/commision.

BES engineer already step in to help up and please contact Gamiee to join in this collaboration.

[Kevin Kofler]

So you have contacts to someone at BES working on the driver? Could you please talk to them about the licensing on the txrx_opt.c and txrx_opt.h files? The license header states a proprietary, GPL-incompatible license, so it ought to be fixed.

[tllim]

So you have contacts to someone at BES working on the driver? Could you please talk to them about the licensing on the txrx_opt.c and txrx_opt.h files? The license header states a proprietary, GPL-incompatible license, so it ought to be fixed.

On the licensing topic, this needs to discuss with BES management team.