Like many/most wifi drivers, the ath9k driver queries your wifi adapter's eeprom to discover its country-code, and this component of the driver has been known to fail, resulting in the driver trying to communicate with the wrong range of channels and frequencies for your country. Obviously, you will fail to connect to a wifi access point in this case.

How will you know? When you run the "dmesg" command you will see something like this -

Quote:

ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: xx

It's feasible that later versions of the ath9k driver may fix this problem, but a solution in the meantime is to manually specify your country-code. This requires a specially modified version of the ath9k driver, now attached.

UPDATE: DON'T install the rfkill-upgrade dotpet! This is likely to conflict with the modified ath9k driver.

Once you have installed the ath9k driver dotpet, use Geany to open /root/my-documents/ath9k-country-codes.txt
and look up your country-code. For example, Australia is "36".
Now add 32768.
36 + 32768 = 32804 - this is the Atheros country-code value for Australia.

Now change your modprobe configuration file;
for older versions of Puppy use Geany to open /etc/modprobe.conf
or for newer versions of Puppy you must create a new text file in /etc/modprobe.d/
I suggest you call this file "ath9k.conf". Any name will do, as long as it ends in ".conf"
In both cases, add this line -

Code:

options ath9k override_eeprom_regdomain=value

Where "value" is the figure we established earlier (32804 for Australia).
Save.

Now reboot, and you should be good.
But it might also be necessary to reset your wifi router, since earlier attempts to connect may have "confused" the router into using the wrong frequency range.

Same situation as above, but with the ath5k wifi driver.
Follow the instructions above, but when adding the country-code configuration line to your modprobe configuration file, obviously substitute "ath5k" for "ath9k".

And a reminder - DON'T install the rfkill-upgrade dotpet! This is likely to conflict with the modified ath5k driver.

Here (and in next message) are all of the previously available analog dialup modem drivers other than for the SmartLink PCI and USB modems and the HCFPCI modems. The versions are the same as in Wary 5.1.2. The packages can be installed only as needed or all together for a complete set.

The SmartLink modem drivers appear to be almost abandoned by the responsible parties. While work continues on an Ubuntu version of the drivers, the latest from the technion site (3/21/2011, slamr) still fails to connect, spewing "NO CARRIER" messages until stopped manually. As for the USB version, support has apparently been ended altogether. Furthermore, the proprietary component has not kept up with kernel developments and cannot be maintained by anyone but LSI.

Although Barry has included both drivers in Wary, the PCI driver spews "NO CARRIER" and the USB driver spews initialization and shutdown "disaster" messages and may corrupt the data (pupsave) file. Beyond those issues, the PCI modems apparently require reloading of the slamr module and restarting of the user-space daemon (slmodemd) for each connection after the first in a bootup session. Omitting those drivers avoids subjecting users to those risks, which would damage Lucid Pup's reputation for stability.

Note, however, that ALSA modems that use the slmodemd user-space component are still supported.

The HCFPCI driver is omitted because it requires each user to pay the developers US$15 to activate a usable data rate beyond 14.4 kbs. If anyone needs or can use the HCFPCI driver at that speed (or can pay), please tell me and I can add it. My thinking, though, is to avoid suggesting that HCF modems are usable without making the payment, which might be difficult from some parts of the world.

I have tested examples of all of the modems except for HDA modems, modems requiring the non-HDA Agere (agrsm) drivers, and the Intel 537s. Note that the newest driver for the 537s does not support the Dell version of 537EP, making mine useful only for verifying that the variant selector still works.

Regarding the HSF- and Agere HDA drivers: I have my doubts whether they can work, but have no way to experiment with them. There may be mismatches between the versions of ALSA used by Lupu and those expected by the drivers. I believe I saw that the Agere was coded for ALSA 1.0.20 and that the HSF may need a patch to the Intel HDA driver(s) associated with the target ALSA version. Lucid Pup has 1.0.24. Although we could experiment with patching for the HSF HDA driver, my only hope for the Agere is that the newly released version of the HDA driver might help. Beyond that, I have no idea what to do about the Agere HDA mismatch, other than wait for further updates from the developer. Advice from ALSA experts is hereby requested.

EDIT: Peebee reports that the Agere HDA driver works in all recent warys, including 5.1.4.1, but still does not work in Lucid Pup. They all use ALSA 1.0.21a. Unless there is something I have missed about setting up the driver, it appears that the difference in ALSA versions and possibly kernel versions might account for the different behavior.

