Why not just parse the MAC address of each NIC? You can use /usr/share/nmap/nmap-mac-prefixes as a MAC address database to get the vendor. Then invoke lspci and lsusb to identify the driver. Seems a lot simpler to me. I do not recall where, but I am pretty sure there is a second file like this (different file name and package source) on a stock Slackware installation, that may be more accurate. Maybe in /usr/src/`linux-uname -r` or similar?

EDIT: Build a new package on 14.2 with the latest nmap to update that mac address listing. -current probably already has the latest nmap.

I was mistaken. oui.txt from the arpwatch SlackBuild on SBo.

https://docs.slackware.com/howtos:so...dress_database

Are you talking about /usr/share/hwdata/oui.txt? I haven't thought about that before but this is actually a very good idea, we could always print vendor name the way users know it reliably:
It would work with my USB TP-Link Wi-Fi adapter and with SDIO chips as the one used on Rpi.
We don't need lspci/lsusb to print driver name, see https://www.linuxquestions.org/quest...ml#post6151312. Also, I think that as we now can get vendor name reliably there is no need to print driver name or use lsusb/lspci to help identify the device. Something like that:
or
is also confusing for users - both examples print vendor name reliably but the first example reports driver name that most users don't have idea about, don't care and don't see labeled on their device and in the second example model name is completely broken.

Yes, /usr/share/hwdata/ has a few other txt files that may be helpful too.

I found something online that would be able to download the latest oui database, but that would obviously require an internet connection. (EDIT: I don't think nmap is available on installation, so it would be a lot to include that package just for the single text document.)

Overall, I think I've spent a lot more time on providing a selection for two wireless NICs than I should've. The amount of systems that are likely to have dual wireless NICs is probably relatively small. It doesn't *need* anything beyond something simple designating the difference between the two devices. I just thought it would be nice to show more details, but I quickly found it was was not as simple with all the varying hardware out there.

Even if we look at the MAC addresses, my two NICs in my system (one ethernet and the other wireless), both are Intel, but one MAC shows Intel and the other shows ASRock (my motherboard manufacturer).

I'm not sure if it's worth adding yet another check. When available, lspci and lsusb output seem to be a lot more informative that using the MAC prefix, but maybe I should add that if the other two come back negative. Or maybe it'd be fine to just use lspci output if available, lsusb output if the previous isn't found, and if neither of those pop, just display the driver.

I actually finished swapping the script over to POSIX and switched everything from net-tools/wireless-tools to iproute2/iw. The only thing I have left to do that was included with the original script is to sort the output of the wireless networks by signal strength. It is not nearly as easy without arrays

My next goal is to include the ability to provide a static address, but that's probably the last big to add.

I only suggested nmap because it is a part of a full Slackware installation. Anyway, the hwdata package contains the better option of oui.txt. Nmap just provides a mac address database already parsed out of oui.txt from the IEEE standards site. I only mentioned it from their site because you will likely want to have an updated file for best accuracy. The files on 14.2 are dated from 2016.

The a/hwdata package is included in the installer, so I suppose that could be an option. But since it seems to only provide the manufacturer's name (and sometimes it's not even tied to the actual NIC manufacturer in the case of the Intel ethernet devices on both of my systems showing the motherboard manufacturer), maybe this is a last resort if the others are blank.

I'll look at getting support for this added.

Guys I have to ask... why are so many concerned about wifi connection during install? From my POV wifi is less reliable that a wired connection and even on a wired connection it is prudent to run md5 checksum to insure one's iso is not corrupted during download. Is there a way now to run checksum on wifi data being installed in realtime? If not, how and why would anyone trust that for such a fundamental process?

There are many slim laptops nowadays that lack Ethernet ports, there are some people who only have laptops and rely on Wi-Fi because there is only one cabled router that shares the Internet connection in the flat or house they live in, and I've also worked at a startup where one had to use Wi-Fi because there was no wired connection available in the office.

1 members found this post helpful.

It was a script I felt would be a good exercise for my scripting knowledge. I've learned a lot of extra info on the differences between bash and POSIX, as well as the differences between net-tools/wireless-tools vs iproute2/iw (although, I am still very lacking in knowledge on the latter, but it's improving). I have no idea if this will end up getting used by anybody or if it'll be just another script to sit on my github relatively unused (which I am fine with). I know it is unlikely to be used in an installed version of Slackware as there are plenty of other options that are much more thorough and it can't be automated without modification to the script.

