Recently I reviewed the Orange Pi Zero 2 and thought it was a fantastic board. I really like the amount of polish that the Orange Pi line of products have as it is the closest I have seen to anything approaching a Raspberry Pi experience. We also benchmarked the Orange Pi Zero 2 and determined it’s a very capable board.
I recently got a Orange Pi i96 (thanks munecito!) and this board is very exciting because it was purchased on sale for ~$10! That is insanely cheap. The reason it’s so cheap is because it’s a headless board that doesn’t contain any display-out ports.
If you are going to be using the board headless anyway (I use most of my SBCs headlessly) you may be able to save a fortune with this board. Let’s get started!
Hardware Used
Orange Pi i96
The Orange Pi i96 is a low-cost board from the Orange Pi line of SBCs. It uses the RDA8810 SoC and has 256MB LPDDR2 SDRAM. It’s well suited for headless tasks and is astonishingly cheap.
The Geekworm copper heatsink set is designed to fit many different single board computers. It uses thermal conductive adhesive which many “cheap” heatsink kits for SBCs don’t have. Eliminates hotspots and reduces throttling. Can be further enhanced by powered cooling over the heatsinks.
The Orange Pi monitor is meant to be a portable monitor you can take anywhere. It has a resolution of 1080P and features a hinge in the back that folds out to support the monitor.
Alternatively you may use the official images (not recommended for this board). If you’d like to use the official images instead head to the official Orange Pi downloads page:
Orange Pi – Official Downloads Page
Now select the Orange Pi i96 from the list. I will be using Ubuntu Linux for this guide but you may use Armbian as well.
If you are wanting to try Android I highly recommend seeing my Orange Pi Android Installation Guide as the installation process is different than Linux.
Writing the Image
The images are typically distributed as a .tar.gz file. The name of the Ubuntu image tar.gz file at time of writing was OrangePi_i96_ubuntu_xenial_server_linux3.10.62_v0.0.4.tar.gz.
We will need to extract this file. If you are using Windows then grab 7-zip to be able to extract a .tar.gz file.
Inside this file will be a .img file. Since I downloaded the Ubuntu image the name of my file was OrangePi_i96_ubuntu_xenial_server_linux3.10.62_v0.0.4.img. This is the image that we are going to write to our SD card.
There are several choices to write the image to your SD card. If you are on Windows I recommend Win32DiskImager. Etcher is also available for Windows/Linux/Mac OS X.
Write the image to the SD card using your preferred software.
First Startup
Before starting up you should make sure that the Orange Pi’s switches are in these positions (indicating to boot from SD card):
Orange Pi – SD Startup PositionOrange Pi – SD Startup Position
We’re ready to put the SD card into the Orange Pi i96. But how are we going to connect to the device? There’s no network port and the device isn’t configured to connect to our WiFi yet.
Connection Option #1
If you happen to have a USB to Ethernet adapter that is the easiest way to connect to the device for initial configuration:
Once you’ve connected it’s time to do some basic configuration. We will use the tool orangepi-config:
sudo orangepi-config
You may now set the WiFi settings, etc. The orangepi-config is just like raspi-config if you’ve ever used that on a Raspberry Pi.
Don’t reboot before doing the next section.
Fix Second Startup (Debian / Ubuntu)
You will notice if you reboot the device it will often not come up the second startup. This is especially likely if you performed a sudo apt dist-upgrade.
To prevent this I recommend removing the alsautils package. This will impact sound functionality on the board but as I was not using it and intended to use this more as a headless board this was fine for me.
For the wireless to function very well at all you need to set the wireless regulatory domain.
If you are not using my image then you will first need to install the crda package with:
sudo apt install crda -y
Now we can set the regulatory domain by editing the following file:
sudo nano /etc/default/crda
At the bottom of the file there is this line:
REGDOMAIN=
Put the 2 letter country code for your country. Mine is “US”. Once finished press Ctrl+X then Y to save the file.
Optional – Upgrade Debian OS to Buster/Bullseye
Note that this will not upgrade the kernel. You can upgrade everything else though including all the way up to Bullseye. You should do this one release at a time and start with “Stretch” and then do “Bullseye” afterward.
If you are using the Debian installation you can upgrade to Buster by editing your /etc/apt/sources.list file.
Change all instances of “stretch” in the file to “buster” and then do the following:
sudo apt update && sudo apt dist-upgrade -y
Once this has completed reboot the system (make sure you’ve done my fix second reboot section first by purging alsa-utils). Verify you are on Buster with
Now you can upgrade to Bullseye. It’s almost the same as upgrading from Stretch to Buster but there has been a change in the security updates server format. Here is a working “Bullseye” apt sources file for the Debian Orange Pi i96 image:
root@orangepii96:/# cat /etc/apt/sources.list
deb http://ftp.debian.org/debian bullseye main contrib non-free
#deb-src http://ftp2.cn.debian.org/debian bullseye main contrib non-free
deb http://ftp.debian.org/debian bullseye-updates main contrib non-free
#deb-src http://ftp2.cn.debian.org/debian bullseye-updates main contrib non-free
deb http://security.debian.org/ bullseye-security main contrib non-free
#deb-src http://security.debian.org/ bullseye-security main contrib non-free
Once you’ve changed the files do a sudo apt update and make sure you don’t see any errors. If everything looks okay start the Bullseye upgrade with:
sudo apt full-upgrade -y
After a reboot you should be on Bullseye! We can verify this with cat /etc/os-release:
Notice that the kernel has not changed at all (as cautioned at the beginning of the section) but everything else on the system will be Bullseye!
Performance Benchmarking
I benchmarked the board using a SanDisk Extreme SD card on my Pi Benchmarks web site. This gives us comparable results between boards and there are over 30,000 benchmarks submitted for various boards / storage devices.
I had a total score of 497. This was below average or off from an average Raspberry Pi setup by about 47%.
To be clear the storage performance on the board is relatively low compared to the Orange Pi Zero 2 or a Raspberry Pi (Zero or 4). That is to be expected for a price of around ~$7-$10.
I’m not sure I would say this is a disappointing result though. We are talking about a board that is a single digit number of dollars. For the price point that is fantastic performance! In fact for the price point it’s a wonder that it works at all.
Conclusion
It’s a great board. At a price point of $7-$10 it reminds me of the really, really old Raspberry Pi Zero days where you could actually get a Raspberry Pi for around that price point.
The Zero 2 is a significantly more powerful board. It benchmarked much higher than the i96 but it also costs significantly more. If you need more power that board will be a better choice. If you’ve never had an Orange Pi before I would recommend the Zero 2 first as this board is quite a bit trickier and has more outdated software available for it.
The version of Ubuntu on this board is also quite old (Ubuntu 16.04 / Xenial) compared to the Orange Pi Zero 2 which is actually running a modern 5.X kernel whereas this one is a 3.X kernel. Make sure that is not going to be a problem or you will want to step up to a higher Orange Pi. The i96 is definitely meant for simple services / projects that don’t need a lot of power. It’s perfect for those.
If you need a headless board then the Orange Pi i96 may very well fit the bill for you, the price is certainly right! Don’t skip the heatsinks though. It got very warm during testing (warm enough to freeze once during consecutive benchmarks) and Orange Pis are known to get quite hot!
Fascinating! This hub actually works with the i96? Maybe it’s actually a compatibility issue with USB 3.0 hubs as I see this is a USB 2.0 hub. That’s kind of a big deal as there are lots of situations where one USB port is not going to be enough. This could actually let people use this for projects that I didn’t think they would be able to based on earlier USB 3.0 hub experimentation.
Great findings! I have a hub somewhere that is USB 2.0 that is meant for Raspberry Pi Zeros. I guess I really need to find that and see if it works. Thanks for sharing!
Seconded for sure. I’ve tried to get hubs working with it a few times and I can’t figure out if it’s something I can fix in the driver or if this is a hardware limitation or what is happening exactly.
Hubs are blacklisted intentionally by the kernel but I’ve gone as far as disabling that and several other steps and I never end up with even a functional USB afterward (for anything, not just hubs, it just won’t detect or work with anything).
I’m sure a USB expert could either tell us how to fix it or why we can’t fix it and I keep hoping someone who has ultra-low-level USB skills takes a look at this sometime here. I’ll probably try again as well as I don’t tend to ever “give up” on anything but will revisit it later which I do plan on still trying to either figure this out or completely understand why it’s impossible for whatever reason!
Roberto
2 years ago
Hello 🙂 Thank you for making this updated Debian image…
Have you tried including the 5.6.2 kernel? The people in this thread say it is working.
I have definitely seen that thread before. If you read the posts toward the end everyone says the SD card mapping doesn’t work on it. That’s definitely a dealbreaker for sure so I don’t think this would work without a lot more work.
If anyone wants to try implementing this and could get it to map the SD card storage successfully I’d definitely willing to update the kernel in this!
Excellent, great stuff! Thanks for sending me a tip as well. That’s very much appreciated!
Isaac
2 years ago
Hey – just a note. The company that makes the orange pi i96 has discontinued the product and has sold all remaining quantities to other resellers at a huge discount. So no more $5.99 boards at aliexpress. 🙁 Any of the ones you see floating around on the marketplace are the last few out there where vendors are trying to make a decent return on their investment.
I don’t think this has changed since I started this image. We knew it was abandoned 100%. I think what is changing is that they are selling now (for probably the first time ever since launch other than one person here or there). I personally bought a few and talked to others who have done the same. Those suppliers have probably had those boards for years.
There was no reason to buy this board until very recently as you couldn’t even use most of it. They haven’t updated their GitHub for this board since 2020 even. That is when they officially abandoned this board no matter what they say publicly. Once the dev work stopped the decision had been made internally and those people working on it were put on other boards.
I definitely think you’re right that the last ones out there are the last ones that are left. I don’t think they’ve manufactured one of these boards for YEARS. I’m sure of it. These are all stock sitting because the board was so unsuccessful and once it’s gone it’s probably gone! It’s their fault (Orange Pi’s) that this board was unsuccessful. We’ve literally proven at this point that the hardware was fine this entire time and that their image was just garbage.
The truth is when they were selling it for $7 they were actually trying to scam you. They knew that there was no image that had been updated in years and that most of the features in the base image were broken. They knew you weren’t going to be happy with it but they made the calculation that for $7 you’d probably forgive them or decide it’s not worth returning. They were just trying to get rid of them at whatever price. I’m guessing that most of the stock is starting to sell out and the smart sellers that track their inventory well have probably marked it up!
If they really have made some kind of announcement then I guarantee you it’s simply because we have finally depleted their Orange Pi i96 stock because they have not made them for a long time. This is a really good time to pick them up while you can still! It was always too good to be true to get a functional board for $7 and they never intended to offer it to us for this price. They were just trying to liquidate what they thought was a worthless board (because they themselves made the decision to stop updating it).
It may have also been embarrassing that someone else was fixing their image (starting out with the fixes submitted to their own GitHub they have ignored for years). It’s a bad look for them but I kind of wish they would keep making it and offering it for that price but the truth is we didn’t really expect that. We’ve been expecting a price increase at best and it looks like you may be right that once these are gone they are gone.
If Orange Pi was extremely intelligent they would chase this market. Raspberry Pi has left the low-end market wide open for the taking. People are hungry for it. Nobody wants to pay $80+ for a Raspberry Pi Zero 2 and this board for $7 is a much better value than the Raspberry Pi Zero 2 for $80+ without question in my mind!
This board could have worked. We’ve already fixed it to be “good enough” for most people at least for the price. If only they had stuck with it and supported their image! If I was in charge of their supply chain I could absolutely have made this product work and would continue selling it today for $7 (and boy would it sell in this climate/market with some marketing / resources behind it as well as a working image).
It’s honestly too bad that it looks like what is going to happen here is that these are going to become unavailable within the next couple of months. If this image wasn’t released it might have taken another year or two for them to liquidate these. This could have been the biggest project I ever did if they still were producing these but it sounds like they are going to run out and then the party will be over. There is literally a worldwide need for this product at this price point that is not going to be met by any other market players in the near future.
In other words myself and everyone who contributed to this image (or even saw this article and knew about it) beat the system. We got our boards for $7 (several of them) and fixed the image so it was fully functional (or it’s getting close). This was never supposed to be though and it looks like it’s already having consequences for the availability / pricing which will continue to get worse. It’s one thing when dozens of people beat the system. It’s another thing entirely when hundreds or thousands of people start beating the system because then the system will change.
Oh wow – I didn’t know these were discontinued. I messaged the company because I wanted more of them, and they had sold out but had in the neighborhood of like 500 left when I last chatted with them. I bought these just by chance because I was looking for alternative hardware for projects… I picked up 4 of these (because they were so cheap), a couple of mango pis, a couple of banana pis. I was thinking to myself, hey, if my projects will work on these, I can get more. There, unfortunately, is not a reliable supply of raspberry pis… I just bought a 100 rpi w0 1.3 boards for 3k last week (good price today, horrible price 3 years ago) and I honestly don’t know when or where I’ll be able to get more when I run out.
No worries at all, that’s amazing that you got 100 RPI boards for that price! It’s a very tough market right now for sure. That’s interesting that they had something like 500 of the i96 left. I was hoping it was more like 5,000-10,000 but it doesn’t sound like they had a ton left to begin with.
Thanks for sharing this, I love hearing from people who are working inside the industry about what kind of prices/availability they’re seeing! I don’t know that I would recommend buying 100 i96 devices but I definitely would recommend to basically anyone who works with SBCs to buy a few of them to have as just light duty boards / use for projects where there’s a chance of them getting damaged / stolen or even throwaway applications. If you had a use case where you knew the board was going to be lost/destroyed in the process I would *never* put a Raspberry Pi Zero 2 or even Zero in something like that (at least now, I would have a couple of years ago) and today would use a sacrificial i96 (and sleep like a baby afterward).
I personally have 3 now. They’re really good for my use cases that don’t need a lot of power but still benefit from being very small like a Raspberry Pi Zero (and requiring hardly any electricity to run either relative to almost anything else). It’s basically a (very soon to be formally) $10-$15ish tool that I think people who work with SBCs a lot will find quite handy/convenient and will find themselves using it for things that wouldn’t have made sense to dedicate a Raspberry Pi to and might not even have done otherwise. I won’t lie, your news has convinced me I probably should grab another 2-3 before it’s too late based on the numbers you’ve given me. Time is short.
This is how I used Raspberry Pis for years (as I’m sure many of you have/do) which is why I found these i96 boards so refreshing. I finally had access to super cheap boards again and since a lot of my Raspberry Pis have made their way into permanent builds like my Pwnagotchi it was definitely at just the right time. I don’t have as many Raspberry Pi Zeros laying around anymore that aren’t already in builds that I am using / don’t want to take apart. I’ll definitely replenish my Raspberry Pi Zero supplies as well when this shortage ends but it looks like this may still go on for quite some time.
This lets you save your expensive/low-availability boards for the stuff you’re doing that needs that power/flexibility. A lot of the time you just need a really cheap computer to shove into a box or stick on the shelf to run some light service / application. The Raspberry Pi Zero used to be that but as everyone knows that has not been the case for some time now mainly due to availability (and scalpers). Given that we have a reasonably updated Bullseye image these boards should be very useful for this purpose for years. They definitely all have their place!
Excellent, that’s still a decent amount of them left for anybody who would like to grab some. Thanks for sharing!
Marco
2 years ago
Nice commits you have done lately, but still having massive wireless issues, sudden disconnects and especially if i enable bluetooth scan.
for example connect via wifi to your network and start downloading a bit file via wget, open a second ssh shell and start scanning via bluetoothctl (scan on).
cfg80211_disconnected
[ 562.800537] cfg80211: All devices are disconnected, going to restore regulatory settings
[ 562.801391] cfg80211: Restoring regulatory settings
[ 562.802001] cfg80211: Kicking the queue
[ 562.802490] cfg80211: Calling CRDA for country: DE
[ 563.056457] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 563.062500] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.063415] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 563.064575] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.065368] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 563.069335] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.070251] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 563.071350] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.074157] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 563.075012] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.076293] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 563.077758] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.078491] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 563.079772] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.082519] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 563.083312] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.084228] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 563.085388] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.086120] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 563.087707] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.091491] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 563.092346] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.093261] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 563.094238] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.095153] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 563.096130] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.100036] cfg80211: Disabling freq 2484 MHz
[ 563.100463] [RDAWLAN_ERR]:: reg_notifier for intiator:3 not supported
[ 563.101562] cfg80211: Regulatory domain changed to country: DE
[ 563.102233] cfg80211: DFS Master region ETSI
[ 563.102783] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.103820] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.105163] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2301 mBm)
[ 563.105895] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.110168] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm)
[ 563.110900] cfg80211: (5725000 KHz - 5875000 KHz @ 80000 KHz), (N/A, 1397 mBm)
[ 563.111816] cfg80211: (5945000 KHz - 6425000 KHz @ 160000 KHz), (N/A, 2301 mBm)
[ 563.112792] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[ 563.114624] cfg80211: Calling CRDA to update world regulatory domain
[ 563.157592] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
[ 563.158752] [RDAWLAN_ERR]:: reg_notifier for intiator:0 not supported
[ 563.160339] cfg80211: World regulatory domain updated:
[ 563.160888] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.161926] cfg80211: (755000 KHz - 928000 KHz @ 2000 KHz), (N/A, 2000 mBm)
[ 563.162719] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.163635] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 563.165039] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 563.165771] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.166687] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.171325] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm)
[ 563.172180] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.173034] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm)
[ 563.174194] cfg80211: Calling CRDA for country: DE
[ 563.214843] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 563.215637] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.216552] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 563.219604] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.220397] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 563.221374] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.222290] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 563.223754] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.224487] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 563.225463] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.226379] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 563.230346] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.231079] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 563.232055] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.233032] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 563.234497] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.235229] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 563.236206] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.239440] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 563.240356] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.242187] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 563.242980] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.243896] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 563.244873] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.248779] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 563.249572] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.250488] cfg80211: Disabling freq 2484 MHz
[ 563.251037] cfg80211: Regulatory domain changed to country: DE
[ 563.252197] cfg80211: DFS Master region ETSI
[ 563.252502] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.253540] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.254455] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2301 mBm)
[ 563.255371] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.256774] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm)
[ 563.261901] cfg80211: (5725000 KHz - 5875000 KHz @ 80000 KHz), (N/A, 1397 mBm)
[ 563.262756] cfg80211: (5945000 KHz - 6425000 KHz @ 160000 KHz), (N/A, 2301 mBm)
[ 563.263671] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[ 565.070068] [RDAWLAN_DCMD]: Connecting to 2c:3a:fd:ff:76:aa
[ 565.101623] [RDAWLAN_CFG80211]: connected. wland_bss_connect_done
[ 565.102539] [RDAWLAN_CFG80211]: Report connect result - connection succeeded
the ssh session will drop, the speed for the download will fall to almost zero and cfg80211 disconnect happens.
now i also realised that before disconnecting cfg80211 the regulation is not set (to country 00 by default).
but what bothers me the most is the sudden disconnects from cfg80211
Is this different from older versions? My guess is that you can just see it now because tracing is enabled. The driver never respected or uses the regulatory settings. It’s overridden here:
Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
This is because of this code in the wireless driver:
/* This is to override regulatory domains defined in cfg80211 module (reg.c)
* By default world regulatory domain defined in reg.c puts the flags
* NL80211_RRF_PASSIVE_SCAN and NL80211_RRF_NO_IBSS for 5GHz channels (for
* 36..48 and 149..165). With respect to these flags, wpa_supplicant doesn't
* start p2p operations on 5GHz channels. All the changes in world regulatory
* domain are to be done here.
*/
static const struct ieee80211_regdomain wland_regdom = {
.n_reg_rules = 4,
.alpha2 = "00",
.reg_rules = {
/*
* IEEE 802.11b/g, channels 1..11
*/
REG_RULE(2412 - 10, 2472 + 10, 40, 10, 30, 0),
/*
* IEEE 802.11 channel 14 - Only JP enables this and for 802.11b only
*/
REG_RULE(2484 - 10, 2484 + 10, 20, 6, 20, 0),
/*
* IEEE 802.11a, channel 36..64
*/
REG_RULE(5150 - 10, 5350 + 10, 40, 6, 20, 0),
/*
* IEEE 802.11a, channel 100..165
*/
REG_RULE(5470 - 10, 5850 + 10, 40, 6, 20, 0),
}
};
It only tried to apply the regulatory settings because you were disconnected:
All devices are disconnected, going to restore regulatory settings
In other words I doubt this has anything to do with regulatory. I just have all of the regulatory output enabled right now in the kernel with this flag: CONFIG_CFG80211_REG_DEBUG=y. What I would suggest doing is turning tracing on in the driver so you can see all of the output:
sudo su
cd /sys/kernel/debug/rdawfmac/mmc1*
echo 5 > dbglevel
This will show all the wireless issues really going on (you’re seeing probably 1% of the messages available right now). The Orange Pi will become very slow in this mode because there’s so much. You will feel it immediately and if you do a dmesg it will be absolutely spammed with output. We really do need a capture like this to know what’s going on because (as you will see) you are honestly seeing nothing in that output. Hopefully it will give some more information about why you were disconnected here!
You can adjust the levels lower to reduce the amount of output (and you’ll probably have to). I had to do a combination of this as well as modifying the WiFi warning levels within the driver (and add a bunch of new messages where there was no output previously) in order to make the output more useful and less spammy.
The default # in the latest versions is 3 (WLAND_INFO_LEVEL). It used to be 0 (errors only) which is why you basically couldn’t see anything before (it was all still happening though). I have enabled this setting inside debugfs which means you can change it on the fly without rebuilding the kernel now. I did this both so people can start getting captures and start taking matters into their own hands with pull requests for issues here in there in the driver (as it is impossible to debug without this output and I wanted a way for people to see it without rebuilding the kernel).
I’d say maybe try stepping it up to 4 first because 5 is absolute spam (but tells you everything). Even turning it up there are no guarantees it will give you the output we need. There’s so much output though that you will be able to know where it was in the code and what it was doing when things went wrong though and that was enough for me to start on the few I’ve tried to tackle so far of the many, many issues in the driver. I had to add a dozen brand new debug messages that did not exist before into the wireless driver to even try to begin to figure out what it was doing just to try and diagnose the txpower. I’m still not sure what is going on with all the iovar variables that are disappearing and not stored/retrieved correctly.
I don’t think it’s an exaggeration to say there are dozens of issues with this wireless driver. I definitely don’t expect it to be fixed any time soon. It doesn’t even store that country code correctly in the driver settings which is why it always says 00. I recently learned the hard way that even if I disabled their code that overrides the regulatory settings that is just the tip of the iceberg. It doesn’t store the country code correctly and always shows it receives ’00’. In fact originally the country was set to “99” which actually doesn’t show anywhere (it always shows 00, the driver doesn’t seem to retrieve these types of settings correctly).
I’m enabling this type of tracing for other systems everywhere I encounter them as I’d imagine there are many other things that are broken like this that we just can’t see. There’s virtually no downside to the ones that can be controlled by the user in /sys/kernel/debug because if they aren’t being used then nothing will happen (and the extra size of the kernel from including the debugfs features is negligible compared to the “main” features themselves which is how you really save space). It’s only as I’ve been learning and trying to diagnose some of these issues that I’ve realized how valuable the tracing stuff is (especially the ones that can be adjusted on the fly through /sys/kernel/debug). The problem might actually be in the Bluetooth part of the driver which this tracing level will probably actually let you see without having to change too much else.
The only way this will ever get fixed is with other people’s help for sure and people taking a look at it and fixing the problems here and there. For example the sensitivity reads as: “Sensitivity=30/0”. My desktop doesn’t even show that measurement but it does not look correct at all. In fact the driver doesn’t seem to store any settings correctly at all. It’s very overwhelming to work with at first but I was just going in circles/guessing until MB3hel pointed me toward the tracing settings in the source code. I then took it further by enabling debugfs support for rdawfmac so this could be adjusted by anyone at any time. Once I could actually see what was happening (and started filtering through the noise and adding my own messages) I was finally able to make some progress. Let’s see what your output looks like with the tracing level turned up here!
EDIT: It may have been my txpower settings. I set it back to 20 like the board has as the default (it may be the limit, still investigating that) and my board stayed connected stable for several hours again. I also set the regulatory domain back to ’99’ which it turns out has a special meaning in cfg80211 (it means the driver sets an override). I think this may be what is preventing the disconnects. Can you try with 1.29?
MZA
2 years ago
Hi all,
Good news, I’ve got CAN bus working with mcp2515.
I’ve done too much things ( not all clever) to have it but now, I’ll go back to the latest Legendary kernel and do it properly again before submitting it.
I96 def_config file update and devices.c have been uploaded to OrangePi-I96-Work to make CAN bus transciever MCP2515 work instead of spidev2.1 ( SPI2 CS_1) and with interrupt pin on D02 ( H26).
After kernel compilation with CAN BUS flags and device MCP251x, install can-utils package on orangepi sudo apt-get install can-utils
bring CAN interface up with the desired bitrate sudo ip link set can0 type can bitrate 1000000
sudo ip link set can0 up
send a frame : cansend can0 123#DEADBEEF
see incoming frames : candump can0
use loop mode : sudo ip link set can0 down
sudo ip link set can0 type can bitrate 1000000 loopback on
sudo ip link set can0 up
Fantastic work, everything looks good to me! I’m surprised you were able to add this in without breaking the other functionality if I’m looking at this correctly. Someone did manage to get spidev working with a Waveshare e-paper display. Will this change break it? I guess it depends on whether they are using spidev2.0 or 2.1 (or do they always have to use 2.1?). That was my main concern with this change is that everyone would have to build their own kernel (which is why things like device trees that give you other options than this are so awesome).
Is it possible to have them all enabled at once (using either bus_num or chip_select or any of those variables) or are we going to run out of pins? Since the GPIO SPI is all software controlled couldn’t we theoretically have a whole bunch of these? Even if not this is still huge progress. I really like that you left it configurable with kernel flags.
Theoretically I could modify the build system to produce multiple images with different options available. I’m hoping that this won’t break the other person’s though that they got working. It’s probably not unreasonable to expect someone to build this project that wants to work with a device like this and be able to change the driver theoretically but then the question becomes what should be the default behavior.
I’m packaging and releasing this as 1.26 if you’d like to give it a try and make sure I got everything in there properly! I’d definitely say it’s worth resyncing with me on this version as it’s much cleaner than the older builds (both in how the code is organized as well as dmesg / syslog output) and is starting to look really good. The only bug I even know of right now is the WiFi driver shows the txpower as 1 (which I think is a display glitch because if it was really 1 I wouldn’t be able to connect and use it)!
Hi James,
I think that the essay with the epd uses user-land driver, I’ve tried such a driver ( it’s more an application) and no other driver has been added to the devices.c. I’ve pulled out your latest version. So it opens the /dev/spidev2.0 which uses the CS on header pin N°16. He may be using the spidev2.1 but he would have to use the other.
You can use the devices.c without activating the MCP251x flag, it will produce the two spidev(s). Any one that needs the CAN, will have to enable the flag and compile the kernel.
By the way, prices of the OrangePI have doubled, they’re now at +13 EUR excluding shipping, I missed ordering some.
Now for the CAN bus, I’m seeing RX errors with some traffic, I guess the spi-gpio is not able to deal with it, I will try to debug ASAP. Small traffic is OK.
Outstanding! I’ve implemented the changes as you’ve suggested here in 1.27. Thanks for your work on this and I’m so glad you were able to get it functioning after all your work on it!
I noticed the Orange Pi prices have risen a little bit as well. It’s now $18 on amazon.us but that’s not too large of an increase since they didn’t used to have prime / free shipping. They only have one left in stock though which they used to have literally as many as you wanted to order for as long as I can remember.
It’s getting pretty close to the 1 month anniversary for the image and it’s almost unrecognizable from the original image at this point. It definitely adds a full half-dozen features that were completely inaccessible/broken and a couple of those (the most technically impressive ones at least to me as my strengths do not lie with the pin assignments and hardware level your changes are interacting with but I’m slowly learning) are thanks to your work. I look forward to anything else you find with it when debugging!
Hey James,
I’ve linked the RX frame loss to bursts while having 1Mbps bitrate on the bus.
This is an already discussed topic on the net, there are some patches to avoid race conditions in the mcp251X driver that I borrowed but it did not fix the problem. It is mainly due to slow spi transfer. I tried using higher priory irq handler but I did not do the job.
I think going back another time to rda-spi driver will be the solution but I’ll try it in the future, I need to check the I2C now.
Fascinating findings! That sounds good to check out the i2c as I haven’t heard much from people working with that yet. This actually makes a lot of sense.
I finally got a USB to UART adapter ordered. I’ve enjoyed doing the fixes on this enough that I want to dive more into the lower level hardware and this tool will help a lot. There are things happening with these protocols I don’t understand and I don’t like it. Especially with diagnosing the WiFi from my desk without having to use the USB to Ethernet adapter will help me do some more low-level debugging (at least at a more efficient pace).
My old setup had my i96 in the basement on the USB to Ethernet adapter so every time I built an image I had to go to a different story of the house. Recently I upgraded the build tool to be able to preconfigure an image if you create a “presets” folder in the external folder. This lets me build images during development that already have my WiFi configured as well as other things to save time. This worked well but the problem is when I was working on the WiFi I would often break it and then I couldn’t see what was happening. In that case I had to remove the SD card from the i96 to access the logs and even see them (slow). Once I receive this I will be able to use the serial console right from my desk without any network connection at all.
There are other tools called the bus pirate and Shikra that also will interact with SPI/I2C and other protocols. I don’t know enough about those ones yet to know what the best adapter / tool would be to do testing with but I saw some interesting ones.
Hey James,
You’ll probably need to add lrzsz package to be able to transfer files with zmodem over the serial link. I use it exclusively, I could do nothing with ssh and scp over Wi-Fi. The latest improvements of the wi-fi made it some how possible but not as quick and reliable as through the serial link.
That’s actually some really good news for a change that something is working correctly without a lot of additional fixes/assistance! I should be able to add the lszrx package in for sure here in the next version.
Has anyone attempted to get a WiFi hotspot working on this device? I’ve been attempting to get this working with hostapd (bullseye image version 1.20), but have been unable to get it to work.
On line 476 wland_cfg80211.c (OrangePiRDA_Kernel repo) it seems that no driver for AP mode is implemented.
However, the iw tool lists AP as a supported mode.
Supported interface modes:
* managed
* AP
Is there perhaps a different interface to work with AP mode than NL80211 that works with this device or a different kernel driver I should try that may have support for AP mode implemented? My familiarity with the low-level Linux network stack is minimal, so I’m not really sure where to go from here.
This lets it work with the driver but I’m seeing errors. You can run it like this to get the debug output:
sudo hostapd -d /etc/hostapd/hostapd.conf
This will work but this is the output I get:
orangepi@orangepii96:~/hostap/hostapd$ sudo hostapd -d /etc/hostapd/hostapd.conf
random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=0
nl80211: Could not add multicast membership for vendor events: -2 (Interrupted system call)
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:6
nl80211: Using driver-based off-channel TX
nl80211: key_mgmt=0xd0f enc=0x10f auth=0x7 flags=0xd0c0 rrm_flags=0x0 probe_resp_offloads=0x0 max_stations=0 max_remain_on_chan=5000 max_scan_ssids=10
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 3 (AP)
nl80211: Setup AP(wlan0) - device_ap_sme=1 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0xb7d27100 (device SME)
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=04 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 04
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0501 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0503 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0504 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=06 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 06
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=08 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 08
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=09 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0a multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 0a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=11 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 11
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=7f multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 7f
nl80211: Failed to subscribe for mgmt frames from SME driver - trying to run without it
nl80211: Enable Probe Request reporting nl_preq=0xb7d26e98
nl80211: Register frame type=0x40 (WLAN_FC_STYPE_PROBE_REQ) nl_handle=0xb7d26e98 match= multicast=0
rfkill: initial event: idx=2 type=1 op=0 soft=0 hard=0
nl80211: Could not re-add multicast membership for vendor events: -2 (Interrupted system call)
nl80211: Add own interface ifindex 3 (ifidx_reason -1)
nl80211: if_indices[16]: 3(-1)
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code US
Continue interface setup after channel list update
ctrl_iface not configured!
random: Got 20/20 bytes from /dev/random
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 40 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
Completing interface initialization
Mode: IEEE 802.11g Channel: 6 Frequency: 2437 MHz
DFS 0 channels required radar detection
nl80211: Set freq 2437 (ht_enabled=0, vht_enabled=0, he_enabled=0, eht_enabled=0, bandwidth=20 MHz, cf1=2437 MHz, cf2=0 MHz)
* freq=2437
* eht_enabled=0
* he_enabled=0
* vht_enabled=0
* ht_enabled=0
* radar_background=0
* channel_type=0
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
hostapd_setup_bss(hapd=0xb7d27fa0 (wlan0), first=1)
nl80211: flush -> DEL_STATION wlan0 (all)
Using interface wlan0 with hwaddr fe:ae:e0:39:f9:41 and ssid "orangepi"
Deriving WPA PSK based on passphrase
SSID - hexdump_ascii(len=8):
6f 72 61 6e 67 65 70 69 orangepi
PSK (ASCII passphrase) - hexdump_ascii(len=8): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
GMK - hexdump(len=32): [REMOVED]
Key Counter - hexdump(len=32): [REMOVED]
WPA: Delay group state machine start until Beacon frames have been configured
nl80211: Set beacon (beacon_set=0)
nl80211: Beacon head - hexdump(len=59): 80 00 00 00 ff ff ff ff ff ff fe ae e0 39 f9 41 fe ae e0 39 f9 41 00 00 00 00 00 00 00 00 00 00 64 00 11 04 00 08 6f 72 61 6e 67 65 70 69 01 08 82 84 8b 96 0c 12 18 24 03 01 06
nl80211: Beacon tail - hexdump(len=31): 2a 01 04 32 04 30 48 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
nl80211: ifindex=3
nl80211: beacon_int=100
nl80211: beacon_rate=0
nl80211: rate_type=0
nl80211: dtim_period=2
nl80211: ssid=orangepi
* beacon_int=100
* dtim_period=2
nl80211: hidden SSID not in use
nl80211: privacy=2
nl80211: auth_algs=0x1
nl80211: wpa_version=0x2
nl80211: key_mgmt_suites=0x2
nl80211: pairwise_ciphers=0x10
nl80211: group_cipher=0x10
wlan0: Deauthenticate all stations at BSS start
nl80211: sta_remove -> DEL_STATION wlan0 ff:ff:ff:ff:ff:ff --> 0 (Success)
WPA: Start group state machine to set initial keys
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GTK - hexdump(len=16): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=3 addr=0xb6eed1b4 key_idx=1 set_tx=1 seq_len=0 key_len=16 key_flag=0x1a
nl80211: NEW_KEY
nl80211: KEY_DATA - hexdump(len=16): [REMOVED]
broadcast key
nl80211: NL80211_CMD_SET_KEY - default key
nl80211: Set wlan0 operstate 0->1 (UP)
netlink: Operstate: ifindex=3 linkmode=-1 (no change), operstate=6 (IF_OPER_UP)
nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95
Failed to set TX queue parameters for queue 0.
nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95
Failed to set TX queue parameters for queue 1.
nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 2.
nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 3.
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED
wlan0: Setup of interface done.
Maybe I have it configured incorrectly. There’s some errors throughout such as “Operation already in progress” and “Failed to set TX queue parameters for queue X.”. My /etc/hostapd/hostapd.conf looks like this:
I think the problem might be here in my debug output (Unknown event 47 after scan started):
wlan0: nl80211: Scan trigger
wlan0: Event SCAN_STARTED (47) received
Unknown event 47
nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlan0
wlan0: nl80211: New scan results available
nl80211: Scan probed for SSID ''
I figured I’d show you how far I got before I got stuck. It may be additional configuration or maybe the driver needs fixes somehow for it to work but hopefully this lets you get a little further in your testing!
Hi, thanks for the info. Building as shown I’ve been able to get very similar output. However, I believe other lines in the output may be indicators of actual issues. The lines you indicated above seem to indicate something to do with SSID scanning (station mode). I don’t get these lines when I disable connection to stations when attempting to run hostapd (I just set a static ip for wlan0 in /etc/network/interfaces).
There are some other lines that are interesting though. In particular these lines (close to the top of the output)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code US
Continue interface setup after channel list update
ctrl_iface not configured!
random: Got 20/20 bytes from /dev/random
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 40 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
Completing interface initialization
This output would seem to indicate that setting the country code failed. The channel list update times out and the regulatory information still shows a null country code.
The next interesting section is near the end of the log output
nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95
Failed to set TX queue parameters for queue 0.
nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95
Failed to set TX queue parameters for queue 1.
nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 2.
nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 3.
I’m not really sure what this means, but from a little googling it seems that output similar to this has shown up from time to time with various SBCs. In the cases I found of this happening the end behavior is similar to what happens on the i96, hostapd thinks the access point is enabled, but it is not seen by any other devices.
People have solved it by unblocking wlan with rfkill or properly setting country codes and in cases where that failed the solution was usually a newer / different kernel. This leads me to wonder about that first output block. If the tx queue parameter sets fail this could be due to a country code issue, since it seems that hostapd fails to set the country code.
Tracking down the root cause of the country code failing to get set is probably non-trivial. I suspect it’s due to some strange error in the cfg80211 driver for this chip.
Perhaps it is possible to set the country code in a different way? If I recall correctly, there are some country code problems with this board’s default image that are fixed by crda? I wonder if it would be possible to fix this using crda or something similar.
Fantastic results, that does look exactly like where I am at with it. Yes, setting the country code in /etc/default/crda is super important. It’s in the “First Startup” instructions because if you don’t set it there you will see a bunch of dmesg errors related to this. I’m not sure if I had it set for this test or not but I’m still working on it. I get the exact same TX queue errors. It could be regulatory related.
The original image was completely missing the crda package and it’s the reason everyone thinks the WiFi chip is broken. It’s definitely not the chip though. It’s their terrible, terrible driver but it can be fixed and just installing the crda package in this image and setting your country will eliminate most of these. It may still need something more for regulatory on hostapd. I’ll continue to test/check this based on your findings too. It’s probably a combination of the kernel being too old and the packages being too new (as is the source for a lot of the problems I’ve fixed recently but they’re usually not too bad) with some driver bugs likely mixed in as well.
I just released 1.22 which has some fixes to the wireless driver and I’m working on more. P2P mode is disabled in the driver so I’m seeing if it will let me enable that (has needed a bunch of fixes). Can you try setting your country code in /etc/default/crda and try running this test on 1.22? I’m definitely not expecting it to work yet but I want to see if there’s any change at all (this will help us know if we are on the right track or fixing some of them at least).
One of the big changes in 1.22 is that I basically recreated wireless fixes (which were packaged up as only a binary blob, not the source code). This was a very important step because we couldn’t really modify the driver as long as we were using that. I recreated his MAC address fixes that he made in the driver and now we can actually start fixing it / accepting PRs for it!
I don’t remember for sure if I set the country code on the 1.20 image when I was testing hostapd, however I flashed the 1.22 image and even after setting the country code it seems to have had no effect for some reason.
After I modified /etc/default/crda and rebooted, I get the following output from iw
orangepi@orangepii96:~$ cat /etc/default/crda
# Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may set
# the initial regulatory domain setting for IEEE 802.11 devices which operate
# on this system.
#
# Governments assert the right to regulate usage of radio spectrum within
# their respective territories so make sure you select a ISO/IEC 3166-1 alpha2
# country code suitable for your location or you may infringe on local
# legislature. See/usr/share/zoneinfo/zone.tab’ for a table of timezone
# descriptions containing ISO/IEC 3166-1 alpha2 country codes.
Great findings again! I can definitely confirm the iw reg command isn’t working for sure. I dug a little deeper and found this in the wireless driver (kernel/drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c): /* This is to override regulatory domains defined in cfg80211 module (reg.c)
* By default world regulatory domain defined in reg.c puts the flags
* NL80211_RRF_PASSIVE_SCAN and NL80211_RRF_NO_IBSS for 5GHz channels (for
* 36..48 and 149..165). With respect to these flags, wpa_supplicant doesn't
* start p2p operations on 5GHz channels. All the changes in world regulatory
* domain are to be done here.
*/
static const struct ieee80211_regdomain wland_regdom = {
.n_reg_rules = 4,
.alpha2 = "99",
.reg_rules = {
/*
* IEEE 802.11b/g, channels 1..11
*/
REG_RULE(2412 - 10, 2472 + 10, 40, 6, 20, 0),
/*
* If any
*/
/*
* IEEE 802.11 channel 14 - Only JP enables this and for 802.11b only
*/
REG_RULE(2484 - 10, 2484 + 10, 20, 6, 20, 0),
/*
* IEEE 802.11a, channel 36..64
*/
REG_RULE(5150 - 10, 5350 + 10, 40, 6, 20, 0),
/*
* IEEE 802.11a, channel 100..165
*/
REG_RULE(5470 - 10, 5850 + 10, 40, 6, 20, 0),}
};
This explains why we aren’t seeing any crda errors in dmesg or the kernel logs. The crda package is working just fine. The driver is just programmed to overwrite it with it’s own stuff.
Given that we don’t even have a 5G radio onboard the whole reason they broke regulatory for this (given by their comment) doesn’t even apply to the i96. The next time I am working on the image I am going to try commenting out these lines:
Maybe this will let it use the regular regulatory information. If you want to give it a try before me though definitely go ahead!
EDIT: I was able to try this and it does appear to have done something:
Aug 7 13:25:18 orangepii96 kernel: [ 5.724487] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.725341] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.729675] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.730468] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.731384] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.732360] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.733276] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.734252] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.735229] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.787475] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.788269] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.789794] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.790649] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.791564] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.792541] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.793518] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.794433] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.842285] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.843078] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.843994] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.844970] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.859680] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.860412] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.861389] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.862304] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.863281] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.864196] cfg80211: Updating information on frequency 2484 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.865234] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.889099] [RDAWLAN_ERR]:: World domain. Setting XY/4
Aug 7 13:25:18 orangepii96 kernel: [ 5.945678] [RDAWLAN_ERR]:: event handler failed (2)
Aug 7 13:25:18 orangepii96 kernel: [ 6.695434] enable vbus and disable charge
Aug 7 13:25:18 orangepii96 kernel: [ 6.696472] : end of pending msg
Aug 7 13:25:18 orangepii96 kernel: [ 6.696838] rda_modem_pm_notify status:0x0
Is it working yet? A lot more than it was for sure but there’s still more to do/fix. It’s at least setting some frequencies now and trying to do something. The country code still isn’t right yet so there’s still more work to be done and I doubt hostapd will be happy with it yet but this is a really good sign that this is fixable here (eventually, it’s hard to say how deep the rabbit hole goes as the wireless driver is quite large spanning many different files and has added a dozen files to the project just getting this far).
I’m releasing these changes as 1.24 if you’d like to try them! The dmesg output from this version on the i96 is actually cleaner than the Ubuntu 22.04 x86_64 desktop I am typing this on (not perfect yet though)!
Apparently it was common for older wifi drivers to hard code a regulatory domain (not sure why), so I’m not surprised to see this.
I got a chance to quickly test some things on the new image (1.24). I haven’t messed with hostapd yet (and I doubt it will work based on the following), but this is certainly good progress!
In my testing I get results very similar to what you have in dmesg, however I am not seeing the RDAWLAN_ERR lines (perhaps because I set a REGDOMAIN using crda?).
I did also notice a couple of things in the driver
– It looks like the cfg80211_reg_notifier function actually does nothing with the regulatory domain info currently. There’s a disabled block (#if 0) around line 5314 of wland_cfg80211.c that seemingly disables the code that actually sets the regulatory domain. Perhaps it is worth enabling this to see what happens.
– There are various traces prints that could be very helpful for following where in the driver things are happening. It may be beneficial to enable these by changing the log level in wland_dbg.c by changing the wland_dbg_level variable and defining DEBUG.
I don’t have a system setup to build an image on yet, but I’ll probably try the above two things when I do (unless you get to it first).
Perfect observations! You’re absolutely right here about everything. I’ve been working on the wireless driver this morning and have been working on getting traces enabled. Your tip will actually save me a ton of time as that is one of the things I was looking for (enabling tracing and debug output messages).
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c: In function ‘cfg80211_reg_notifier’:
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:2: error: implicit declaration of function ‘wldev_iovar_setbuf’ [-Werror=implicit-function-declaration]
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:27: error: ‘wdev’ undeclared (first use in this function)
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:27: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:78: error: ‘struct wland_cfg80211_info’ has no member named ‘ioctl_buf’
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:91: error: ‘WLC_IOCTL_SMLEN’ undeclared (first use in this function)
There’s no ioctl_buf, but there’s a couple other buffers that don’t sound quite right. I’m still playing with it but I’m exactly where you’re at. I also need to do some tests with the new tracing trick you showed me!
I didn’t look very closely at that code. It’s located in the section for kernels older than 3.10…
It looks like this driver was a copy of an older kernel driver (I think it may have originally been a driver for Android’s network stack) that someone “updated” to barely work on Linux 3.10 with some features (such as setting country) missing.
To get things working properly, it’s likely necessary to figure out what those functions used to do.
It appears that these likely came from wldev_common.h / wldev_common.c, two random files that seem to be in most android 3.x kernels for wlan drivers. For instance this one and this one. I’d imagine (if this was an old android driver) these files were originally part of this driver too.
I haven’t really looked through them, so not sure what they are / do, but wldev_iovar_setbuf is defined in these files so maybe we can figure out what they actually do. Just from the header comment it seems to be setting an “iovar” (not sure what this is / means). Perhaps looking at modern wireless drivers in the mainline kernel could shed some light on how iovars are handled in modern (and not android) kernels?
I’ve done some more poking around and the thing that is really confusing me is that the iw and iwconfig commands are just… not working it seems like. No matter how I try to set the txpower it always just says it’s 1:
This could probably be adapted for the other function as I’m starting to understand how it’s working better but I honestly don’t want to go further until I understand why it isn’t showing my even fixed 20dBm regulatory setting in here. Great work on this, you’ve helped me get a lot further already!
I am also seeing this error with the new tracing but I don’t know what it means:
[RDAWLAN_SDIO]: isr w/o interrupt is disabled, so do nothing and return
[ 5.614257] [RDAWLAN_ERR]:: event handler failed (2)
The second one I have seen before but the one before it was only revealed by the tracing. I’m releasing this as V1.25!
Michael
2 years ago
Hi James,
SPI is working now thanks to you and MZA.
For my e-paper display from waveshare i needed the Opi.GPIO library, but the pin definitions were missing.
I added them here.
I also made a pull request to the original project. Here is the modified waveshare project which is working for me
Wow, you are our first confirmation! Thanks for checking this out and your great work getting it working! I’m definitely familiar with Waveshare and have a bunch of Waveshare products and am pretty happy with them.
I think I can probably add your GPIO library to the image as I’d imagine that the e-paper displays are going to be a better choice with the i96 than TFTs simply because they update and take a second or two to redraw but that’s totally normal for a e-ink/e-paper display so it shouldn’t be as much of a problem that it’s software driven as it is for a TFT which is ideally pushing out a decent number of frames per second at the screen’s full resolution for it to not look really choppy.
I could definitely add this in since it looks like this would be a good library to get other types of devices working as well!
For anyone who hasn’t bought a usb hub for their i96: eBay Link
Hey Roberto,
Fascinating! This hub actually works with the i96? Maybe it’s actually a compatibility issue with USB 3.0 hubs as I see this is a USB 2.0 hub. That’s kind of a big deal as there are lots of situations where one USB port is not going to be enough. This could actually let people use this for projects that I didn’t think they would be able to based on earlier USB 3.0 hub experimentation.
Great findings! I have a hub somewhere that is USB 2.0 that is meant for Raspberry Pi Zeros. I guess I really need to find that and see if it works. Thanks for sharing!
Hello. I don’t know yet. The usb hub will arrive to me early next week
it propably wont work, you can go thru the comments and see that some already tried to use a hub, it failed.
Seconded for sure. I’ve tried to get hubs working with it a few times and I can’t figure out if it’s something I can fix in the driver or if this is a hardware limitation or what is happening exactly.
Hubs are blacklisted intentionally by the kernel but I’ve gone as far as disabling that and several other steps and I never end up with even a functional USB afterward (for anything, not just hubs, it just won’t detect or work with anything).
I’m sure a USB expert could either tell us how to fix it or why we can’t fix it and I keep hoping someone who has ultra-low-level USB skills takes a look at this sometime here. I’ll probably try again as well as I don’t tend to ever “give up” on anything but will revisit it later which I do plan on still trying to either figure this out or completely understand why it’s impossible for whatever reason!
Hello 🙂 Thank you for making this updated Debian image…
Have you tried including the 5.6.2 kernel? The people in this thread say it is working.
Hey Roberto,
I have definitely seen that thread before. If you read the posts toward the end everyone says the SD card mapping doesn’t work on it. That’s definitely a dealbreaker for sure so I don’t think this would work without a lot more work.
If anyone wants to try implementing this and could get it to map the SD card storage successfully I’d definitely willing to update the kernel in this!
Thank you for your reply… I will stick with the 3.10 kernel to continue my project….
I found why ping needs sudo…solution
Hey Roberto,
Excellent, great stuff! Thanks for sending me a tip as well. That’s very much appreciated!
Hey – just a note. The company that makes the orange pi i96 has discontinued the product and has sold all remaining quantities to other resellers at a huge discount. So no more $5.99 boards at aliexpress. 🙁 Any of the ones you see floating around on the marketplace are the last few out there where vendors are trying to make a decent return on their investment.
Hey Isaac,
Haven’t these been discontinued for a while now?
I don’t think this has changed since I started this image. We knew it was abandoned 100%. I think what is changing is that they are selling now (for probably the first time ever since launch other than one person here or there). I personally bought a few and talked to others who have done the same. Those suppliers have probably had those boards for years.
There was no reason to buy this board until very recently as you couldn’t even use most of it. They haven’t updated their GitHub for this board since 2020 even. That is when they officially abandoned this board no matter what they say publicly. Once the dev work stopped the decision had been made internally and those people working on it were put on other boards.
I definitely think you’re right that the last ones out there are the last ones that are left. I don’t think they’ve manufactured one of these boards for YEARS. I’m sure of it. These are all stock sitting because the board was so unsuccessful and once it’s gone it’s probably gone! It’s their fault (Orange Pi’s) that this board was unsuccessful. We’ve literally proven at this point that the hardware was fine this entire time and that their image was just garbage.
The truth is when they were selling it for $7 they were actually trying to scam you. They knew that there was no image that had been updated in years and that most of the features in the base image were broken. They knew you weren’t going to be happy with it but they made the calculation that for $7 you’d probably forgive them or decide it’s not worth returning. They were just trying to get rid of them at whatever price. I’m guessing that most of the stock is starting to sell out and the smart sellers that track their inventory well have probably marked it up!
If they really have made some kind of announcement then I guarantee you it’s simply because we have finally depleted their Orange Pi i96 stock because they have not made them for a long time. This is a really good time to pick them up while you can still! It was always too good to be true to get a functional board for $7 and they never intended to offer it to us for this price. They were just trying to liquidate what they thought was a worthless board (because they themselves made the decision to stop updating it).
It may have also been embarrassing that someone else was fixing their image (starting out with the fixes submitted to their own GitHub they have ignored for years). It’s a bad look for them but I kind of wish they would keep making it and offering it for that price but the truth is we didn’t really expect that. We’ve been expecting a price increase at best and it looks like you may be right that once these are gone they are gone.
If Orange Pi was extremely intelligent they would chase this market. Raspberry Pi has left the low-end market wide open for the taking. People are hungry for it. Nobody wants to pay $80+ for a Raspberry Pi Zero 2 and this board for $7 is a much better value than the Raspberry Pi Zero 2 for $80+ without question in my mind!
This board could have worked. We’ve already fixed it to be “good enough” for most people at least for the price. If only they had stuck with it and supported their image! If I was in charge of their supply chain I could absolutely have made this product work and would continue selling it today for $7 (and boy would it sell in this climate/market with some marketing / resources behind it as well as a working image).
It’s honestly too bad that it looks like what is going to happen here is that these are going to become unavailable within the next couple of months. If this image wasn’t released it might have taken another year or two for them to liquidate these. This could have been the biggest project I ever did if they still were producing these but it sounds like they are going to run out and then the party will be over. There is literally a worldwide need for this product at this price point that is not going to be met by any other market players in the near future.
In other words myself and everyone who contributed to this image (or even saw this article and knew about it) beat the system. We got our boards for $7 (several of them) and fixed the image so it was fully functional (or it’s getting close). This was never supposed to be though and it looks like it’s already having consequences for the availability / pricing which will continue to get worse. It’s one thing when dozens of people beat the system. It’s another thing entirely when hundreds or thousands of people start beating the system because then the system will change.
Oh wow – I didn’t know these were discontinued. I messaged the company because I wanted more of them, and they had sold out but had in the neighborhood of like 500 left when I last chatted with them. I bought these just by chance because I was looking for alternative hardware for projects… I picked up 4 of these (because they were so cheap), a couple of mango pis, a couple of banana pis. I was thinking to myself, hey, if my projects will work on these, I can get more. There, unfortunately, is not a reliable supply of raspberry pis… I just bought a 100 rpi w0 1.3 boards for 3k last week (good price today, horrible price 3 years ago) and I honestly don’t know when or where I’ll be able to get more when I run out.
Hey Isaac,
No worries at all, that’s amazing that you got 100 RPI boards for that price! It’s a very tough market right now for sure. That’s interesting that they had something like 500 of the i96 left. I was hoping it was more like 5,000-10,000 but it doesn’t sound like they had a ton left to begin with.
Thanks for sharing this, I love hearing from people who are working inside the industry about what kind of prices/availability they’re seeing! I don’t know that I would recommend buying 100 i96 devices but I definitely would recommend to basically anyone who works with SBCs to buy a few of them to have as just light duty boards / use for projects where there’s a chance of them getting damaged / stolen or even throwaway applications. If you had a use case where you knew the board was going to be lost/destroyed in the process I would *never* put a Raspberry Pi Zero 2 or even Zero in something like that (at least now, I would have a couple of years ago) and today would use a sacrificial i96 (and sleep like a baby afterward).
I personally have 3 now. They’re really good for my use cases that don’t need a lot of power but still benefit from being very small like a Raspberry Pi Zero (and requiring hardly any electricity to run either relative to almost anything else). It’s basically a (very soon to be formally) $10-$15ish tool that I think people who work with SBCs a lot will find quite handy/convenient and will find themselves using it for things that wouldn’t have made sense to dedicate a Raspberry Pi to and might not even have done otherwise. I won’t lie, your news has convinced me I probably should grab another 2-3 before it’s too late based on the numbers you’ve given me. Time is short.
This is how I used Raspberry Pis for years (as I’m sure many of you have/do) which is why I found these i96 boards so refreshing. I finally had access to super cheap boards again and since a lot of my Raspberry Pis have made their way into permanent builds like my Pwnagotchi it was definitely at just the right time. I don’t have as many Raspberry Pi Zeros laying around anymore that aren’t already in builds that I am using / don’t want to take apart. I’ll definitely replenish my Raspberry Pi Zero supplies as well when this shortage ends but it looks like this may still go on for quite some time.
This lets you save your expensive/low-availability boards for the stuff you’re doing that needs that power/flexibility. A lot of the time you just need a really cheap computer to shove into a box or stick on the shelf to run some light service / application. The Raspberry Pi Zero used to be that but as everyone knows that has not been the case for some time now mainly due to availability (and scalpers). Given that we have a reasonably updated Bullseye image these boards should be very useful for this purpose for years. They definitely all have their place!
The boards are no more sold at 5.99$ but you can still find them reasonably cheap at around 13$, and according to AliExpress’ site they have 3000 in stock (can’t say if that number is real, but I guess it is):
As James said, I see a lot of potential for working SBCs like the I96 even at current (higher) pricepoint.
Hey Andy,
Excellent, that’s still a decent amount of them left for anybody who would like to grab some. Thanks for sharing!
Nice commits you have done lately, but still having massive wireless issues, sudden disconnects and especially if i enable bluetooth scan.
for example connect via wifi to your network and start downloading a bit file via wget, open a second ssh shell and start scanning via bluetoothctl (scan on).
cfg80211_disconnected[ 562.800537] cfg80211: All devices are disconnected, going to restore regulatory settings
[ 562.801391] cfg80211: Restoring regulatory settings
[ 562.802001] cfg80211: Kicking the queue
[ 562.802490] cfg80211: Calling CRDA for country: DE
[ 563.056457] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 563.062500] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.063415] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 563.064575] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.065368] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 563.069335] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.070251] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 563.071350] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.074157] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 563.075012] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.076293] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 563.077758] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.078491] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 563.079772] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.082519] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 563.083312] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.084228] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 563.085388] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.086120] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 563.087707] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.091491] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 563.092346] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.093261] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 563.094238] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.095153] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 563.096130] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.100036] cfg80211: Disabling freq 2484 MHz
[ 563.100463] [RDAWLAN_ERR]:: reg_notifier for intiator:3 not supported
[ 563.101562] cfg80211: Regulatory domain changed to country: DE
[ 563.102233] cfg80211: DFS Master region ETSI
[ 563.102783] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.103820] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.105163] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2301 mBm)
[ 563.105895] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.110168] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm)
[ 563.110900] cfg80211: (5725000 KHz - 5875000 KHz @ 80000 KHz), (N/A, 1397 mBm)
[ 563.111816] cfg80211: (5945000 KHz - 6425000 KHz @ 160000 KHz), (N/A, 2301 mBm)
[ 563.112792] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[ 563.114624] cfg80211: Calling CRDA to update world regulatory domain
[ 563.157592] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
[ 563.158752] [RDAWLAN_ERR]:: reg_notifier for intiator:0 not supported
[ 563.160339] cfg80211: World regulatory domain updated:
[ 563.160888] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.161926] cfg80211: (755000 KHz - 928000 KHz @ 2000 KHz), (N/A, 2000 mBm)
[ 563.162719] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.163635] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 563.165039] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[ 563.165771] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.166687] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.171325] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm)
[ 563.172180] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.173034] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm)
[ 563.174194] cfg80211: Calling CRDA for country: DE
[ 563.214843] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 563.215637] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.216552] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 563.219604] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.220397] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 563.221374] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.222290] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 563.223754] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.224487] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 563.225463] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.226379] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 563.230346] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.231079] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 563.232055] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.233032] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 563.234497] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.235229] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 563.236206] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.239440] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 563.240356] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.242187] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 563.242980] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.243896] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 563.244873] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.248779] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 563.249572] cfg80211: 2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 563.250488] cfg80211: Disabling freq 2484 MHz
[ 563.251037] cfg80211: Regulatory domain changed to country: DE
[ 563.252197] cfg80211: DFS Master region ETSI
[ 563.252502] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 563.253540] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 563.254455] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2301 mBm)
[ 563.255371] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 563.256774] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm)
[ 563.261901] cfg80211: (5725000 KHz - 5875000 KHz @ 80000 KHz), (N/A, 1397 mBm)
[ 563.262756] cfg80211: (5945000 KHz - 6425000 KHz @ 160000 KHz), (N/A, 2301 mBm)
[ 563.263671] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[ 565.070068] [RDAWLAN_DCMD]: Connecting to 2c:3a:fd:ff:76:aa
[ 565.101623] [RDAWLAN_CFG80211]: connected. wland_bss_connect_done
[ 565.102539] [RDAWLAN_CFG80211]: Report connect result - connection succeeded
the ssh session will drop, the speed for the download will fall to almost zero and cfg80211 disconnect happens.
now i also realised that before disconnecting cfg80211 the regulation is not set (to country 00 by default).
but what bothers me the most is the sudden disconnects from cfg80211
Hey Marco,
Is this different from older versions? My guess is that you can just see it now because tracing is enabled. The driver never respected or uses the regulatory settings. It’s overridden here:
Ignoring regulatory request Set by core since the driver uses its own custom regulatory domainThis is because of this code in the wireless driver:
/* This is to override regulatory domains defined in cfg80211 module (reg.c)* By default world regulatory domain defined in reg.c puts the flags
* NL80211_RRF_PASSIVE_SCAN and NL80211_RRF_NO_IBSS for 5GHz channels (for
* 36..48 and 149..165). With respect to these flags, wpa_supplicant doesn't
* start p2p operations on 5GHz channels. All the changes in world regulatory
* domain are to be done here.
*/
static const struct ieee80211_regdomain wland_regdom = {
.n_reg_rules = 4,
.alpha2 = "00",
.reg_rules = {
/*
* IEEE 802.11b/g, channels 1..11
*/
REG_RULE(2412 - 10, 2472 + 10, 40, 10, 30, 0),
/*
* IEEE 802.11 channel 14 - Only JP enables this and for 802.11b only
*/
REG_RULE(2484 - 10, 2484 + 10, 20, 6, 20, 0),
/*
* IEEE 802.11a, channel 36..64
*/
REG_RULE(5150 - 10, 5350 + 10, 40, 6, 20, 0),
/*
* IEEE 802.11a, channel 100..165
*/
REG_RULE(5470 - 10, 5850 + 10, 40, 6, 20, 0),
}
};
It only tried to apply the regulatory settings because you were disconnected:
All devices are disconnected, going to restore regulatory settingsIn other words I doubt this has anything to do with regulatory. I just have all of the regulatory output enabled right now in the kernel with this flag: CONFIG_CFG80211_REG_DEBUG=y. What I would suggest doing is turning tracing on in the driver so you can see all of the output:
sudo sucd /sys/kernel/debug/rdawfmac/mmc1*
echo 5 > dbglevel
This will show all the wireless issues really going on (you’re seeing probably 1% of the messages available right now). The Orange Pi will become very slow in this mode because there’s so much. You will feel it immediately and if you do a dmesg it will be absolutely spammed with output. We really do need a capture like this to know what’s going on because (as you will see) you are honestly seeing nothing in that output. Hopefully it will give some more information about why you were disconnected here!
You can adjust the levels lower to reduce the amount of output (and you’ll probably have to). I had to do a combination of this as well as modifying the WiFi warning levels within the driver (and add a bunch of new messages where there was no output previously) in order to make the output more useful and less spammy.
The default # in the latest versions is 3 (WLAND_INFO_LEVEL). It used to be 0 (errors only) which is why you basically couldn’t see anything before (it was all still happening though). I have enabled this setting inside debugfs which means you can change it on the fly without rebuilding the kernel now. I did this both so people can start getting captures and start taking matters into their own hands with pull requests for issues here in there in the driver (as it is impossible to debug without this output and I wanted a way for people to see it without rebuilding the kernel).
I’d say maybe try stepping it up to 4 first because 5 is absolute spam (but tells you everything). Even turning it up there are no guarantees it will give you the output we need. There’s so much output though that you will be able to know where it was in the code and what it was doing when things went wrong though and that was enough for me to start on the few I’ve tried to tackle so far of the many, many issues in the driver. I had to add a dozen brand new debug messages that did not exist before into the wireless driver to even try to begin to figure out what it was doing just to try and diagnose the txpower. I’m still not sure what is going on with all the iovar variables that are disappearing and not stored/retrieved correctly.
I don’t think it’s an exaggeration to say there are dozens of issues with this wireless driver. I definitely don’t expect it to be fixed any time soon. It doesn’t even store that country code correctly in the driver settings which is why it always says 00. I recently learned the hard way that even if I disabled their code that overrides the regulatory settings that is just the tip of the iceberg. It doesn’t store the country code correctly and always shows it receives ’00’. In fact originally the country was set to “99” which actually doesn’t show anywhere (it always shows 00, the driver doesn’t seem to retrieve these types of settings correctly).
I’m enabling this type of tracing for other systems everywhere I encounter them as I’d imagine there are many other things that are broken like this that we just can’t see. There’s virtually no downside to the ones that can be controlled by the user in /sys/kernel/debug because if they aren’t being used then nothing will happen (and the extra size of the kernel from including the debugfs features is negligible compared to the “main” features themselves which is how you really save space). It’s only as I’ve been learning and trying to diagnose some of these issues that I’ve realized how valuable the tracing stuff is (especially the ones that can be adjusted on the fly through /sys/kernel/debug). The problem might actually be in the Bluetooth part of the driver which this tracing level will probably actually let you see without having to change too much else.
The only way this will ever get fixed is with other people’s help for sure and people taking a look at it and fixing the problems here and there. For example the sensitivity reads as: “Sensitivity=30/0”. My desktop doesn’t even show that measurement but it does not look correct at all. In fact the driver doesn’t seem to store any settings correctly at all. It’s very overwhelming to work with at first but I was just going in circles/guessing until MB3hel pointed me toward the tracing settings in the source code. I then took it further by enabling debugfs support for rdawfmac so this could be adjusted by anyone at any time. Once I could actually see what was happening (and started filtering through the noise and adding my own messages) I was finally able to make some progress. Let’s see what your output looks like with the tracing level turned up here!
EDIT: It may have been my txpower settings. I set it back to 20 like the board has as the default (it may be the limit, still investigating that) and my board stayed connected stable for several hours again. I also set the regulatory domain back to ’99’ which it turns out has a special meaning in cfg80211 (it means the driver sets an override). I think this may be what is preventing the disconnects. Can you try with 1.29?
Hi all,
Good news, I’ve got CAN bus working with mcp2515.
I’ve done too much things ( not all clever) to have it but now, I’ll go back to the latest Legendary kernel and do it properly again before submitting it.
I96 def_config file update and devices.c have been uploaded to OrangePi-I96-Work to make CAN bus transciever MCP2515 work instead of spidev2.1 ( SPI2 CS_1) and with interrupt pin on D02 ( H26).
After kernel compilation with CAN BUS flags and device MCP251x, install can-utils package on orangepi
sudo apt-get install can-utilsbring CAN interface up with the desired bitrate
sudo ip link set can0 type can bitrate 1000000sudo ip link set can0 up
send a frame :
cansend can0 123#DEADBEEFsee incoming frames :
candump can0use loop mode :
sudo ip link set can0 downsudo ip link set can0 type can bitrate 1000000 loopback on
sudo ip link set can0 up
Hey MZA,
Fantastic work, everything looks good to me! I’m surprised you were able to add this in without breaking the other functionality if I’m looking at this correctly. Someone did manage to get spidev working with a Waveshare e-paper display. Will this change break it? I guess it depends on whether they are using spidev2.0 or 2.1 (or do they always have to use 2.1?). That was my main concern with this change is that everyone would have to build their own kernel (which is why things like device trees that give you other options than this are so awesome).
Is it possible to have them all enabled at once (using either bus_num or chip_select or any of those variables) or are we going to run out of pins? Since the GPIO SPI is all software controlled couldn’t we theoretically have a whole bunch of these? Even if not this is still huge progress. I really like that you left it configurable with kernel flags.
Theoretically I could modify the build system to produce multiple images with different options available. I’m hoping that this won’t break the other person’s though that they got working. It’s probably not unreasonable to expect someone to build this project that wants to work with a device like this and be able to change the driver theoretically but then the question becomes what should be the default behavior.
I’m packaging and releasing this as 1.26 if you’d like to give it a try and make sure I got everything in there properly! I’d definitely say it’s worth resyncing with me on this version as it’s much cleaner than the older builds (both in how the code is organized as well as dmesg / syslog output) and is starting to look really good. The only bug I even know of right now is the WiFi driver shows the txpower as 1 (which I think is a display glitch because if it was really 1 I wouldn’t be able to connect and use it)!
Hi James,
I think that the essay with the epd uses user-land driver, I’ve tried such a driver ( it’s more an application) and no other driver has been added to the devices.c. I’ve pulled out your latest version. So it opens the /dev/spidev2.0 which uses the CS on header pin N°16. He may be using the spidev2.1 but he would have to use the other.
You can use the devices.c without activating the MCP251x flag, it will produce the two spidev(s). Any one that needs the CAN, will have to enable the flag and compile the kernel.
By the way, prices of the OrangePI have doubled, they’re now at +13 EUR excluding shipping, I missed ordering some.
Now for the CAN bus, I’m seeing RX errors with some traffic, I guess the spi-gpio is not able to deal with it, I will try to debug ASAP. Small traffic is OK.
Hey MZA,
Outstanding! I’ve implemented the changes as you’ve suggested here in 1.27. Thanks for your work on this and I’m so glad you were able to get it functioning after all your work on it!
I noticed the Orange Pi prices have risen a little bit as well. It’s now $18 on amazon.us but that’s not too large of an increase since they didn’t used to have prime / free shipping. They only have one left in stock though which they used to have literally as many as you wanted to order for as long as I can remember.
It’s getting pretty close to the 1 month anniversary for the image and it’s almost unrecognizable from the original image at this point. It definitely adds a full half-dozen features that were completely inaccessible/broken and a couple of those (the most technically impressive ones at least to me as my strengths do not lie with the pin assignments and hardware level your changes are interacting with but I’m slowly learning) are thanks to your work. I look forward to anything else you find with it when debugging!
Hey James,
I’ve linked the RX frame loss to bursts while having 1Mbps bitrate on the bus.
This is an already discussed topic on the net, there are some patches to avoid race conditions in the mcp251X driver that I borrowed but it did not fix the problem. It is mainly due to slow spi transfer. I tried using higher priory irq handler but I did not do the job.
I think going back another time to rda-spi driver will be the solution but I’ll try it in the future, I need to check the I2C now.
Hey MZA,
Fascinating findings! That sounds good to check out the i2c as I haven’t heard much from people working with that yet. This actually makes a lot of sense.
I finally got a USB to UART adapter ordered. I’ve enjoyed doing the fixes on this enough that I want to dive more into the lower level hardware and this tool will help a lot. There are things happening with these protocols I don’t understand and I don’t like it. Especially with diagnosing the WiFi from my desk without having to use the USB to Ethernet adapter will help me do some more low-level debugging (at least at a more efficient pace).
My old setup had my i96 in the basement on the USB to Ethernet adapter so every time I built an image I had to go to a different story of the house. Recently I upgraded the build tool to be able to preconfigure an image if you create a “presets” folder in the external folder. This lets me build images during development that already have my WiFi configured as well as other things to save time. This worked well but the problem is when I was working on the WiFi I would often break it and then I couldn’t see what was happening. In that case I had to remove the SD card from the i96 to access the logs and even see them (slow). Once I receive this I will be able to use the serial console right from my desk without any network connection at all.
There are other tools called the bus pirate and Shikra that also will interact with SPI/I2C and other protocols. I don’t know enough about those ones yet to know what the best adapter / tool would be to do testing with but I saw some interesting ones.
I look forward to your i2c results!
Hey James,
You’ll probably need to add lrzsz package to be able to transfer files with zmodem over the serial link. I use it exclusively, I could do nothing with ssh and scp over Wi-Fi. The latest improvements of the wi-fi made it some how possible but not as quick and reliable as through the serial link.
/dev/i2c-2 is OK.
Hey MZA,
That’s actually some really good news for a change that something is working correctly without a lot of additional fixes/assistance! I should be able to add the lszrx package in for sure here in the next version.
🙂 lrzsz
Has anyone attempted to get a WiFi hotspot working on this device? I’ve been attempting to get this working with hostapd (bullseye image version 1.20), but have been unable to get it to work.
On line 476 wland_cfg80211.c (OrangePiRDA_Kernel repo) it seems that no driver for AP mode is implemented.
However, the
iwtool lists AP as a supported mode.Supported interface modes:
* managed
* AP
Is there perhaps a different interface to work with AP mode than NL80211 that works with this device or a different kernel driver I should try that may have support for AP mode implemented? My familiarity with the low-level Linux network stack is minimal, so I’m not really sure where to go from here.
Hey MB3hel,
I think this is actually a problem with the hostapd package from apt. I rebuilt the package on the orangepi like this:
git clone git://w1.fi/srv/git/hostap.git --depth=1sudo apt install libnl-3-dev libnl-genl-3-dev -y
cd hostap/hostapd
make
sudo cp hostapd /usr/sbin/hostapd
sudo cp hostapd_cli /usr/sbin/hostapd_cli
This lets it work with the driver but I’m seeing errors. You can run it like this to get the debug output:
sudo hostapd -d /etc/hostapd/hostapd.confThis will work but this is the output I get:
orangepi@orangepii96:~/hostap/hostapd$ sudo hostapd -d /etc/hostapd/hostapd.confrandom: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=0
nl80211: Could not add multicast membership for vendor events: -2 (Interrupted system call)
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:6
nl80211: Using driver-based off-channel TX
nl80211: key_mgmt=0xd0f enc=0x10f auth=0x7 flags=0xd0c0 rrm_flags=0x0 probe_resp_offloads=0x0 max_stations=0 max_remain_on_chan=5000 max_scan_ssids=10
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 3 (AP)
nl80211: Setup AP(wlan0) - device_ap_sme=1 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0xb7d27100 (device SME)
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=04 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 04
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0501 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0503 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0504 multicast=0
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=06 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 06
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=08 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 08
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=09 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=0a multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 0a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=11 multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 11
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb7d27100 match=7f multicast=0
nl80211: Register frame command failed (type=208): ret=-114 (Operation already in progress)
nl80211: Register frame match - hexdump(len=1): 7f
nl80211: Failed to subscribe for mgmt frames from SME driver - trying to run without it
nl80211: Enable Probe Request reporting nl_preq=0xb7d26e98
nl80211: Register frame type=0x40 (WLAN_FC_STYPE_PROBE_REQ) nl_handle=0xb7d26e98 match= multicast=0
rfkill: initial event: idx=2 type=1 op=0 soft=0 hard=0
nl80211: Could not re-add multicast membership for vendor events: -2 (Interrupted system call)
nl80211: Add own interface ifindex 3 (ifidx_reason -1)
nl80211: if_indices[16]: 3(-1)
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code US
Continue interface setup after channel list update
ctrl_iface not configured!
random: Got 20/20 bytes from /dev/random
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 40 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
Completing interface initialization
Mode: IEEE 802.11g Channel: 6 Frequency: 2437 MHz
DFS 0 channels required radar detection
nl80211: Set freq 2437 (ht_enabled=0, vht_enabled=0, he_enabled=0, eht_enabled=0, bandwidth=20 MHz, cf1=2437 MHz, cf2=0 MHz)
* freq=2437
* eht_enabled=0
* he_enabled=0
* vht_enabled=0
* ht_enabled=0
* radar_background=0
* channel_type=0
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
hostapd_setup_bss(hapd=0xb7d27fa0 (wlan0), first=1)
nl80211: flush -> DEL_STATION wlan0 (all)
Using interface wlan0 with hwaddr fe:ae:e0:39:f9:41 and ssid "orangepi"
Deriving WPA PSK based on passphrase
SSID - hexdump_ascii(len=8):
6f 72 61 6e 67 65 70 69 orangepi
PSK (ASCII passphrase) - hexdump_ascii(len=8): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
GMK - hexdump(len=32): [REMOVED]
Key Counter - hexdump(len=32): [REMOVED]
WPA: Delay group state machine start until Beacon frames have been configured
nl80211: Set beacon (beacon_set=0)
nl80211: Beacon head - hexdump(len=59): 80 00 00 00 ff ff ff ff ff ff fe ae e0 39 f9 41 fe ae e0 39 f9 41 00 00 00 00 00 00 00 00 00 00 64 00 11 04 00 08 6f 72 61 6e 67 65 70 69 01 08 82 84 8b 96 0c 12 18 24 03 01 06
nl80211: Beacon tail - hexdump(len=31): 2a 01 04 32 04 30 48 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
nl80211: ifindex=3
nl80211: beacon_int=100
nl80211: beacon_rate=0
nl80211: rate_type=0
nl80211: dtim_period=2
nl80211: ssid=orangepi
* beacon_int=100
* dtim_period=2
nl80211: hidden SSID not in use
nl80211: privacy=2
nl80211: auth_algs=0x1
nl80211: wpa_version=0x2
nl80211: key_mgmt_suites=0x2
nl80211: pairwise_ciphers=0x10
nl80211: group_cipher=0x10
wlan0: Deauthenticate all stations at BSS start
nl80211: sta_remove -> DEL_STATION wlan0 ff:ff:ff:ff:ff:ff --> 0 (Success)
WPA: Start group state machine to set initial keys
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GTK - hexdump(len=16): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=3 addr=0xb6eed1b4 key_idx=1 set_tx=1 seq_len=0 key_len=16 key_flag=0x1a
nl80211: NEW_KEY
nl80211: KEY_DATA - hexdump(len=16): [REMOVED]
broadcast key
nl80211: NL80211_CMD_SET_KEY - default key
nl80211: Set wlan0 operstate 0->1 (UP)
netlink: Operstate: ifindex=3 linkmode=-1 (no change), operstate=6 (IF_OPER_UP)
nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95
Failed to set TX queue parameters for queue 0.
nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95
Failed to set TX queue parameters for queue 1.
nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 2.
nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 3.
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED
wlan0: Setup of interface done.
Maybe I have it configured incorrectly. There’s some errors throughout such as “Operation already in progress” and “Failed to set TX queue parameters for queue X.”. My /etc/hostapd/hostapd.conf looks like this:
orangepi@orangepii96:~/hostap/hostapd$ cat /etc/hostapd/hostapd.confinterface=wlan0
ctrl_interface=/run/hostapd
ctrl_interface_group=0
#driver=mac80211
ssid=orangepi
country_code=US
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=test1234
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_group_rekey=86400
I think the problem might be here in my debug output (Unknown event 47 after scan started):
wlan0: nl80211: Scan triggerwlan0: Event SCAN_STARTED (47) received
Unknown event 47
nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlan0
wlan0: nl80211: New scan results available
nl80211: Scan probed for SSID ''
I figured I’d show you how far I got before I got stuck. It may be additional configuration or maybe the driver needs fixes somehow for it to work but hopefully this lets you get a little further in your testing!
Hi, thanks for the info. Building as shown I’ve been able to get very similar output. However, I believe other lines in the output may be indicators of actual issues. The lines you indicated above seem to indicate something to do with SSID scanning (station mode). I don’t get these lines when I disable connection to stations when attempting to run hostapd (I just set a static ip for wlan0 in
/etc/network/interfaces).There are some other lines that are interesting though. In particular these lines (close to the top of the output)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code US
Continue interface setup after channel list update
ctrl_iface not configured!
random: Got 20/20 bytes from /dev/random
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 40 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
Completing interface initialization
This output would seem to indicate that setting the country code failed. The channel list update times out and the regulatory information still shows a null country code.
The next interesting section is near the end of the log output
nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95
Failed to set TX queue parameters for queue 0.
nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95
Failed to set TX queue parameters for queue 1.
nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 2.
nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95
Failed to set TX queue parameters for queue 3.
I’m not really sure what this means, but from a little googling it seems that output similar to this has shown up from time to time with various SBCs. In the cases I found of this happening the end behavior is similar to what happens on the i96, hostapd thinks the access point is enabled, but it is not seen by any other devices.
People have solved it by unblocking wlan with rfkill or properly setting country codes and in cases where that failed the solution was usually a newer / different kernel. This leads me to wonder about that first output block. If the tx queue parameter sets fail this could be due to a country code issue, since it seems that hostapd fails to set the country code.
Tracking down the root cause of the country code failing to get set is probably non-trivial. I suspect it’s due to some strange error in the cfg80211 driver for this chip.
Perhaps it is possible to set the country code in a different way? If I recall correctly, there are some country code problems with this board’s default image that are fixed by crda? I wonder if it would be possible to fix this using crda or something similar.
Hey MB3hel,
Fantastic results, that does look exactly like where I am at with it. Yes, setting the country code in /etc/default/crda is super important. It’s in the “First Startup” instructions because if you don’t set it there you will see a bunch of dmesg errors related to this. I’m not sure if I had it set for this test or not but I’m still working on it. I get the exact same TX queue errors. It could be regulatory related.
The original image was completely missing the crda package and it’s the reason everyone thinks the WiFi chip is broken. It’s definitely not the chip though. It’s their terrible, terrible driver but it can be fixed and just installing the crda package in this image and setting your country will eliminate most of these. It may still need something more for regulatory on hostapd. I’ll continue to test/check this based on your findings too. It’s probably a combination of the kernel being too old and the packages being too new (as is the source for a lot of the problems I’ve fixed recently but they’re usually not too bad) with some driver bugs likely mixed in as well.
I just released 1.22 which has some fixes to the wireless driver and I’m working on more. P2P mode is disabled in the driver so I’m seeing if it will let me enable that (has needed a bunch of fixes). Can you try setting your country code in /etc/default/crda and try running this test on 1.22? I’m definitely not expecting it to work yet but I want to see if there’s any change at all (this will help us know if we are on the right track or fixing some of them at least).
One of the big changes in 1.22 is that I basically recreated wireless fixes (which were packaged up as only a binary blob, not the source code). This was a very important step because we couldn’t really modify the driver as long as we were using that. I recreated his MAC address fixes that he made in the driver and now we can actually start fixing it / accepting PRs for it!
Hi again,
Thanks for the quick response and awesome work!
I don’t remember for sure if I set the country code on the 1.20 image when I was testing hostapd, however I flashed the 1.22 image and even after setting the country code it seems to have had no effect for some reason.
After I modified
/etc/default/crdaand rebooted, I get the following output fromiworangepi@orangepii96:~$ cat /etc/default/crda
# Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may set
# the initial regulatory domain setting for IEEE 802.11 devices which operate
# on this system.
#
# Governments assert the right to regulate usage of radio spectrum within
# their respective territories so make sure you select a ISO/IEC 3166-1 alpha2
# country code suitable for your location or you may infringe on local
# legislature. See/usr/share/zoneinfo/zone.tab’ for a table of timezone
# descriptions containing ISO/IEC 3166-1 alpha2 country codes.
REGDOMAIN=US
orangepi@orangepii96:~$ sudo iw reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
orangepi@orangepii96:~$ sudo iw phy phy0 reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
This seemingly indicates the country code has not actually been set. Confusingly, this output remains the same even while connected to a wifi network.
orangepi@orangepii96:~$ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0: mtu 1480 qdisc noop state DOWN group default
link/sit 0.0.0.0 brd 0.0.0.0
3: wlan0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ba:3a:96:d3:49:58 brd ff:ff:ff:ff:ff:ff
inet 192.168.208.254/24 brd 192.168.208.255 scope global dynamic wlan0
valid_lft 3572sec preferred_lft 3572sec
inet6 fe80::b83a:96ff:fed3:4958/64 scope link
valid_lft forever preferred_lft forever
orangepi@orangepii96:~$ sudo iw reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
orangepi@orangepii96:~$ sudo iw phy phy0 reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
Attempting to set the domain by manually invoking crda also fails (two ways attempted)
orangepi@orangepii96:~$ sudo COUNTRY=US /usr/lib/crda/crda
Failed to set regulatory domain: -7
orangepi@orangepii96:~$ sudo /lib/crda/setregdomain
orangepi@orangepii96:~$ sudo iw reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
orangepi@orangepii96:~$ sudo iw phy phy0 reg get
global
country 00: DFS-UNSET
(2402 – 2472 @ 40), (6, 20), (N/A)
(2457 – 2482 @ 40), (6, 20), (N/A), NO-IR
(2474 – 2494 @ 20), (6, 20), (N/A), NO-OFDM, NO-IR
(5170 – 5250 @ 80), (6, 20), (N/A), NO-IR
(5735 – 5835 @ 80), (6, 20), (N/A), NO-IR
(57240 – 63720 @ 2160), (N/A, 0), (N/A)
`It seems that crda is not working (at least not fully) which could explain the issues with hostapd.
Hey MB3hel,
Great findings again! I can definitely confirm the iw reg command isn’t working for sure. I dug a little deeper and found this in the wireless driver (kernel/drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c):
/* This is to override regulatory domains defined in cfg80211 module (reg.c)* By default world regulatory domain defined in reg.c puts the flags
* NL80211_RRF_PASSIVE_SCAN and NL80211_RRF_NO_IBSS for 5GHz channels (for
* 36..48 and 149..165). With respect to these flags, wpa_supplicant doesn't
* start p2p operations on 5GHz channels. All the changes in world regulatory
* domain are to be done here.
*/
static const struct ieee80211_regdomain wland_regdom = {
.n_reg_rules = 4,
.alpha2 = "99",
.reg_rules = {
/*
* IEEE 802.11b/g, channels 1..11
*/
REG_RULE(2412 - 10, 2472 + 10, 40, 6, 20, 0),
/*
* If any
*/
/*
* IEEE 802.11 channel 14 - Only JP enables this and for 802.11b only
*/
REG_RULE(2484 - 10, 2484 + 10, 20, 6, 20, 0),
/*
* IEEE 802.11a, channel 36..64
*/
REG_RULE(5150 - 10, 5350 + 10, 40, 6, 20, 0),
/*
* IEEE 802.11a, channel 100..165
*/
REG_RULE(5470 - 10, 5850 + 10, 40, 6, 20, 0),}
};
This explains why we aren’t seeing any crda errors in dmesg or the kernel logs. The crda package is working just fine. The driver is just programmed to overwrite it with it’s own stuff.
Given that we don’t even have a 5G radio onboard the whole reason they broke regulatory for this (given by their comment) doesn’t even apply to the i96. The next time I am working on the image I am going to try commenting out these lines:
wiphy_apply_custom_regulatory(wiphy, &wland_regdom);Maybe this will let it use the regular regulatory information. If you want to give it a try before me though definitely go ahead!
EDIT: I was able to try this and it does appear to have done something:
Aug 7 13:25:18 orangepii96 kernel: [ 5.724487] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:: World domain. Setting XY/4: event handler failed (2): end of pending msg Aug 7 13:25:18 orangepii96 kernel: [ 5.725341] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.729675] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.730468] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.731384] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.732360] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.733276] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.734252] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.735229] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.787475] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.788269] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.789794] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.790649] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.791564] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.792541] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.793518] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.794433] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.842285] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.843078] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.843994] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.844970] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.859680] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.860412] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.861389] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.862304] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.863281] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.864196] cfg80211: Updating information on frequency 2484 MHz with regulatory rule:
Aug 7 13:25:18 orangepii96 kernel: [ 5.865234] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
Aug 7 13:25:18 orangepii96 kernel: [ 5.889099] [RDAWLAN_ERR]:
Aug 7 13:25:18 orangepii96 kernel: [ 5.945678] [RDAWLAN_ERR]:
Aug 7 13:25:18 orangepii96 kernel: [ 6.695434] enable vbus and disable charge
Aug 7 13:25:18 orangepii96 kernel: [ 6.696472]
Aug 7 13:25:18 orangepii96 kernel: [ 6.696838] rda_modem_pm_notify status:0x0
Is it working yet? A lot more than it was for sure but there’s still more to do/fix. It’s at least setting some frequencies now and trying to do something. The country code still isn’t right yet so there’s still more work to be done and I doubt hostapd will be happy with it yet but this is a really good sign that this is fixable here (eventually, it’s hard to say how deep the rabbit hole goes as the wireless driver is quite large spanning many different files and has added a dozen files to the project just getting this far).
I’m releasing these changes as 1.24 if you’d like to try them! The dmesg output from this version on the i96 is actually cleaner than the Ubuntu 22.04 x86_64 desktop I am typing this on (not perfect yet though)!
Hey,
Apparently it was common for older wifi drivers to hard code a regulatory domain (not sure why), so I’m not surprised to see this.
I got a chance to quickly test some things on the new image (1.24). I haven’t messed with hostapd yet (and I doubt it will work based on the following), but this is certainly good progress!
In my testing I get results very similar to what you have in dmesg, however I am not seeing the
RDAWLAN_ERRlines (perhaps because I set aREGDOMAINusing crda?).I did also notice a couple of things in the driver
– It looks like the
cfg80211_reg_notifierfunction actually does nothing with the regulatory domain info currently. There’s a disabled block (#if 0) around line 5314 ofwland_cfg80211.cthat seemingly disables the code that actually sets the regulatory domain. Perhaps it is worth enabling this to see what happens.– There are various traces prints that could be very helpful for following where in the driver things are happening. It may be beneficial to enable these by changing the log level in
wland_dbg.cby changing thewland_dbg_levelvariable and definingDEBUG.I don’t have a system setup to build an image on yet, but I’ll probably try the above two things when I do (unless you get to it first).
Hey MB3hel,
Perfect observations! You’re absolutely right here about everything. I’ve been working on the wireless driver this morning and have been working on getting traces enabled. Your tip will actually save me a ton of time as that is one of the things I was looking for (enabling tracing and debug output messages).
I can’t figure out this line:
wldev_iovar_setbuf(wdev->netdev, "country", &cspec, sizeof(cspec), cfg->ioctl_buf, WLC_IOCTL_SMLEN, NULL);This function doesn’t seem to exist:
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c: In function ‘cfg80211_reg_notifier’:drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:2: error: implicit declaration of function ‘wldev_iovar_setbuf’ [-Werror=implicit-function-declaration]
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:27: error: ‘wdev’ undeclared (first use in this function)
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:27: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:78: error: ‘struct wland_cfg80211_info’ has no member named ‘ioctl_buf’
drivers/net/wireless/rdaw80211/rdawlan/wland_cfg80211.c:5512:91: error: ‘WLC_IOCTL_SMLEN’ undeclared (first use in this function)
There’s no ioctl_buf, but there’s a couple other buffers that don’t sound quite right. I’m still playing with it but I’m exactly where you’re at. I also need to do some tests with the new tracing trick you showed me!
Hmm…
I didn’t look very closely at that code. It’s located in the section for kernels older than 3.10…
It looks like this driver was a copy of an older kernel driver (I think it may have originally been a driver for Android’s network stack) that someone “updated” to barely work on Linux 3.10 with some features (such as setting country) missing.
To get things working properly, it’s likely necessary to figure out what those functions used to do.
It appears that these likely came from
wldev_common.h/wldev_common.c, two random files that seem to be in most android 3.x kernels for wlan drivers. For instance this one and this one. I’d imagine (if this was an old android driver) these files were originally part of this driver too.I haven’t really looked through them, so not sure what they are / do, but
wldev_iovar_setbufis defined in these files so maybe we can figure out what they actually do. Just from the header comment it seems to be setting an “iovar” (not sure what this is / means). Perhaps looking at modern wireless drivers in the mainline kernel could shed some light on how iovars are handled in modern (and not android) kernels?Hey MB3hel,
I’ve done some more poking around and the thing that is really confusing me is that the iw and iwconfig commands are just… not working it seems like. No matter how I try to set the txpower it always just says it’s 1:
root@orangepii96:~# iwconfigwlan0 IEEE 802.11bgn ESSID:"jamesachambers.net" Nickname:""
NWID:off/any Mode:Managed Frequency:2.437 GHz
Access Point: 24:5A:4C:6A:7F:EC Bit Rate=54 Mb/s Tx-Power=1 dBm
I’ve enabled a bunch of logging features so I can see more of what is going on:
[ 786.290954] [RDAWLAN_CFG80211]: Done(qtxpower:0)[ 876.068054] [RDAWLAN_CFG80211]: Done(qtxpower:0)
[ 881.083007] [RDAWLAN_CFG80211]: Done(qtxpower:0)
[ 892.792236] [RDAWLAN_CFG80211]: Done(qtxpower:0)
[ 1512.652465] [RDAWLAN_CFG80211]: Done(qtxpower:0)
[ 1536.309509] [RDAWLAN_CFG80211]: Done(qtxpower:0)
[ 1574.824462] [RDAWLAN_CFG80211]: Done(qtxpower:0)
I think the way we set iovars is now like this:
err = wland_fil_iovar_data_set(ifp, "qtxpower", &dbm, sizeof(dbm));This could probably be adapted for the other function as I’m starting to understand how it’s working better but I honestly don’t want to go further until I understand why it isn’t showing my even fixed 20dBm regulatory setting in here. Great work on this, you’ve helped me get a lot further already!
I am also seeing this error with the new tracing but I don’t know what it means:
[RDAWLAN_SDIO]: isr w/o interrupt is disabled, so do nothing and return[ 5.614257] [RDAWLAN_ERR]:: event handler failed (2)
The second one I have seen before but the one before it was only revealed by the tracing. I’m releasing this as V1.25!
Hi James,
SPI is working now thanks to you and MZA.
For my e-paper display from waveshare i needed the Opi.GPIO library, but the pin definitions were missing.
I added them here.
I also made a pull request to the original project.
Here is the modified waveshare project which is working for me
Hey Michael,
Wow, you are our first confirmation! Thanks for checking this out and your great work getting it working! I’m definitely familiar with Waveshare and have a bunch of Waveshare products and am pretty happy with them.
I think I can probably add your GPIO library to the image as I’d imagine that the e-paper displays are going to be a better choice with the i96 than TFTs simply because they update and take a second or two to redraw but that’s totally normal for a e-ink/e-paper display so it shouldn’t be as much of a problem that it’s software driven as it is for a TFT which is ideally pushing out a decent number of frames per second at the screen’s full resolution for it to not look really choppy.
I could definitely add this in since it looks like this would be a good library to get other types of devices working as well!
UPDATE: This is out as 1.19