morrownr commented 1 year ago

@alkisg @paralin @RyanScott96 @AstroDrabb @ashah7 @Jibun-no-Kage @knightfall-cs @tamojitray @thjderjktyrjkt

There is one thing that is not on the list in #1 . As most of you know, we maintain 5 Realtek drivers here. Over the last year I have seen a big increase in country code related problems. I have been researching the issue and I still have no idea what can be done to improve the situation.

We see issues such as:

My 5 GHz wifi is not working, please fix it.

A suggestion to set the country code with $ iw reg set US or whatever the country code happens to be results in one of the following:

It does not fix the problem
It fixes the problem until a reboot and then the setting is gone
It fixes the problem

5 GHz is problematic because, unlike 2.4 Ghz and channels 1-11, there is not universal allowable channels so the default without the country code set is for 5 GHz to be shut down. From my perspective, it seems that we have a lot of distro maintainers that may not understand what they are doing. I could was poetic about this topic for a long time but I will spare you. In the end, it is one of the major issues that is reported.

What is the fix? I don't know. It could be that documenting how things should work is the best answer. It could also be that a check in the installation script could help.

I am asking all of you to think about this issue and if you have suggestions, please post. If you have friends that have suggestion, get the information and post. If you can find links to go articles or documents that we can use as a source, please post.

One last thing: it has been unusually quiet. Anyone having any problems or suggestions to report?

Nick

morrownr commented 1 year ago

FYI: I just merged what I hope is a fix or at least help: attempted fix for country code issues

It is a combination of improved documentation along with a default setting change for the driver.

Please test the heck out of this.

Thanks,

Nick

paralin commented 1 year ago

@morrownr

it has been unusually quiet. Anyone having any problems or suggestions to report?

My users currently using the public version of 8821cu from your other repo & have not reported any issues.

Jibun-no-Kage commented 1 year ago

@morrownr,

I am back on task now, should be testing again starting later today. Interesting, with the testing I have done thus far I was just setting the code to US and testing was done.

The local ISP (installers) have no clue what they are doing, every day I see more WiFi routers come on line, and the installer just picks the least used channel in 5G at the installation. Or worse, the horrible 'auto' feature is used.

The customers never seem to change it. Thus 5G for me is a mess. I finally created a WiFi scanner via some scripting and Node Red, to warn me when things get very ugly and then I get to change the channel again. Getting to the point I need an A.I. methodology to keep it stable and consistent?

Don't even get me started on power leveling. Everyone just cranks up the power level thinking it will improve connectivity and throughput, so the result is, every single WiFi router is screaming, in effect. So if I range limit mine, I get flooded.

I guess what I am saying is, unless we can educate, on how to range limit, do valid channel selection, etc., and create informed knowledgeable consumers of WiFi, can we really solve this issue? In a way, cell phones have created the perception, that I just turn the thing on, and it works... but what cell phones do... to get even a single bar, is actually, from a programming perspective very complex. And a key factor is 'cooperative interaction' cells phone do this by design logic well beyond anything a consumer WiFi router will ever do.

Jibun-no-Kage commented 1 year ago

Here is a thought, why can't the driver installer script peak at the locale information, and make a suggestion for the default region/country code? install-driver.sh, could ask one more question? "Based on your location, the country code will be set to X? [Yn] Warning, not setting a valid country code may result in 5 GHz communication being disable by default."

morrownr commented 1 year ago

@paralin

My users currently using the public version of 8821cu from your other repo & have not reported any issues.

Yes, the public driver seems to be solid which is why I am not in a big hurry to get this new code out there. It gives us time to do some deep dives to see if we can solve some problem areas that are external to the driver code. My estimate is that > 90% of the issues reported with the public driver are not something wrong with the driver code but with external issues in installation or with distro configuration.