And prior to I.G.O.R.'s ramblings on the forum, I didn't realize that the installer was missing the tools to even connect to a wireless network.

The installer is what would check the packages. I don't know if it checks them when installing from a server. But if the installer has the ability to install from a wired connection, it is not a bad idea to allow a wireless connection. As average_user mentioned, many laptops are now coming without network cables. My desktop sits two floors above my router and I haven't had the desire to cut holes in my walls to run a network cable up there.

There doesn't need to be a script to connect to the network as there isn't a script to connect to a wired network, but it would be nice to have the wireless-tools, iw, and wpa_supplicant packages included in the installer.

1 members found this post helpful.

Well, you got already sound answers from bassmadrigal and average_user, but being the OP I feel compelled to confirm and complete them

As average_user pointed out, many users do not have a wired connection during installation (and some will never have one on the machine on which the system is installed).

Also, having an Internet connection (wired or wireless) at time of installation will allow:

• To install the most recent packages from the inception (the ISOs for Slackware 14.2 are several years old, the one for Slint64.14.2.1.2 is more recent but a lot of packages have been upgraded or added since its release).
• To provide a fully net installation using a very small ISO shipping only the installer.
• To propose a time zone fitting the user's current location with a command like:
  Code:

  proposed_TZ=$(curl ipinfo.io|grep timezone|cut -d'"' -f 4)

• The user to surf the web to find information during installation (just including a lightweight web browser in the installer).

Indeed, the installer can check the authenticity as well as the integrity of the downloaded packages, as long as the mirror used provides the relevant metadata: md5sum, and signature (of each package individually in case of Slackware, of the CHECKSUM.md5.gz file in case of Slint).

@bassmadrigal: you can be sure that I will seriously consider shipping you script in the Slint installer, possibly with a few modifications. I will also certainly ship all needed utilities for wireless connections and more generally software needed as dependencies.

I haven't posted in this thread since a while, however I follow it and am happy and grateful of the work you and others devote to fulfilling my request. Thanks!

@All: to know what makes a shell compliant to POSIX, just read the Shell Command Language. This reading is in order even for the folks using only bash, as "man bash" implicitly assume this background from its readers.

2 members found this post helpful.

To be clear(er) it isn't wifi I'm so concerned about. It's the inability to checksum on-the-fly as opposed to downloading, checking and then transferring to a storage device from which the installer functions and relies upon.

That is not the scope of this project. Very basically, it's to allow for wireless connections as wired connections are already supported. The script is to just simplify connecting to a wireless network since it is a bit harder than a wired. If the installer doesn't check packages for integrity when downloading from a remote source, that would be a good suggestion to add to the requests for -current thread.

1 members found this post helpful.

In case of Slackware it doesn't, it uses wget to get the packages and installpkg to install them. In case of Slint it will, using slapt-get to check both the integrity of each downloaded package and the GPG signature of the file http://slackware.uk/slint/x86_64/sli...ECKSUMS.md5.gz against http://slackware.uk/slint/x86_64/sli...UMS.md5.gz.asc. As slackpkg has the same abilities (with the difference that each package is individually signed in the Slackware repositories, not only the md5 summary), it could be used to do the same checks in the Slackware installer.

1 members found this post helpful.

Thanks again to all who responded, especially but not limited to bassmadrigal.

After much thoughts I ended up writing a script that does not let the user choose the network card if several, but in this cases just scans all of them to find network addresses and SSID. I also chose to use just a command-line UI, not using dialog. This is to make thing easier for blind users, as not all are acquainted with the screen review shortcuts of speakup. I could optionally allow using a dialog box to list the SSID though.

Please test the script as it is and report your findings here. Proposals for enhancements are indeed welcome.

PS There are a few variables that you can set, as indicated in the script itself.

PPS Indeed you can run the script in Slackware version 14.2. It also works here in Slackware64-current up to date as of now, I just checked. No need to first stop a NetworkManager or dhcpd or wpa_supplicant daemon, the script will kill them first. All you'll have to do after having tested is start /etc/rc.d/rc.inet1 or /etc/rc.d/rc.networkmanager. If if after the tests you are connected that's not even necessary. In any case the script won't fiddle at all with your network configuration files, so testing doesn't put your system at risk.