Would you happen to have such a list or pointers?tempestuous wrote: it's far easier to list all the non-WPA compatible drivers instead of listing all the compatible ones, as is the case presently.
Thx
Would you happen to have such a list or pointers?tempestuous wrote: it's far easier to list all the non-WPA compatible drivers instead of listing all the compatible ones, as is the case presently.
We could leave in CARD_WPA_DRV to keep changes to a minimum.tempestuous wrote:I like the simplicity of your code, and you're on the right track, but no, the whole logic needs to be adjusted -mavrothal wrote:You mean something like this?Code: Select all
INTMODULE=$(readlink /sys/class/net/$INTERFACE/device/driver) INTMODULE=${INTMODULE##*/} case "$INTMODULE" in prism2_*) USE_WLAN_NG="yes" ;; # orther_no_wext_card) add as needed ;; *) CARD_WPA_DRV="wext" ;; esac
the CARD_WPA_DRV variable is completely redundant, and we can dispense with this variable altogether.
Code: Select all
# In showProfilesWindow() function line 309-443
INTERFACE="$1"
INTMODULE=$(readlink /sys/class/net/$INTERFACE/device/driver)
INTMODULE=${INTMODULE##*/}
case "$INTMODULE" in
#Drivers with no WPA support
driver1|driver2|driver3|driver4|...)
if [ -f "$Extra_WPA_Modules_File" ] &&\
CARD_WPA_DRV=$(grep -m1 "^$INTMODULE:" $Extra_WPA_Modules_File) ; then
CARD_WPA_DRV=${CARD_WPA_DRV#*:}
else
CARD_WPA_DRV=""
NO_CARD_WPA_DRV="Yes"
giveNoWPADialog
fi
;;
prism2_*) USE_WLAN_NG="yes"
;;
*) CARD_WPA_DRV="wext"
;;
esac
# In setupNewProfile () function lines 956-989
if [ "$NO_CARD_WPA_DRV" ] ; then
ENABLE_WPA_BUTTON='false'
ENABLE_WPA2_BUTTON='false'
fi
Sorry I can't help with the technical problems, but the foregoing could perhaps be resolved by including a GUI app on the networking submenu. It might only need a yad or gtk-dialog script. Noobs only have to click it, respond as necessary to the dialog, and post the resulting log.tempestuous wrote:
We often don't learn about these problems until someone on the forum reports some item of non-functioning hardware, and we go through the often awkward process of trying to coach new users into providing the necessary diagnostic information. The resistance we encounter to new users running a manual command in the terminal is one of the great frustrations of being involved on this forum, and IMO the greatest roadblock to being able to provide accurate help.
:
Code: Select all
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
Code: Select all
ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"
mavrothal wrote:Funny jamesbond, we were discussing these with Mick (udev rules and kernel/firmware/aufs-utils in zdrv).
I guess FD cross-pollination
You don't need the full udev if you don't want to - you can use busybox mdev for that. Or you can just take udev's "firmware" program. Or you can even write a script to do that for youOne issue is that puppy traditionally does not include the udev-extras where frirmware is coming from but I guess this can change (Slacko has a full udev)
Code: Select all
Udev rule: SUBSYSTEM=="firmware", ACTION=="add", RUN+="/sbin/firmware.sh $env{FIRMWARE} $env{DEVPATH}"
Script /sbin/firmware.sh:
#!/bin/dash
echo 1 > /sys/$2/loading
cat /lib/firmware/$1 > /sys/$2/data
echo 0 > /sys/$2/loading
I'm not sure what you mean by "off-tree" firmware. Is it the firmware you put in /usr/modules/all-firmware? If yes, answer is no, you'll need to write your own firmware loader.I'm just not sure how udev is going to handle off-tree firmware. Is it working in FD?
I guess I mean firmware that is not coming from the linux-firmware.gitjamesbond wrote:I'm not sure what you mean by "off-tree" firmware.
Then it's not a problem. All firmware in linux-firwmare were more or less from third party, once they clear licensing issues then it gets included in linux-firmware.mavrothal wrote:I guess I mean firmware that is not coming from the linux-firmware.gitjamesbond wrote:I'm not sure what you mean by "off-tree" firmware.
This is a happy problem that Fatdog doesn't have (because it doesn't have any analog modem drivers, ouch! ).I also looked a bit more in all-firmware.
An issue is the support for different modems where besided the install script hat usually modprobes, there is also an entry in /etc/init.d fro starting th modem at boot-up.
That being said, I did spend sometime looking at slmodemd a long while ago (I did try to add analog modem drivers to Fatdog, but some of them are 32-bit binary blobs ... so I gave up).How this could be handled?
Just move the init.d and install script from all-firmware in say /usr/share/modems-setup and call them from there as needed?
As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.Karl Godt wrote:Just looked into /lib/modules/all-firmware/pgprs :
All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .
I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
Honestly, Richard, do what ever you want .rerwin wrote:As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.Karl Godt wrote:Just looked into /lib/modules/all-firmware/pgprs :
All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .
I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
Note that Barry has moved some of the firmware "tarballs" to individual pet packages with "firmware" in their names. I probably should put pgprs into its own package, although "firmware" would not be appropriate in its name.
Richard
Code: Select all
echo "## DO NOT EDIT !
## THIS FILE IS AUTOGENERATED by $0
## Edit this template in $0 instead. Thanks.
" >> /etc/wvdial.conf
Upgrading the kernel from 2.6.37 to 3.4 ..dmesg wrote:[ 9131.104368] phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
did this too and its simple and just mean 2 more entries in an already busy but rarely visited network menu so really an unnoticed addition.Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.