With that said, when I first found this new source, I thought it would be easy to just merge the changes into the existing public driver but that turned out not to be true as the changes and fixes are actually more far reaching than expected. If we can take our time to test and work some of the common problems with installing and using this driver, I really think we can dramatically reduce end user issues.

morrownr commented 1 year ago

@Jibun-no-Kage

I am back on task now, should be testing again starting later today.

Welcome back. The fun starts now. There are now 10 of us here in the repo.

Interesting, with the testing I have done thus far I was just setting the code to US and testing was done.

That is how it should be. The reality is something different for many people. Since I regular see the posted issues for all 5 of the Realtek drivers maintained here, I see the ugliness more than most. Things related in one way or another to country code are the single biggest source of problem reports that I see.

The local ISP (installers) have no clue what they are doing, every day I see more WiFi routers come on line, and the installer just picks the least used channel in 5G at the installation. Or worse, the horrible 'auto' feature is used.

Hint: Installers never use DFS channels. At my current location, I can see dozens of routers. The regular 5 GHz channels are congested. The DFS channels are clear air. Not a single user on any of the 4 available 80 MHz width DFS channels. Take a look at the test I posted recently:

https://github.com/morrownr/USB-WiFi/issues/139

As long as you have a wifi router/AP that is capable of DFS channels, there should be a way to take advantage of it. Did you know that this driver we are working on supports AP mode DFS channels? I'll be glad to advise you on working toward using DFS in your local setup.

Here is a thought, why can't the driver installer script peak at the locale information, and make a suggestion for the default region/country code? install-driver.sh, could ask one more question? "Based on your location, the country code will be set to X? [Yn] Warning, not setting a valid country code may result in 5 GHz communication being disable by default."

Let me work on this idea and present something to this group. Using the installation script to ensure the country code is set seems to be a good idea. The single biggest problem I see within the country code problem is that most users never set the country code which causes problems.

Nick

Jibun-no-Kage commented 1 year ago

Yeah, give it a shot. As for DFS... since my WiFi router(s) are older, an sufficient for my needs (mostly IoT stuff), I have not worried about DFS per se. Frankly I enjoyed developing my own scanner setup. But you may have just driven the first nail into my old wifi infrastructure. LOL.

morrownr commented 1 year ago

Status:

I have merged the following:

I changed a setting in the driver to require the driver check the OS for country code. This is a non-default setting so please check to see if this working. Make heavy use of iw reg get and iw reg set XX to see what happens on your setup. Take a vacation to France (FR) or other countries and see what happens. Is this new setting working on your setup?
I am adding a new text document to the driver root directory that shows the alpha 2 country codes so that we can reference it in the documentation and scripts. I am stilling editing the document as of today.
I have added a blurb in the README in the Installation Information section about how to check and set the country code.
I have added a section of code to the installation script to check and display the country code.

Now, how should I handle the installation script now that it is getting and displaying the country code? Should I set up a check to see if the country code has not been set? If so, what is the logic that should be used? Should the code display instructions to the user and kick out (exit 1)?

Nick

Jibun-no-Kage commented 1 year ago

I would suggest if the code is already set, ask user to confirm it. If the code is not set, accept whatever the OS provides, ask user to confirm it. If not set, and can't determine from OS, then tell the user to get off their butt and set it correctly, if the script helps, facilitate it, so much the better.

The thing that bugs me about these 'things' (in general) is that most of the time a 'given' script just spits out a warning and exit is done. This is quick and easy for the developer, but it leaves the user say WTF? Now what do I do? Surely, with a little effort we can do better than that as the default behavior no? IMHO, why just exit cold, unless that is the really safest and best option? In this case, at least checking for existing and/or OS setting is a reasonable approach, right?

morrownr commented 1 year ago

If the code is not set, accept whatever the OS provides,

Below is the code I added to the installation script:

# display ISO 3166-1 alpha-2 Country Code
# https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
a2_country_code=$(iw reg get | grep -i country)
echo "Country Code=="${a2_country_code}