EDIT: I have concluded that the Agere HDA modem driver cannot be used in lucid pup 5.2.8 because the current ALSA version is different from the version that came with kernel 2.6.33.2 (1.0.24.2 vs. 1.0.21). The driver requires the versions to match. For the future (Three-Headed Dog), we should avoid changing the ALSA version from that of the kernel if we are to have working Agere HDA modem support.

I think I will add logic to the packages containing the Agere 11c11040 driver to prevent installation of the driver if the ALSA versions differ, as shown by these commands:

cat /proc/asound/version
alsactl --version

That way, the modem simply will not be detected (because it is not supported) rather than tease the user by detecting it and making it appear to work up to a point.
RichardLast edited by rerwin on Fri 16 Sep 2011, 22:21; edited 6 times in total

I have tested examples of all of the modems except for HDA modems, modems requiring the non-HDA Agere (agrsm) drivers, and the Intel 537s. Note that the newest driver for the 537s does not support the Dell version of 537EP, making mine useful only for verifying that the variant selector still works.
Richard

Hi Richard

Started with a pristine frugal install of 528.
Rebooted to create savefile.
Install the Instant Update 001 pet and then
the Agere HDA modem pet dialup_modem_drivers-hda-hsf-k2.6.33.2-20110913.pet

dmesg seemed to suggest the ttyAGS3 had been correctly loaded however when I went into pupdial to test it the driver crashed:

peebee,
This agrsm-HDA thing is maddening, isn't it. I found a posting from a year ago (from someone else) describing the same problem, but with no responses to it. There is a new version of the driver out there, but I do not see any code change that would improve things. You can try it, but don't expect much. You can install it on top of what you have, or start fresh and use it instead of the HDA-HSF combo package.

I see your statements of a year ago about success with wary 060 or 070, or such. Where did all that end up? Does wary 5.12 work for you?

BTW, to keep this thread dedicated to providing drivers without the clutter of debugging conversations, we should take this discussion elsewhere. How about to your original thread on this subject?
http://www.murga-linux.com/puppy/viewtopic.php?p=322455#322455
RichardLast edited by rerwin on Thu 15 Sep 2011, 20:49; edited 1 time in total

Now open one of the "modprobe" configuration files, this will depend on which version of Puppy 5.x you have;
for older versions of Puppy it will be /etc/modprobe.conf
and for newer versions it will be /etc/modprobe.d/puppy.conf

The /etc/modprobe.d directory lets us avoid having multiple people maintaining the same file (e.g., puppy.conf, controlled by BK). Any additional module-specific configuration statements should go into separate .conf files named to identify the module(s) affected.

So, the line:

options ath9k override_eeprom_regdomain=value

might go into ath9k.conf. There are probably other naming schemes that would be good, but the point is to use separate .conf files where appropriate.
Richard

Tempestuous, still looking for a modification of your b43 post to take into account the /etc/modprobe.d arrangement in newer Puppies. I cannot see where to put those pio commands. I definitely need to use PIO because dmesg gives "This device does not support DMA on your system. Please use PIO instead." It also says, "ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel configuration."

Well, I thought I was running 528. At least, in PUPSTATE it says "PUPSFS='sdb1,vfat,/lupu_528.sfs'". There is a 529? Sheesh, I can never keep up.

I too wondered about all those downloads. Did people try your fix, and it works most of the time? I did mention that your fix actually made it work for a short while on my machine. Maybe there is a timing issue or race condition that mostly works out OK? There does seem to be a lot of confusion and difficulty in the forum with this bcmxxxx hardware...

As to the message, doesn't that come from the driver, so it doesn't matter what kernel it is running under? I also thought it was strange the driver wouldn't just fall back to PIO automatically, with maybe a note to the log about it. Yes, I do want to get serious about diagnosing it. Here is the dmesg:

PaulBx1, I have done some digging, and it appears that I need to recompile the b43 wifi driver with PIO mode explicitly (and permanently) enabled ...
... but in the meantime, I have a feeling that the standard b43 driver might "behave" better if it's reloaded after boot up. Pleas try this - once booted, run these two commands:

Code:

rmmod b43
modprobe b43

Now run the "dmesg" command, and see if it looks more healthy - what I'm hoping is that you won't see this -

Code:

b43-phy0 ERROR: This device does not support DMA on your system. Please use PIO instead.

If you do not see this error, then go ahead and run the Network Wizard, and hopefully you will get a successful connection.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum