Live data from Hacker News

Reverse engineering ESP32 Wi-Fi driver: the road ahead

esp32-open-mac.be

21–30 of 66 posts

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#21
post #2

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more spec…

What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?

You can do that today with the closed source wifi driver. This is not something limited by the wifi performance.

Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#22
post #21

Earlier quoted context omitted.

What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?

You can do that today with the closed source wifi driver. This is not something limited by the wifi performance. Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.

It’s a dual core MCU that runs at around 240MHz.

One of the main limitation tends to be to be around pushing pixels to the screen - most displays are serial (SPI) based which tops out at 80Mhz.

The other limitation is a lack of hardware video decoding. Some of the latest ESP32 chips are RISCV based and have SIMD instructions which can improve decode performance.

But if you pick an easy to decode codec (MJPEG) is popular. The you can get decent performance with the size of displays available.

https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#23
post #2

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more spec…

The ESP32 is 802.11n over 2.4ghz with no MIMO, so the bandwidth will always be bad.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#24
post #18

Earlier quoted context omitted.

The thing is, China as a culture does have a completely different attitude towards intellectual property. For them, copying is not theft, it's acknowledge of something's quality. Andrew "bunnie" Huang has written (at least) two articles with more details [1][2]. [1] https://www.bunniestudios.com/blog/2014/from-gongkai-to-open... [2] https://www.bunniestudios.com/blog/2013/the-12-gongkai-phone...

> copying is not theft, it's acknowledge of something's quality This is a common misconception. It is true that they don't think it is theft once it's widely available (even in underground community), but it's not because "copying is acknowledge of something's quality". This is one of the usual excuses. A better phrasing would be: modern (post-1980s) Chinese people [1] care more about who is able to build the thing,…

Isn't this exactly the MO of post-war Japanese industry? Copy everything from the west for the local market, then improve and make it better and cheaper then seel it in their market for profits?

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#25
It baffles me that a company like espressif wouldn’t publish complete API specs of their radio hardware . I could see why they may not want their proprietary source out there, as it might make it easier for competitors to make similar chips, but what is the downside to enabling someone to write software particular to your hardware?

It seems like they would have everything to gain and nothing to lose from this?

Anyone shed any light on the motivations here?

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#26
post #2

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more spec…

What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?

While many wifi cards have open driver interfaces they still have closed basebands (the software that actually drives the RF hardware) this is usually done for a combination of intellectual property and regulatory reasons. That is, they get to keep their secrets and the user can't make the radio do something it's not licensed to do.

These devs are aiming to open up the baseband of the ESP32 which allow for all kinds of interesting hacks, and probably all kinds of opportunities to run afoul of your countries laws regard spectrum use.

I do foresee some cases not entirely unlike the Flipper Zero arising from this but still wholeheartedly support it.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#27
post #25

It baffles me that a company like espressif wouldn’t publish complete API specs of their radio hardware . I could see why they may not want their proprietary source out there, as it might make it easier for competitors to make similar chips, but what is the downside to enabling someone to write software particular to your hardware? It seems like they would have everything to gain and nothing to lose from this? Anyone…

Really often that's because they license it from a third party and they are not allowed to.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#28
post #2

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more spec…

What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?

There are no newer-than-803.11n cards that are usable with a Linux-libre kernel (which doesn't load binary blobs).

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#29
post #2

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more spec…

What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?

Not great by modern standards... The standard ESP32 supports 802.11n, but only 2.4 GHz (not 5). So theoretical rates maybe up to 40-50 Mbps. In tests that I have seen people do on ESP32 they have reported practical speeds of 5-10 Mbps. Which is basically just in the typical range for Full HD video.

The ESP32-C6 has WiFi 6 support and 5 GHz, so theoretically that can be order of magnitude faster. But it might have completely different hardware and require separate reverse engineering. And practical speeds will still be limited compared to dedicated WiFi hardware.

Re: Reverse engineering ESP32 Wi-Fi driver: the road ahead

#30

Earlier quoted context omitted.

What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?

They're talking about open-source firmware, I would guess.

Exactly. And if that is managed, perhaps the codebase can be further adapted on the future to actually open hardware.
Post reply on HN