The code is asking for and then displaying what is set in the OS.

What the user will see if the Country Code is not set is:

$ iw reg get
global
country 00: bla bla bla

What I can key on is country 00 as that tells us no Country Code is set.

The thing that bugs me about these 'things' (in general) is that most of the time a 'given' script just spits out a warning and exit is done. This is quick and easy for the developer, but it leaves the user say WTF? Now what do I do?

I get that. I am going to try to avoid this outcome.

Determining in advance what will yield the best overall result is not always easy. Sometimes you have to do the best you can and then see what happens and adjust from there. What I think I have done so far is limit how this is going to work by having the driver default to using what the OS is providing as opposed to the driver detecting the country code from the AP/router or from a module parameter set by the user. By limiting how this works, we can focus on making sure the OS country code is set properly. In fact, I think what we are doing here is the default for in-kernel drivers and I am not sure why Realtek does it the way it does...that may be a big contributor to this problem.

So, if I am correct about my assumptions, all we need to do to what is in place right now is:

add logic to see if the country code shows 00
if the country code does not show 00 then assume it is set and press on
if the country code shows `00' then we need code to get the user to set it properly

Thoughts: Users may not know what their country code is. That is why I am adding the text file that contains the codes. How we smoothly get from Ah ha, you have not set your country code to happy results is still not clear to me. Anyone that knows bash is welcome to jump in.

We will get there.

Nick

morrownr commented 1 year ago

Last thought: You cannot imagine how many times I have ask users (remember there are 5 heavily used Realtek drivers here at the site) to post the result is of iw reg get and the result comes back with country 00. We MUST ensure users set their country code if it is not set... before I go crazy.

Why is the hell do the maintainers of the Linux distros not make sure the country code is set during the installation process is beyond me. I know that some try but I see it far too often.

Jibun-no-Kage commented 1 year ago

I remember an old saying, "You can't fix stupid." Is that too harsh? LOL. But users tend to be, ah... stupid sometimes, most times? Even me at times?

As I recall the only distribution that consistently does set the country code for WiFi is Pi OS. This is because the Pi Imager tool allows for the image to be seeded with locale settings. But the user has to do the work to set the values.

The raspi-config tool also (Pi OS) will not enable WiFi until the country code is set. Which for raspi-config is bash scripting...

get_wifi_country() { CODE=${1:-0} if [ -e /etc/default/crda ]; then . /etc/default/crda elif systemctl -q is-active dhcpcd; then REGDOMAIN="$(wpa_cli get country | tail -n 1)" else REGDOMAIN="$(iw reg get | sed -n "0,/country/s/^country (.+):.*$/\1/p")" fi if [ -z "$REGDOMAIN" ] \ || ! grep -q "^${REGDOMAIN}[[:space:]]" /usr/share/zoneinfo/iso3166.tab; then return 1 fi if [ "$CODE" = 0 ]; then echo "$REGDOMAIN" fi return 0 }

do_wifi_country() { if [ "$INTERACTIVE" = True ]; then value=$(sed '/^#/d' /usr/share/zoneinfo/iso3166.tab | tr '\t\n' '/') oIFS="$IFS" IFS="/"

shellcheck disable=2086

REGDOMAIN=$(whiptail --menu "Select the country in which the Pi is to be used" 20 60 10 ${value} 3>&1 1>&2 2>&3)
IFS="$oIFS"

else REGDOMAIN=$1 fi if ! grep -q "^${REGDOMAIN}[[:space:]]" /usr/share/zoneinfo/iso3166.tab; then if [ "$INTERACTIVE" = True ]; then whiptail --msgbox "$REGDOMAIN is not a valid ISO/IEC 3166-1 alpha2 code" 20 60 fi return 1 fi if [ -e /etc/default/crda ]; then sed -i "s/^REGDOMAIN=.*$/REGDOMAIN=$REGDOMAIN/" /etc/default/crda iw reg set "$REGDOMAIN" fi if [ "$INIT" = "systemd" ] && systemctl -q is-active dhcpcd; then wpa_cli set country "$REGDOMAIN" > /dev/null 2>&1 wpa_cli save_config > /dev/null 2>&1 fi

if [ "$INIT" = "systemd" ] && systemctl -q is-active NetworkManager; then nmcli radio wifi on elif hash rfkill 2> /dev/null; then rfkill unblock wifi fi if is_pi; then for filename in /var/lib/systemd/rfkill/*:wlan ; do echo 0 > "$filename" done fi if [ "$INTERACTIVE" = True ]; then whiptail --msgbox "Wireless LAN country set to $REGDOMAIN" 20 60 1 fi }

The question I have is what the country code setting in /etc/wpa_supplication/wpa_supplicant.conf has in this entire question? That should be set as well right? Do not the region setting and wpa_supplicant have to match? The interesting thing is, they can be set correctly under raspi-config.

The raspi-config tool definitely sets the WLAN country code in wpa_supplicant.conf as well as /etc/default/crda...

# cat /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=US

# cat /etc/default/crda

Not sure the above wpa_supplicant.conf matters to the driver? Maybe it should?

# 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

Jibun-no-Kage commented 1 year ago

I just realized why maintainers DO NOT DO IT. They assume the only connectivity is ethernet or nothing. The various installers all have the same design, you load OS via media or Network install, which is only really feasible via wired connection. So they dodge the entire question by default.

morrownr commented 1 year ago

I just realized why maintainers DO NOT DO IT.

Yes, it is because it is hard and the only real computer users use ethernet.

Why is it hard? I think you hit on some of the reasons inadvertently:

as well as /etc/default/crda...

I'm pretty sure that has been depreciated. But like everything else that is depreciated, being depreciated does not remove it from the internet so users end up fixing problems with old information that no longer works.

> # cat /etc/wpa_supplicant/wpa_supplicant.conf

wpa_supplicant is depreciated in the latest 22.10 of Ubuntu and all the little Buntu's. Not sure what iwd is doing at this point.

As I recall the only distribution that consistently does set the country code for WiFi is Pi OS.

Yes. The script you posted seems to have depreciated things in it but since RasPiOS is based on Debian which is always 10 years outdated by the time a new version is released, I can see that.

Your post is helping everyone understand why this is a messed up situation. How we make WiFi work on Linux is beyond me. However, based on the users of the Realtek drivers here and the number of issues reported, my estimate is driver installation and function is about 95% successful.

Our solution here does need to consider older ways of doing this as well as the newer way which is why I wanted to change the default in the driver and detect the unset country code with the installation script and then do something about it. I think this basic idea has potential.

Nick

Jibun-no-Kage commented 1 year ago

Yup, I think so as well. At this point doing something is much better than nothing. Even if we have to bridge a rather long time window in depreciation scope.

The sad thing is, this is core to Linux, incomplete synchronization of advancement. I almost cried in humorous anger when I heard that Linux Torvalds said that ZFS should not be used, that it was not supported well any more. And BtRFS has been in development for how long, like 11 years, still considered alpha not even beta? But such is the life of Linux.

Jibun-no-Kage commented 1 year ago

Ok, first thing tomorrow, I am starting a new testing cycle. I will hit same distributions as before.

Pi4 ARM64.... Ubuntu Kali Manjaro PiOS Fedora 37 (If I can get it to work, last time it refused to bring up Gnome)

x86_64... Fedora Debian 11 Xbuntu PiOS Manjaro Mint (just for fun) Kali

Anything add or remove? Figure will focus on Workstation variants, with Server variants as applicable Xbuntu Ubuntu

paralin commented 1 year ago

Why is there no global "this is the regulatory country we are in" variable in the kernel that everything else follows, at least on default? It's so odd that everything has to be separately configured for that.

Seems to me like another approach that would work is - scan everything, if there's a station, when connecting to it match its regulatory domain.

But then again, I'm sure there's a lot involved here that I don't know anything about and I agree it's complex and definitely broken in many ways in Linux.

Jibun-no-Kage commented 1 year ago

@paralin,

I would say, in theory, wpa_supplicant.conf would be the logical place for said 'global' configuration, but... as is the case with open source, every author controls every aspect of the project by default, so you get regression of standards (if any exist at all) until there is an authority established. Red Hat is an example of this, in that because Red Hat has RHEL, that is legally and functionally a standard, it aligns design. However, the only reason RHEL is a defacto standard, is because of indemnity... meaning no business adopts an open standard alone... they will want someone to be on the financial hook, so open-source is often leveraged but the actual solution is commercial, licensed and owned. Regardless of it being mostly open source or not, in origin or practical long term development.

Only read the following if you want...

An example of this, a few years ago, IBM/Tivoli Agents had a DNS resolution related bug in their commercial monitoring solution, similar to HP iLO/Agents, Dell iDRAC/OSMA, The bug was that a DNS name in all CAPS was not resolved, but the same name via DNS lookup in lower case was accepted, resolved. This is clearly a RFC violation of the published standard that DNS FQDN should be case insensitive. And I reference "RFC 4343 DNS Case Insensitivity Clarification January 2006 1." However, in 2008 or so, the IBM engineering team, at the time for Tivoli Agents, told me, as I then worked for a Fortunate 10 company, as an Enterprise IT architect, that they would NOT FIX the bug, because they found the bug was actually in an open-source component of Tivoli monitoring solution. They suggested I fix the bug and submit the fix for review. WTH! Right in a conference call they refused to take corrective action.

So get this, a several million $$$ contract, solution, has a bug, and IBM is refusing to fix it. I informed IBM that I was one call away from the legal group, to initiate legal action for non-performance under our indemnity section of our contract with IBM. Because IBM is refusing to fix a bug that happens to be in an open source component of a commercial product IBM sells world wide? There was silence on the conference call, then obviously a muted discussion on their end. I was told they would handle it internally, and get back to me in a timely manner. Would have paid $$$ to be a fly on the wall in the room after that call at IBM.

In short, the bug was fixed, and I got updated Tivoli Agents in 48 hours to finish validation testing of the monitoring solution in question. Which we deployed world wide to every IBM server we owned/purchased over several years after this event. And, about 2 weeks or so later after said conference call, I happen to be reviewing the FOSS open-source fixes publication list for the solution, and noticed that a software engineer for IBM had submitted a bug fix for the open-source component in question. Go figure.

Nor was this the only time I had to do this, DELL got into the hot water on an open-source bug in their iDRAC firmware. Interestingly, HP (guess smarter than IBM or DELL at the time) actually via formal request, asked my engineering team to consult on their pending HP iLO solution enhance effort the same year, so we found a few bugs that got fixed with little hassle at the time, HP always seem to be on the ball back then, maybe it was the Compaq legacy mind-set that influenced them?

Now just imagine, if the open-source in question had no commercial leverage or support? How long would the bug exist, how long would the finger pointing continue? I got yelled at, by my boss, about 2 years before all this, for saying in a meeting, "You only have a standard... when it is (actually) implemented." My boss later in private, said and I quote, "Don't say that shit to management, I almost pissed myself. And, of course you are right, but there is a time and place, you know?" LOL

paralin commented 1 year ago

@Jibun-no-Kage very interesting read, matches my experience as well.

Re: the wpa supplicant conf thing: that would not be an appropriate global config location for this as that config file is not used anymore in most environments, having been replaced with NetworkManager which automatically configures wpa supplicant as needed.

It used to be that you'd add to /etc/network/interfaces a hook to start wpa supplicant using that config file, but that was extremely brittle and prone to breakage.

Jibun-no-Kage commented 1 year ago

I guess my bias with Linux is apparent, 95% of my experience with Linux was server based, over time, especially as I moved into supporting virtualization, first VMware (in 2001 yes, before VMware as public), then Hyper-V, then QEMU/KVM, and even RHEV. Odd thing is I never really got into XenServer other than to break it in the lab frequently. I did spend time LXC, which in some ways I still like better than docker, but I digress.

It was not until I started using micro-controllers, and then Pi devices that I did much with Linux desktop. Is NetworkManager truly going to own the world? So to speak? Not debating, just thinking. Then since so much of 'system' configuration is somehow spinning around systemd as well right? I would say either /etc/default/... is dated as well? I would not say dconf, since it is so tightly integrated to Gnome? We need to be 'UI' independent or consistent across UIs?

The entire networking stack, IMHO, needs to be qualified and standardized, it is IMHO one of the ugly issues with Linux over time. You have some implementations like Debian dragging ass, but others blazing forward.

morrownr commented 1 year ago

@Jibun-no-Kage

Ok, first thing tomorrow, I am starting a new testing cycle. I will hit same distributions as before.

Much appreciated. Use your own judgement and take your time. I am going to post a new issue listing some emphasis items right after I send this message so please read that issue.

Nick

morrownr commented 1 year ago

The entire networking stack, IMHO, needs to be qualified and standardized, it is IMHO one of the ugly issues with Linux over time. You have some implementations like Debian dragging ass, but others blazing forward.

Amen brother! Preach on.

Let me repeat it:

The entire networking stack, IMHO, needs to be qualified and standardized!

Betwen the above and You have some implementations like Debian dragging ass, but others blazing forward. , it is difficult to work things like this driver. A lot of time ends up being wasted. In the docs for this driver, I have now added statements that RHEL and Android are not supported. We simply do not have time to be everything to everybody and that is especially true when distros make it very hard and both of those distros make it hard.

Jibun-no-Kage commented 1 year ago

If, I still had access to RHEL, I could test, but CentOS is no longer a RHEL mimic, and Fedora is NOT, in anyway RHEL, so there is no effective way to validate for RHEL. I have friends at Red Hat, I could maybe ask, for a limited RHEL license, but since I don't have current hardware sufficient to what we would need, I am not going to ask at this time. And, technically WiFi on RHEL is a horrible idea, IMHO. Just the thought of WiFi on a server OS, gives me the hibbie-jibbies.

morrownr commented 1 year ago

If, I still had access to RHEL,

Don't worry about it. It won't work. I interact with many different users including the periodic RHEL user. I don't restrict RHEL devs from merging needed mods if they want RHEL support in these drivers. If you look at 88x2bu, it supports 2 versions of RHEL. I just won't support it because I don't have access to RHEL and what Red Hat does really sucks...as far as wifi goes.

But thanks for asking.

Jibun-no-Kage commented 1 year ago

Sure. :)

morrownr commented 1 year ago

Just to add to the discussion:

https://wireless.wiki.kernel.org/en/developers/regulatory/crda

That is the official documentation on the Linux kernel site. Note that it was last edited in 2015. I think we are going to have to come up with better info than this so that we fully know how things should be done these days so I am going to search. Please help with this search.

Nick

paralin commented 1 year ago

On my machine running network manager it appears to set the regdom correctly:

I guess everything is fine with network manager? This seems like it's out-of-scope for the driver to worry about. Just let the OS set the regdom and use whatever it says.

Jibun-no-Kage commented 1 year ago

The only thing confirm, then, for our understanding is how consistent this is, meaning, are all the targeted distributions we have itemized, behave in like manner. I would expect workstation variants to be fairly consistent, but server variants, could be all over the place.

paralin commented 1 year ago

Note that NetworkManager runs as a lightweight daemon and is not necessarily connected with any GUI. I don't have a GUI for it on my machines and just use nmtui. So it's likely to be present even on server distros. And the distros that don't use it probably have some other solution for setting the regulatory domain and/or don't use wifi at all.

morrownr commented 1 year ago

Let me pile onto what Jibun said.

My Raspberry Pi says hi. Network Manager. I don't need no stinking Network Manager.

There are a lot of distros without Network Manager so Network Manager cannot be key to this problem... I hope.

I'm still digging.

morrownr commented 1 year ago

So it's likely to be present even on server distros.

I'm pretty sure it is not present at all on Ubuntu server. Until this last version of the Raspberry Pi OS, NM was nowhere to be found. NM is now being included but not activated on the RasPiOS.

If we keep arguing about this, we will figure out what is going on. Life is good!

paralin commented 1 year ago

I don't need no stinking Network Manager.

Then it's your job to find a way to set the regulatory domain correctly. It's still not up to the driver to do so.

By the way, I use NetworkManager on the Pi and it works fine with very low resource usage. Including on the licheerv dock which is a risc-v machine with half a gigabyte of RAM.

morrownr commented 1 year ago

It's still not up to the driver to do so.

Are you aware that this driver and the other Realtek drivers that are maintained here have a module parameter called:

rtw_country_code

That's right. So, let's see. Network Manager can set it. wpa_supplicant can set it. The driver can set it. Iw can set it...

but too many people don't set it and they end up whining about problems.

Now, which of the above are used and work is as clear as mud in this day in time. What is needed for this driver is a universal or near universal solution that is easy to use and easy to catch in the installation script.

paralin commented 1 year ago

Are you aware that this driver and the other Realtek drivers that are maintained here have a module parameter called:

yes, I'm saying that it's the job of something external to the driver to set this parameter. in most cases, networkmanager.

If you cause the driver to set this automatically it'll be beyond the scope of what all the other rtl drivers do automatically (afaik).

Edit: from your original post:

It could be that documenting how things should work is the best answer.

I agree, of course document it.

Jibun-no-Kage commented 1 year ago

I think the idea we had before, was to 'yell' at the operator to make a decision at ./install-driver.sh before reboot, if it is not set. Of course, the installer-driver.sh script can do a couple of sanity checks, like did NM set it already? Did wpa_cli set it already? Etc. If anything has set it, we could just report the the driver script is going to honor was is set, to the operator, and move on. We can't educate the operator, on which method of it being set... is best, that is just not possible. We can explain this in the documentation, like hey bro (or gal) get off you butt and learn why this needs to be set.

morrownr commented 1 year ago

If you cause the driver to set this automatically it'll be beyond the scope of what all the other rtl drivers do automatically (afaik).

I am not saying that the driver should set the country code automatically. I am saying that the installation script should catch when the country code is not so that bla bla bla can happen to make sure it gets set.

Jibun-no-Kage commented 1 year ago

Yeah, just a question if not set at all, I think was the original idea.

morrownr commented 1 year ago

just a question if not set at all

That is the exact problem. The country code not being set and then users end up posting issues. I enjoy helping Linux users but I am expending more time on it than I have available. I have got to cut down on the number of issues that are posted. This site, github.com/morrownr, averages over 10,000 hits per week.

Jibun-no-Kage commented 1 year ago

I noticed that a while ago, just how crazy busy the site is.

morrownr commented 1 year ago

I noticed that a while ago, just how crazy busy the site is.

github provides reasonably good analytical data. Interestingly, a much higher percentage of users are corporate IT types than I would have expected. Another interesting bit of info is that several companies involved in the industry keep an eye on this site. Some of the Mediatek devs stop by. Alfa not only monitors the site but heavily links into it via their support site. There are others as well. I think there may be more home Linux users than is realized and certainly more usb wifi Linux users than many would expect.

Back on topic:

I have added the following to install-driver.sh.

# display  and check ISO 3166-1 alpha-2 Country Code
a2_country_code=$(iw reg get | grep -i country)
echo "Country Code="${a2_country_code}
if [[ $a2_country_code == *"00"* ]];
then
    echo "The Country Code is not properly set."
    echo "File alpha-2_Country_Codes is located in the driver directory."
    echo "Please read and follow the directions in the file.
fi

It displays the country as gathered from the OS via iw. It then checks for 00 and if it is there, then it simply provides instructions without stopping. (not sure is that is the best solution)

Also, please take a look at alpha-2_Country_Codes to see what you think. I am still working on lining up the country codes and that may take a while.

Suggestions?

paralin commented 1 year ago

@morrownr note that the reg is only set after connected to a network. On my machine w/ three adapters:

$ iw reg get | grep -i country
country 00: DFS-UNSET
country US: DFS-UNSET
country US: DFS-UNSET

Jibun-no-Kage commented 1 year ago

KISS is always good, i.e. Keep It Simple S.... my real name starts with an 'S' where Jibun no Kage is actually my Gamer Tag, but so many know that handle, it has become like a nick name. I have to keep telling myself NOT to over engineer stuff, so I like what you have so far, simple, explicit, straightforward. One question, how are you going to cross reference the codes? Or are they always 1 to 1 per country? If you do need a cross reference, maybe a /etc/.db file? Just thinking a bit out side the box? I just had to do this for my own udev rules for mounting USB disks, where I have several identical USB thumb drives, and I did not want to go to the trouble to capture all the serial numbers, so just wanted all 'X' manufacturer USB thumbs to be mounted as 'USB X'. Used a DB file to setup the assignments, keeps stuff out of /etc/fstab, safer to change the db file.

morrownr commented 1 year ago

@paralin

note that the reg is only set after connected to a network.

Well, yes. To step back for a moment: I am not looking to solve world hungry and world peace though that would be nice. All I want is to reduce the numbers of reported issues via better information to the user and other minor tweaks that prove to work. The installation script now posts the value of the country code as reported by the os. I'm also adding a test file with the country codes and basic instructions of how to set it via iw. This simple approach may reduce the reported issues. We will have to see and can react based on input.

For now, I need to continue on with another major problem that I have yet to post: How to determine with a bash script if the correct kernel headers for the currently active kernel are installed.

paralin commented 1 year ago

@morrownr it seems like you're trying to reimplement what dkms does with your install script. Have you considered using dkms?

Jibun-no-Kage commented 1 year ago

Have you taken a look at what rpi-source does? I have not got back to it, per se, like I want to fix the python2 dependencies, but what it does do is pull the correct headers for the installed kernel that is active, even if the active kernel is ahead of the official packaged headers, that would seem to be parallel to what you state is a pending challenge, ensuring hat is needed is present, part of it? Or am I misunderstanding?

Jibun-no-Kage commented 1 year ago

FYI... my SD card reader just melted, yes, melted.

Apparently an SD card failed in mid write and got so hot (before I noticed) that it melted my USB 3.0 reader. I have another one on order (different model). The one I had was running a bit warm all the time, but now, it is dead, and was so hot barely could remove it.

https://forums.raspberrypi.com/viewtopic.php?t=202314 Interesting, I had not know this is apparently an issue of some note, Google has quite a few hits on this, very hot SD card failure, scenario.

morrownr commented 1 year ago

@paralin

it seems like you're trying to reimplement what dkms does with your install script. Have you considered using dkms?

The installation script uses dkms if it is installed.

Jibun-no-Kage commented 1 year ago

Nick where do we submit our expense reports? JUST KIDDING.

morrownr commented 1 year ago

@Jibun-no-Kage

Have you taken a look at what rpi-source does?

No. Can you put me on it?

morrownr commented 1 year ago

@Jibun-no-Kage

my SD card reader just melted, yes, melted.

Doesn't surprise me. Hope it did not damage anything else like a usb port.

morrownr / 8821cu-20210916

WiFi Country Code has turned into a nightmare #16

shellcheck disable=2086