MediaWiki - User contributions [en]

Overview

2026-05-31T17:34:47Z

Rwh: /* NST Wiki World Users */

__TOC__

= Summary =
This Wiki offers a means where users of the '''Network Security Toolkit''' ('''NST''') can ask questions, share experiences, and offer advice in regards to the use of the '''NST''' distribution and the tools which it contains.

The '''NST''' homepage is located at: [http://www.networksecuritytoolkit.org/ http://www.networksecuritytoolkit.org/]. The '''NST''' [http://sourceforge.net/ SourceForge] project page is located at: [http://sourceforge.net/projects/nst http://sourceforge.net/projects/nst]. An '''NST Pro''' version is located at: [http://www.networksecuritytoolkit.org/ http://www.networksecuritytoolkit.org/nstpro]. One can download the current version of '''NST''' [http://sourceforge.net/project/showfiles.php?group_id=85467 '''here''']. A reference about '''NST''' at [http://en.wikipedia.org Wikipedia] can be found [http://en.wikipedia.org/wiki/Network_Security_Toolkit '''here'''].



You can view Webcasts related to '''NST''' on the [[NST Screencasts]] page. This NST Wiki Web site is generated by an "'''NST 44'''" system using '''[http://www.mediawiki.org/wiki/MediaWiki MediaWiki]''' software running on an '''[http://www.intel.com/content/www/us/en/nuc/products-overview.html Intel NUC]'''. The following are some of the IPv4 Address Host geolocation tools available with the toolkit using NST Wiki traffic data as a data source.

= NST Wiki World Users =

The '''Mercator World Map''' projection below depicts geolocated user host systems that have recently accessed the '''NST''' wiki site. The map is updated once an hour using a collection window of 24 hours. The data source is an '''[http://www.ntop.org/products/traffic-analysis/ntop/ ntopng]''' session running on an "'''NST 44'''" probe listening on 2 network interfaces (i.e., '''wikirx''' & '''wikitx''') for packet capture. A '''[https://networkvisibility.com/products/ixia-net-optics-tap-copper-10-100-1g-955-0270-tp-cu3 TP-CU3]''' Non-Aggregational TAP is inserted between the '''NST''' probe and the '''NST''' wiki site providing full-duplex traffic access.

[[File:Curhostswm.png|frame|center|NST Wiki Site World Map: Global Users Host Geolocations]]

The '''NST''' wiki traffic for the last 24 hours is also formatted as a '''KMZ (KML)''' document that can be downloaded and ''viewed'' in '''[http://earth.google.com Google Earth]''': "'''([http://wiki.networksecuritytoolkit.org/nstwiki/maps/curhostskml.kmz KMZ Document - NST Wiki Traffic])'''". Both the '''Mercator World Map''' and the '''KML Document''' above were produced by the '''NST''' script: "'''[http://nst.sourceforge.net/nst/docs/scripts/nstgeolocate.html nstgeolocate]'''". This script is included in the '''NST''' distribution (See the NST Wiki page: '''[http://wiki.networksecuritytoolkit.org/nstwiki/index.php/HowTo_Automate_%26_Manage_NST_Geolocation_Results HowTo Automate & Manage NST Geolocation Results]''' for further information on geolocating network entities with '''NST''').

= NST WebGL Globe =
'''NST''' now includes a '''[https://experiments.withgoogle.com/chrome/globe WebGL Globe'''] implementation for the geolocation of IPv4 Hosts. Each hour new NST Wiki host geolocation traffic data is generated and formatted for '''[https://en.wikipedia.org/wiki/WebGL WebGL] Globe''' usage (i.e. A '''[https://en.wikipedia.org/wiki/JSON JSON]''' formatted document.) which can be ''rendered'' within a web browser producing images similar to the following graphics of the earth. Each red spike represents Host traffic to and from the NST Wiki site derived from an active '''[http://www.ntop.org/products/traffic-analysis/ntop/ ntopng]''' session. Longer spikes indicate greater combined transmit and received network traffic.

<center>[[File:Nstwikiwebglglobe.png|256x256px|frameless|NST Wiki Site Global Traffic (Day Time Map)]]    [[File:Nstwikiwebglglobenight.png|256x256px|frameless|NST Wiki Site Global Traffic (Night Time Map)]]</center>

Use this link to view the '''NST''' Wiki traffic for the past 24 hours as a single series dataset: '''[http://wiki.networksecuritytoolkit.org/nst-webgl-globe/index.html?daymap=true&gdsrc=data/curhostswebgl.json NST Webgl Globe - NST Wiki Traffic]'''

Use this link to view the '''NST''' Wiki traffic as a multi-series dataset for the past 7 hours with a 1 day time interval: '''[http://wiki.networksecuritytoolkit.org/nst-webgl-globe/index.html?daymap=true&gdsrc=data/curwebgldataset.json NST Webgl Globe (Multi-Series Dataset) - NST Wiki Traffic]'''.

The '''NST WebGL Globe''' implementation includes the following features:
* Switch between day time and night time maps.
* Uses a bump map for a realistic earth topography visual.
* Uses a specular map for a realistic sun and moon glint visual.
* Zoom in and out with your mouse scroll control.
* Automatic earth rotation control.
* Configurable selection of the IPv4 Host geolocation data source.
* Manual data spike intensity scale controls.
* The data scale can be dynamically changed between linear and logarithmic.
* A reset button to re-initialize the earth 3D control settings.
* Data can be displayed using either a single series or multi-series dataset.
* All parameters included the initial view location and view distance can be controlled via the '''[https://en.wikipedia.org/wiki/Uniform_resource_locator URL]'''.

The '''NST''' script: "'''[http://nst.sourceforge.net/nst/docs/scripts/nstgeolocate.html nstgeolocate]'''" now includes the ability to produce '''NST WebGL Globe JSON''' documents using '''[http://www.ntop.org/ntopng ntop / ntopng]''' as a data source. The '''NST WUI''' can now ''dynamically'' produce on demand '''NST WebGL Globe JSON''' documents for these data sources.

Overview

2026-05-31T17:34:22Z

Rwh: /* Summary */

__TOC__

= Summary =
This Wiki offers a means where users of the '''Network Security Toolkit''' ('''NST''') can ask questions, share experiences, and offer advice in regards to the use of the '''NST''' distribution and the tools which it contains.

The '''NST''' homepage is located at: [http://www.networksecuritytoolkit.org/ http://www.networksecuritytoolkit.org/]. The '''NST''' [http://sourceforge.net/ SourceForge] project page is located at: [http://sourceforge.net/projects/nst http://sourceforge.net/projects/nst]. An '''NST Pro''' version is located at: [http://www.networksecuritytoolkit.org/ http://www.networksecuritytoolkit.org/nstpro]. One can download the current version of '''NST''' [http://sourceforge.net/project/showfiles.php?group_id=85467 '''here''']. A reference about '''NST''' at [http://en.wikipedia.org Wikipedia] can be found [http://en.wikipedia.org/wiki/Network_Security_Toolkit '''here'''].



You can view Webcasts related to '''NST''' on the [[NST Screencasts]] page. This NST Wiki Web site is generated by an "'''NST 44'''" system using '''[http://www.mediawiki.org/wiki/MediaWiki MediaWiki]''' software running on an '''[http://www.intel.com/content/www/us/en/nuc/products-overview.html Intel NUC]'''. The following are some of the IPv4 Address Host geolocation tools available with the toolkit using NST Wiki traffic data as a data source.

= NST Wiki World Users =

The '''Mercator World Map''' projection below depicts geolocated user host systems that have recently accessed the '''NST''' wiki site. The map is updated once an hour using a collection window of 24 hours. The data source is an '''[http://www.ntop.org/products/traffic-analysis/ntop/ ntopng]''' session running on an "'''NST 40'''" probe listening on 2 network interfaces (i.e., '''wikirx''' & '''wikitx''') for packet capture. A '''[https://networkvisibility.com/products/ixia-net-optics-tap-copper-10-100-1g-955-0270-tp-cu3 TP-CU3]''' Non-Aggregational TAP is inserted between the '''NST''' probe and the '''NST''' wiki site providing full-duplex traffic access.

[[File:Curhostswm.png|frame|center|NST Wiki Site World Map: Global Users Host Geolocations]]

The '''NST''' wiki traffic for the last 24 hours is also formatted as a '''KMZ (KML)''' document that can be downloaded and ''viewed'' in '''[http://earth.google.com Google Earth]''': "'''([http://wiki.networksecuritytoolkit.org/nstwiki/maps/curhostskml.kmz KMZ Document - NST Wiki Traffic])'''". Both the '''Mercator World Map''' and the '''KML Document''' above were produced by the '''NST''' script: "'''[http://nst.sourceforge.net/nst/docs/scripts/nstgeolocate.html nstgeolocate]'''". This script is included in the '''NST''' distribution (See the NST Wiki page: '''[http://wiki.networksecuritytoolkit.org/nstwiki/index.php/HowTo_Automate_%26_Manage_NST_Geolocation_Results HowTo Automate & Manage NST Geolocation Results]''' for further information on geolocating network entities with '''NST''').

= NST WebGL Globe =
'''NST''' now includes a '''[https://experiments.withgoogle.com/chrome/globe WebGL Globe'''] implementation for the geolocation of IPv4 Hosts. Each hour new NST Wiki host geolocation traffic data is generated and formatted for '''[https://en.wikipedia.org/wiki/WebGL WebGL] Globe''' usage (i.e. A '''[https://en.wikipedia.org/wiki/JSON JSON]''' formatted document.) which can be ''rendered'' within a web browser producing images similar to the following graphics of the earth. Each red spike represents Host traffic to and from the NST Wiki site derived from an active '''[http://www.ntop.org/products/traffic-analysis/ntop/ ntopng]''' session. Longer spikes indicate greater combined transmit and received network traffic.

<center>[[File:Nstwikiwebglglobe.png|256x256px|frameless|NST Wiki Site Global Traffic (Day Time Map)]]    [[File:Nstwikiwebglglobenight.png|256x256px|frameless|NST Wiki Site Global Traffic (Night Time Map)]]</center>

Use this link to view the '''NST''' Wiki traffic for the past 24 hours as a single series dataset: '''[http://wiki.networksecuritytoolkit.org/nst-webgl-globe/index.html?daymap=true&gdsrc=data/curhostswebgl.json NST Webgl Globe - NST Wiki Traffic]'''

Use this link to view the '''NST''' Wiki traffic as a multi-series dataset for the past 7 hours with a 1 day time interval: '''[http://wiki.networksecuritytoolkit.org/nst-webgl-globe/index.html?daymap=true&gdsrc=data/curwebgldataset.json NST Webgl Globe (Multi-Series Dataset) - NST Wiki Traffic]'''.

The '''NST WebGL Globe''' implementation includes the following features:
* Switch between day time and night time maps.
* Uses a bump map for a realistic earth topography visual.
* Uses a specular map for a realistic sun and moon glint visual.
* Zoom in and out with your mouse scroll control.
* Automatic earth rotation control.
* Configurable selection of the IPv4 Host geolocation data source.
* Manual data spike intensity scale controls.
* The data scale can be dynamically changed between linear and logarithmic.
* A reset button to re-initialize the earth 3D control settings.
* Data can be displayed using either a single series or multi-series dataset.
* All parameters included the initial view location and view distance can be controlled via the '''[https://en.wikipedia.org/wiki/Uniform_resource_locator URL]'''.

The '''NST''' script: "'''[http://nst.sourceforge.net/nst/docs/scripts/nstgeolocate.html nstgeolocate]'''" now includes the ability to produce '''NST WebGL Globe JSON''' documents using '''[http://www.ntop.org/ntopng ntop / ntopng]''' as a data source. The '''NST WUI''' can now ''dynamically'' produce on demand '''NST WebGL Globe JSON''' documents for these data sources.

Subversion Notes

2026-05-29T01:18:02Z

Rwh: /* Merging From Dev Area To The Repo Area */

We switched from using CVS to Subversion as our source control mechanism in mid October 2009.

* We did not try to import all of the CVS history.
* The initial import includes all of the 2.11.0 release source plus the updated source code since the release (the state of CVS on 2009-10-14).
* We left the CVS repository alone (in case we ever wanted to refer back for older history).

= Preparing Development Machine =

As a developer, the following things must be done to your development machine before you will be able to check out, build and commit changes to the NST source code.

== Set SVNROOT ==

You need to set the ''SVNROOT'' variable. Add the following to your '''~/.bashrc''' or '''~/.bash_profile''' configuration file:

export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst

export SVNROOT=svn+ssh://user@svn.code.sf.net/p/nst/code

After the ''SVNROOT'' variable is set, you should be able to run Subversion commands. For example the following shows the directories under ''SVNROOT''.

[pkb@sprint ~]$ export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst
[pkb@sprint ~]$ svn ls ${SVNROOT}
trunk/
[pkb@sprint ~]$

== gnome-keyring ==

Subversion might complain about needing to store passwords in a ''unencrypted'' form. To prevent this, we need to figure out how to enable the ''gnome-keyring'' add-on. To do this, edit the file '''~/.subversion/config''' and search on the string ''password-stores''. Most likely this will be commented out in your current configuration file. I updated mine to the following:

password-stores = gnome-keyring

However, this was not enough to prevent me from being prompted each time. I then added the following package:

yum install subversion-gnome

We will see if this permits us to store the password or not (you may need to be logged into a GNOME desktop in order to make use of the gnome-keyring feature).

= Directory Structure =

Currently the directory structure under Subversion is fairly straight forward. We use ''dev/FCVer'' (E.g., dev/30) as the current working area (this is what most developers will be checking out from and committing to). The following is the top level directory structure for Development (/dev), Release (/releases) and the pristine repository for pushing out package updates (/repo):

[nst@vortex ~]$ svn ls ${SVNROOT}/
dev/
releases/
repo/

Under each top level directory there are Fedora specific source trees:

[nst@vortex ~]$ svn ls ${SVNROOT}/dev
18/
2.11.0/
2.12.0/
2.13.0/
2.15.0/
2.16.0/
20/
21/
22/
24/
26/
28/
30/
32/

= Subversion Commands =

Use the following to get the list of available subversion commands:

svn help

To get more information about a specific Subversion command (like ''ls''), run:

svn help ls

== Checking Out Code ==

Ex: 1 To make the initial checkout of the current source code into a sub-directory named ''nst'', you can use the following Subversion command:

svn co ${SVNROOT}/trunk nst

Ex: 2 To make the initial checkout of the current development source code into a sub-directory named ''dev42'', you can use the following Subversion command:

svn co ${SVNROOT}/dev/42 dev42

== Committing Code ==

You use the ''commit'' subversion command when you want to commit changes to the source code.

When you first run ''commit'', it may prompt you for the password for the incorrect user ID. If this happens, press the ''Enter'' key without specifying a password. This should allow you enter your SourceForge user ID followed by your SourceForge password when committing changes. For example:

[root@fedora11 nightly]# svn commit
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Password for 'root':
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Username: SOURCEFORGE_LOGIN_ID
Password for 'SOURCEFORGE_LOGIN_ID':
Sending nightly/nightly-build.bash
Sending nightly/nightly2html.xsl
Sending nightly/nightly2txt.xsl
Transmitting file data ...-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

<https://nst.svn.sourceforge.net:443> SourceForge Subversion area

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? no

Committed revision 4.
[root@fedora11 nightly]#

== Status ==

The Subversion status command is very handy at showing not only what files you've modified, but also (when including the ''-u'' option) handy at showing what files have changed in the repository:

svn status -u

For help about the output of ''svn status'', run:

svn help status | less

== Revert ==

If you've made modifications to a file which you want to discard, use the ''revert'' command to restore the original version:

svn revert FILENAME

To revert back to a previous revision use the '''merge''' option. The follow example reverts back to the '''3986''' revision from the '''3987''' revision for file: "'''bwmonitor.js'''". After the revert changes are applied you will need to '''commit'''. Use the [http://nst.svn.sourceforge.net/viewvc/nst/ Subversion Browser] to assit in finding your revision numbers.

svn merge -r 3987:3986 bwmonitor.js

== Revert Commit, Undo Commit, Reverse Merge ==

If you've committed modifications to a file accidentally it is a bit tricky to ''undo'' the commit. To get back an older version you need to perform something called a reverse merge. This is done by running the ''svn merge -r BAD:GOOD SOURCE'' command. Where BAD is typically the current revision ID of the source you want to revert, GOOD is the revision ID of the good code you want to restore and is typically 1 less than the value of BAD. SOURCE is typically the name of the file or directory you want to undo the commit on.

For example, we can used the following command to determine the last changed revision of the files under the current directory:

[pkb@refritos server]$ svn info . | grep Rev:
Last Changed Rev: 10660
[pkb@refritos server]$

In this example the BAD revision ID is 10660 associated with the last commit done to this area. To restore the files to the 10659 state (the good version prior to the 10660) state, we would run the following command:

[pkb@refritos server]$ svn merge -r 10660:10659 .
--- Reverse-merging r10660 into '.':
U xrdp.cgi
--- Recording mergeinfo for reverse merge of r10660 into '.':
G .
--- Eliding mergeinfo from '.':
U .
[pkb@refritos server]$

As the ''status'' command shows, this undo only impacted one file in the directory and is not immediately reflected in the repository.

[pkb@refritos server]$ svn status
M xrdp.cgi
[pkb@refritos server]$

This allows us to inspect the undone changes. If we are happy, we can commit this version back. If we are unhappy with the results, we can revert the state of the directory and try again.

== Ignoring Files ==

Under CVS, you could edit the file '''.cvsignore''' to tell CVS to ignore certain files within the directory. Subversion has a similar, but different mechanism for ignoring files. Basically, you change to the directory where the files/directories to be ignored exist and run the following command:

svn propedit svn:ignore .

Running the above command should pull up a text editor and allow you to specify file name patterns to specify what files and directories should be ignored. Here is an example ignore list which causes Subversion to ignore any file or directory ending with the extension ''.log'' or having the name ''tmp'':

*.log
tmp

== Manage The Executable Flag On File ==
Use the following command to set the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propset svn:executable bwmonitor-ajax.php

Use the following command to remove the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propdel svn:executable bwmonitor-ajax.php

== Merging Changes Across Revisions ==

Our general strategy is typically to do all new work under the ''trunk'' area. However, when we move from one Fedora platform to another (like from Fedora 13 to Fedora 15), we will typically copy the ''trunk'' area to a sub-directory under the maintenance area. For example, the following shows the top level Subversion heirarchy (where you will see ''trunk'' and ''maintenance'') and the number of older maintenance areas where we have the ability to maintain older versions of the software.

[root@f13-32 ~]# svn ls $SVNROOT
maintenance/
releases/
trunk/
[root@f13-32 ~]# svn ls $SVNROOT/maintenance
2.11.0/
2.12.0/
2.13.0/
[root@f13-32 ~]#

In this situation, you may find yourself making changes to the ''trunk'' area that you would also like to apply to the ''2.13.0'' branch area. To accomplish this, use the following strategy:

* Make your updates to the ''trunk'' area.
* Commit your changes.
* Determine the range of revision numbers for your change using the [http://nst.svn.sourceforge.net/viewvc/nst/ Subversion browser].
* Use the ''svn merge'' command to merge the changes into the ''maintenance/2.13.0'' area.

Here is an example of using ''svn merge'' to merge the changes made for the 2.1.6 release of the relaycheck package from the ''trunk'' area to the ''maintenance/2.13.0'' area:

* From looking at the [http://nst.svn.sourceforge.net/viewvc/nst/maintenance/2.13.0/yum/pkgs maintenance/2.13.0/yum/pkgs/relaycheck revision number], I can see that the last revision number for the ''maintenance/2.13.0'' version was 2016 (at the time of this writing - it will change in the future).
* From looking at the [http://nst.svn.sourceforge.net/viewvc/nst/trunk/yum/pkgs trunk/yum/pkgs/relaycheck revision number], I can see that the current revision number for the ''trunk'' version of relaycheck was 2102 (at the time this article was written).
* At this point I have enough information to merge the changes with the following ''svn merge'' command:

[root@f13-32 repo]# svn info
Path: .
URL: https://nst.svn.sourceforge.net/svnroot/nst/maintenance/2.13.0
Repository Root: https://nst.svn.sourceforge.net/svnroot/nst
Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586
Revision: 2076
Node Kind: directory
Schedule: normal
Last Changed Author: pblankenbaker
Last Changed Rev: 2076
Last Changed Date: 2011-05-10 16:53:57 -0400 (Tue, 10 May 2011)

[root@f13-32 repo]# svn merge -r 2016:2102 $SVNROOT/trunk/yum/pkgs/relaycheck yum/pkgs/relaycheck
--- Merging r2076 through r2102 into 'yum/pkgs/relaycheck':
U yum/pkgs/relaycheck/src/relaycheck.pl
U yum/pkgs/relaycheck/pkginfo.xml
U yum/pkgs/relaycheck/relaycheck.template.spec
[root@f13-32 repo]# svn status
M yum/pkgs/relaycheck
M yum/pkgs/relaycheck/src/relaycheck.pl
M yum/pkgs/relaycheck/pkginfo.xml
M yum/pkgs/relaycheck/relaycheck.template.spec
[root@f13-32 repo]#

At this point, we should make sure the merged changes still build and then commit our changes.

NOTE: After committing the changes, the [http://nst.svn.sourceforge.net/viewvc/nst/maintenance/2.13.0/yum/pkgs maintenance/2.13.0/yum/pkgs/relaycheck revision number] changed to 2103 (at the time of this writing) which is now larger than the original 2102 revision we used for the merge.
[root@f13-32 repo]# cd yum
[root@f13-32 yum]# make relaycheck

... Omitted much of the output ...

-------------------------------------------------------------------------------
SUCCESS: Successfully installed relaycheck-1.2.6-11.nst13.noarch.rpm
-------------------------------------------------------------------------------
make[1]: Leaving directory `/root/repo/yum/pkgs/relaycheck'
[root@f13-32 yum]# svn commit

== Merging From Dev Area To The Repo Area ==

* '''Note:''' If this merge includes updates in the '''nstwui''' package: '''Have You Updated The NST WUI Release Number On The Dev Branch First?'''

The following demonstrates the current merge method to bring changes from the ''dev/20'' development branch to the ''repo/20'' area.

[root@dev20-64 ~]# cd repo
[root@dev20-64 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
[root@dev20-64 repo]# svn info
Path: .
Working Copy Root Path: /root/repo
URL: https://svn.code.sf.net/p/nst/code/repo/20
Relative URL: ^/repo/20
Repository Root: https://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 6545
Node Kind: directory
Schedule: normal
Last Changed Author: rwhalb
Last Changed Rev: 6545
Last Changed Date: 2015-02-14 08:44:42 -0500 (Sat, 14 Feb 2015)

[root@dev20-64 repo]# svn update; svn merge https://svn.code.sf.net/p/nst/code/dev/20 .
At revision 6594.
--- Merging r6545 through r6594 into '.':
U include/javascript/core/NstSelect.js
U include/javascript/core/NstRuler.js

...

U yum/pkgs/putty-win32
--- Recording mergeinfo for merge of r6545 through r6594 into '.':
U .
--- Recording mergeinfo for merge of r6545 through r6594 into 'yum/pkgs/putty-win32':
G yum/pkgs/putty-win32
[root@dev20-64 repo]# svn commit -m "Merging up to 6545 from dev/20"
... output from commit ...
[root@dev20-64 repo]#

Method for a svn user: '''svnuser''' setup: (Note: substitute the name "'''user'''" with your Subversion user name.
export SVNROOT="svn+ssh://user@svn.code.sf.net/p/nst/code";
alias svnuser='svn --username user';
svnuser update; svnuser merge ${SVNROOT}/dev/44
svnuser commit -m "Merging dev 44 area into repo 44 through r15094";

This is the old method used for merging and updating the '''Trunk Area''' with code changes in the '''Development 18 Area''' spanning from revision: "''''4869'''" to the "'''HEAD (4877)'''" (latest changes committed to the ''dev/18'' area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst

[root@dev16-32 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
[root@dev16-32 repo]# svn proplist
Properties on '.':
svn:mergeinfo
svn:ignore
[root@dev16-32 repo]# svn propget svn:mergeinfo
/dev:4409-4503,4516-4793
/dev/18:4795-4869
/maintenance/18:4794
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@dev16-32 repo]# svn merge -r 4869:HEAD ${SVNROOT}/dev/18 .
[root@dev16-32 repo]# svn propget svn:mergeinfo
/dev:3590,3592-3611,3613-3614,3616,3618-3620,3622,3624-3627,3629-3702
[root@dev16-32 repo]# svn status -u
... shows files that were updated by the merge ...
[root@dev16-32 repo]# svn commit -m "Merging up to 4877 from dev/18 - new release of the NST WUI"
... output from commit ...
[root@dev16-32 repo]#

== Merging From ''repo'' To ''dev'' Area ==

The easy method for merging the ''repo'' area changes into your ''dev'' area:

* Make sure all code is committed and everything is up to date.
* Set SVNROOT to point to the top level directory (like: https://svn.code.sf.net/p/nst/code).
* Run the merge command as shown below:

[pkb@chimi dev]$ svn merge $SVNROOT/repo/22 .
--- Merging differences between repository URLs into '.':
U include/dist/release-notes.txt
U include/manifest/current.xml
A include/manifest/release-22-7248.xml
U include/data/configure.in
U html/include/make/makefile
U html/links.html
U html/side.html
U html/welcome.html
U html/README.html
U src/scripts/nstmenu/share/groups/release.group.xml
U src/scripts/nstmenu/share/applications/release.apps.xml
U yum/pkgs/nstmenu/template.spec
U yum/pkgs/nstmenu/pkginfo.xml
U yum/pkgs/nstweb/template.spec
U yum/pkgs/nstweb/pkginfo.xml
U .
--- Recording mergeinfo for merge between repository URLs into '.':
U .
[pkb@chimi dev]$

The following demonstrates an older technique that merges the '''Development Area''' with code changes in the '''Repo Area''' spanning from revision: "''''6534''" to "'''HEAD (6537)'''".

'''On repo:'''
[root@vortex repo]# svn propget svn:mergeinfo
/dev:4409-4503,4516-4793
/dev/18:4795-5411,5419-5496
/dev/20:5419-5501,5503-6533
/maintenance/18:4794
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex repo]#

'''On Dev:'''
[root@vortex dev]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
Status against revision: 6533
[root@vortex dev]# svn merge -r 6534:HEAD ${SVNROOT}/repo .
[root@vortex dev]# svn propget svn:mergeinfo
/dev/18:5419-5496
/repo:4494,4505-4514,4516-4551,4555-4568,4586-4587,4614,4695,4717,4781,4812,5413-5415,5662-5666,6535-6537
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex dev]# svn status -u
... shows files that were updated by the merge ...
[root@vortex dev]# svn commit -m "Merging up to 6537 from repo for new release"
... output from commit ...
[root@vortex dev]#

== Switching To A New Root ==

There can be many different branches of the same source tree at different levels of development within the Subversion repository. You can use the ''switch'' command to switch from one branch to another. When making a switch, the source code you have checked out will be updated to match the state of the source code in the new branch. Before making a switch, it is important to make sure that all of your changes are checked into the current branch. For example, the following demonstrates how to switch to the ''dev'' branch from the ''trunk'' branch:

[root@taco-dev32 repo]# svn info
Path: .
Working Copy Root Path: /root/repo
URL: https://svn.code.sf.net/p/nst/code/repo
Relative URL: ^/repo
Repository Root: https://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 6540
Node Kind: directory
Schedule: normal
Last Changed Author: rwhalb
Last Changed Rev: 6540
Last Changed Date: 2015-02-09 13:57:38 -0500 (Mon, 09 Feb 2015)

[root@taco-dev32 repo]# export SVNROOT="$(svn info | awk -- '$2 == "Root:" { print $3; }')";
[root@taco-dev32 repo]# echo $SVNROOT
https://svn.code.sf.net/p/nst/code
[root@taco-dev32 repo]# svn switch $SVNROOT/dev/20
At revision 3577.
[root@taco-dev32 repo]#

After making a switch, you can use the ''info'' command to verify the switch was successful.

[root@taco-dev32 repo]# svn info
Path: .
URL: https://nst.svn.sourceforge.net/svnroot/nst/dev
Repository Root: https://nst.svn.sourceforge.net/svnroot/nst
Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586
Revision: 3577
Node Kind: directory
Schedule: normal
Last Changed Author: jdoe
Last Changed Rev: 3577
Last Changed Date: 2012-05-29 10:04:54 -0400 (Tue, 29 May 2012)

[root@taco-dev32 repo]#

== Relocate To A New Repository Root ==

This section demonstrates switching repository root from one URL to another. In this example we switch from "'''http://svn.code.sf.net/p/nst/code'''" to "'''svn+ssh://USERID@svn.code.sf.net/p/nst/code'''". The svn "'''relocate'''" command is used.

[root@vortex dev]# svn info;
Path: .
Working Copy Root Path: /root/dev
URL: http://svn.code.sf.net/p/nst/code/dev/26
Relative URL: ^/dev/26
Repository Root: http://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 9274
Node Kind: directory
Schedule: normal
Last Changed Author: user
Last Changed Rev: 9274
Last Changed Date: 2017-10-11 16:07:51 -0400 (Wed, 11 Oct 2017)
[root@vortex dev]#
[root@vortex dev]# svn --username USERID relocate http://svn.code.sf.net/p/nst/code svn+ssh://USERID@svn.code.sf.net/p/nst/code;

== Switching User Repository Root ==
Use this subversion method to switch the "'''Repository Root'''" user from "'''USERID1'''" to "'''USERID2'''":
svn relocate svn+ssh://USERID1@svn.code.sf.net/p/nst/code/dev/38 svn+ssh://USERID2@svn.code.sf.net/p/nst/code/dev/38;

= New NST Release Setup =

Currently the directory structure under Subversion is fairly straight forward. As an example we use ''dev/30'' when working on Fedora 30 based builds. To move to Fedora 32 we do the following:

svn copy ${SVNROOT}/dev/30 ${SVNROOT}/dev/32;

When we are ready to push out a release we want to create our pristine repository area:

svn copy ${SVNROOT}/dev/32 ${SVNROOT}/repo/32;

= Related Links =

; http://nst.svn.sourceforge.net/viewvc/nst
: Use this link to browse the NST Subversion repository (the 'trunk' folder corresponds to the current development tree).

Subversion Notes

2026-05-29T01:17:16Z

Rwh: /* Merging From Dev Area To The Repo Area */

We switched from using CVS to Subversion as our source control mechanism in mid October 2009.

* We did not try to import all of the CVS history.
* The initial import includes all of the 2.11.0 release source plus the updated source code since the release (the state of CVS on 2009-10-14).
* We left the CVS repository alone (in case we ever wanted to refer back for older history).

= Preparing Development Machine =

As a developer, the following things must be done to your development machine before you will be able to check out, build and commit changes to the NST source code.

== Set SVNROOT ==

You need to set the ''SVNROOT'' variable. Add the following to your '''~/.bashrc''' or '''~/.bash_profile''' configuration file:

export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst

export SVNROOT=svn+ssh://user@svn.code.sf.net/p/nst/code

After the ''SVNROOT'' variable is set, you should be able to run Subversion commands. For example the following shows the directories under ''SVNROOT''.

[pkb@sprint ~]$ export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst
[pkb@sprint ~]$ svn ls ${SVNROOT}
trunk/
[pkb@sprint ~]$

== gnome-keyring ==

Subversion might complain about needing to store passwords in a ''unencrypted'' form. To prevent this, we need to figure out how to enable the ''gnome-keyring'' add-on. To do this, edit the file '''~/.subversion/config''' and search on the string ''password-stores''. Most likely this will be commented out in your current configuration file. I updated mine to the following:

password-stores = gnome-keyring

However, this was not enough to prevent me from being prompted each time. I then added the following package:

yum install subversion-gnome

We will see if this permits us to store the password or not (you may need to be logged into a GNOME desktop in order to make use of the gnome-keyring feature).

= Directory Structure =

Currently the directory structure under Subversion is fairly straight forward. We use ''dev/FCVer'' (E.g., dev/30) as the current working area (this is what most developers will be checking out from and committing to). The following is the top level directory structure for Development (/dev), Release (/releases) and the pristine repository for pushing out package updates (/repo):

[nst@vortex ~]$ svn ls ${SVNROOT}/
dev/
releases/
repo/

Under each top level directory there are Fedora specific source trees:

[nst@vortex ~]$ svn ls ${SVNROOT}/dev
18/
2.11.0/
2.12.0/
2.13.0/
2.15.0/
2.16.0/
20/
21/
22/
24/
26/
28/
30/
32/

= Subversion Commands =

Use the following to get the list of available subversion commands:

svn help

To get more information about a specific Subversion command (like ''ls''), run:

svn help ls

== Checking Out Code ==

Ex: 1 To make the initial checkout of the current source code into a sub-directory named ''nst'', you can use the following Subversion command:

svn co ${SVNROOT}/trunk nst

Ex: 2 To make the initial checkout of the current development source code into a sub-directory named ''dev42'', you can use the following Subversion command:

svn co ${SVNROOT}/dev/42 dev42

== Committing Code ==

You use the ''commit'' subversion command when you want to commit changes to the source code.

When you first run ''commit'', it may prompt you for the password for the incorrect user ID. If this happens, press the ''Enter'' key without specifying a password. This should allow you enter your SourceForge user ID followed by your SourceForge password when committing changes. For example:

[root@fedora11 nightly]# svn commit
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Password for 'root':
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Username: SOURCEFORGE_LOGIN_ID
Password for 'SOURCEFORGE_LOGIN_ID':
Sending nightly/nightly-build.bash
Sending nightly/nightly2html.xsl
Sending nightly/nightly2txt.xsl
Transmitting file data ...-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

<https://nst.svn.sourceforge.net:443> SourceForge Subversion area

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? no

Committed revision 4.
[root@fedora11 nightly]#

== Status ==

The Subversion status command is very handy at showing not only what files you've modified, but also (when including the ''-u'' option) handy at showing what files have changed in the repository:

svn status -u

For help about the output of ''svn status'', run:

svn help status | less

== Revert ==

If you've made modifications to a file which you want to discard, use the ''revert'' command to restore the original version:

svn revert FILENAME

To revert back to a previous revision use the '''merge''' option. The follow example reverts back to the '''3986''' revision from the '''3987''' revision for file: "'''bwmonitor.js'''". After the revert changes are applied you will need to '''commit'''. Use the [http://nst.svn.sourceforge.net/viewvc/nst/ Subversion Browser] to assit in finding your revision numbers.

svn merge -r 3987:3986 bwmonitor.js

== Revert Commit, Undo Commit, Reverse Merge ==

If you've committed modifications to a file accidentally it is a bit tricky to ''undo'' the commit. To get back an older version you need to perform something called a reverse merge. This is done by running the ''svn merge -r BAD:GOOD SOURCE'' command. Where BAD is typically the current revision ID of the source you want to revert, GOOD is the revision ID of the good code you want to restore and is typically 1 less than the value of BAD. SOURCE is typically the name of the file or directory you want to undo the commit on.

For example, we can used the following command to determine the last changed revision of the files under the current directory:

[pkb@refritos server]$ svn info . | grep Rev:
Last Changed Rev: 10660
[pkb@refritos server]$

In this example the BAD revision ID is 10660 associated with the last commit done to this area. To restore the files to the 10659 state (the good version prior to the 10660) state, we would run the following command:

[pkb@refritos server]$ svn merge -r 10660:10659 .
--- Reverse-merging r10660 into '.':
U xrdp.cgi
--- Recording mergeinfo for reverse merge of r10660 into '.':
G .
--- Eliding mergeinfo from '.':
U .
[pkb@refritos server]$

As the ''status'' command shows, this undo only impacted one file in the directory and is not immediately reflected in the repository.

[pkb@refritos server]$ svn status
M xrdp.cgi
[pkb@refritos server]$

This allows us to inspect the undone changes. If we are happy, we can commit this version back. If we are unhappy with the results, we can revert the state of the directory and try again.

== Ignoring Files ==

Under CVS, you could edit the file '''.cvsignore''' to tell CVS to ignore certain files within the directory. Subversion has a similar, but different mechanism for ignoring files. Basically, you change to the directory where the files/directories to be ignored exist and run the following command:

svn propedit svn:ignore .

Running the above command should pull up a text editor and allow you to specify file name patterns to specify what files and directories should be ignored. Here is an example ignore list which causes Subversion to ignore any file or directory ending with the extension ''.log'' or having the name ''tmp'':

*.log
tmp

== Manage The Executable Flag On File ==
Use the following command to set the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propset svn:executable bwmonitor-ajax.php

Use the following command to remove the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propdel svn:executable bwmonitor-ajax.php

== Merging Changes Across Revisions ==

Our general strategy is typically to do all new work under the ''trunk'' area. However, when we move from one Fedora platform to another (like from Fedora 13 to Fedora 15), we will typically copy the ''trunk'' area to a sub-directory under the maintenance area. For example, the following shows the top level Subversion heirarchy (where you will see ''trunk'' and ''maintenance'') and the number of older maintenance areas where we have the ability to maintain older versions of the software.

[root@f13-32 ~]# svn ls $SVNROOT
maintenance/
releases/
trunk/
[root@f13-32 ~]# svn ls $SVNROOT/maintenance
2.11.0/
2.12.0/
2.13.0/
[root@f13-32 ~]#

In this situation, you may find yourself making changes to the ''trunk'' area that you would also like to apply to the ''2.13.0'' branch area. To accomplish this, use the following strategy:

* Make your updates to the ''trunk'' area.
* Commit your changes.
* Determine the range of revision numbers for your change using the [http://nst.svn.sourceforge.net/viewvc/nst/ Subversion browser].
* Use the ''svn merge'' command to merge the changes into the ''maintenance/2.13.0'' area.

Here is an example of using ''svn merge'' to merge the changes made for the 2.1.6 release of the relaycheck package from the ''trunk'' area to the ''maintenance/2.13.0'' area:

* From looking at the [http://nst.svn.sourceforge.net/viewvc/nst/maintenance/2.13.0/yum/pkgs maintenance/2.13.0/yum/pkgs/relaycheck revision number], I can see that the last revision number for the ''maintenance/2.13.0'' version was 2016 (at the time of this writing - it will change in the future).
* From looking at the [http://nst.svn.sourceforge.net/viewvc/nst/trunk/yum/pkgs trunk/yum/pkgs/relaycheck revision number], I can see that the current revision number for the ''trunk'' version of relaycheck was 2102 (at the time this article was written).
* At this point I have enough information to merge the changes with the following ''svn merge'' command:

[root@f13-32 repo]# svn info
Path: .
URL: https://nst.svn.sourceforge.net/svnroot/nst/maintenance/2.13.0
Repository Root: https://nst.svn.sourceforge.net/svnroot/nst
Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586
Revision: 2076
Node Kind: directory
Schedule: normal
Last Changed Author: pblankenbaker
Last Changed Rev: 2076
Last Changed Date: 2011-05-10 16:53:57 -0400 (Tue, 10 May 2011)

[root@f13-32 repo]# svn merge -r 2016:2102 $SVNROOT/trunk/yum/pkgs/relaycheck yum/pkgs/relaycheck
--- Merging r2076 through r2102 into 'yum/pkgs/relaycheck':
U yum/pkgs/relaycheck/src/relaycheck.pl
U yum/pkgs/relaycheck/pkginfo.xml
U yum/pkgs/relaycheck/relaycheck.template.spec
[root@f13-32 repo]# svn status
M yum/pkgs/relaycheck
M yum/pkgs/relaycheck/src/relaycheck.pl
M yum/pkgs/relaycheck/pkginfo.xml
M yum/pkgs/relaycheck/relaycheck.template.spec
[root@f13-32 repo]#

At this point, we should make sure the merged changes still build and then commit our changes.

NOTE: After committing the changes, the [http://nst.svn.sourceforge.net/viewvc/nst/maintenance/2.13.0/yum/pkgs maintenance/2.13.0/yum/pkgs/relaycheck revision number] changed to 2103 (at the time of this writing) which is now larger than the original 2102 revision we used for the merge.
[root@f13-32 repo]# cd yum
[root@f13-32 yum]# make relaycheck

... Omitted much of the output ...

-------------------------------------------------------------------------------
SUCCESS: Successfully installed relaycheck-1.2.6-11.nst13.noarch.rpm
-------------------------------------------------------------------------------
make[1]: Leaving directory `/root/repo/yum/pkgs/relaycheck'
[root@f13-32 yum]# svn commit

== Merging From Dev Area To The Repo Area ==

* '''Note:''' If this merge includes updates in the '''nstwui''' package: '''Have You Updated The NST WUI Release Number On The Dev Branch First?'''

The following demonstrates the current merge method to bring changes from the ''dev/20'' development branch to the ''repo/20'' area.

[root@dev20-64 ~]# cd repo
[root@dev20-64 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
[root@dev20-64 repo]# svn info
Path: .
Working Copy Root Path: /root/repo
URL: https://svn.code.sf.net/p/nst/code/repo/20
Relative URL: ^/repo/20
Repository Root: https://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 6545
Node Kind: directory
Schedule: normal
Last Changed Author: rwhalb
Last Changed Rev: 6545
Last Changed Date: 2015-02-14 08:44:42 -0500 (Sat, 14 Feb 2015)

[root@dev20-64 repo]# svn update; svn merge https://svn.code.sf.net/p/nst/code/dev/20 .
At revision 6594.
--- Merging r6545 through r6594 into '.':
U include/javascript/core/NstSelect.js
U include/javascript/core/NstRuler.js

...

U yum/pkgs/putty-win32
--- Recording mergeinfo for merge of r6545 through r6594 into '.':
U .
--- Recording mergeinfo for merge of r6545 through r6594 into 'yum/pkgs/putty-win32':
G yum/pkgs/putty-win32
[root@dev20-64 repo]# svn commit -m "Merging up to 6545 from dev/20"
... output from commit ...
[root@dev20-64 repo]#

Method for a svn user: '''svnuser''' setup: (Note: substitute the name "'''user'''" with your Subversion user name.
export SVNROOT="svn+ssh://user@svn.code.sf.net/p/nst/code";
alias svnuser='svn --username user';
svnuser update; svnuser merge ${SVNROOT}/dev/36
svnuser commit -m "Merging dev 36 area into repo 36 through r13374";

This is the old method used for merging and updating the '''Trunk Area''' with code changes in the '''Development 18 Area''' spanning from revision: "''''4869'''" to the "'''HEAD (4877)'''" (latest changes committed to the ''dev/18'' area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst

[root@dev16-32 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
[root@dev16-32 repo]# svn proplist
Properties on '.':
svn:mergeinfo
svn:ignore
[root@dev16-32 repo]# svn propget svn:mergeinfo
/dev:4409-4503,4516-4793
/dev/18:4795-4869
/maintenance/18:4794
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@dev16-32 repo]# svn merge -r 4869:HEAD ${SVNROOT}/dev/18 .
[root@dev16-32 repo]# svn propget svn:mergeinfo
/dev:3590,3592-3611,3613-3614,3616,3618-3620,3622,3624-3627,3629-3702
[root@dev16-32 repo]# svn status -u
... shows files that were updated by the merge ...
[root@dev16-32 repo]# svn commit -m "Merging up to 4877 from dev/18 - new release of the NST WUI"
... output from commit ...
[root@dev16-32 repo]#

== Merging From ''repo'' To ''dev'' Area ==

The easy method for merging the ''repo'' area changes into your ''dev'' area:

* Make sure all code is committed and everything is up to date.
* Set SVNROOT to point to the top level directory (like: https://svn.code.sf.net/p/nst/code).
* Run the merge command as shown below:

[pkb@chimi dev]$ svn merge $SVNROOT/repo/22 .
--- Merging differences between repository URLs into '.':
U include/dist/release-notes.txt
U include/manifest/current.xml
A include/manifest/release-22-7248.xml
U include/data/configure.in
U html/include/make/makefile
U html/links.html
U html/side.html
U html/welcome.html
U html/README.html
U src/scripts/nstmenu/share/groups/release.group.xml
U src/scripts/nstmenu/share/applications/release.apps.xml
U yum/pkgs/nstmenu/template.spec
U yum/pkgs/nstmenu/pkginfo.xml
U yum/pkgs/nstweb/template.spec
U yum/pkgs/nstweb/pkginfo.xml
U .
--- Recording mergeinfo for merge between repository URLs into '.':
U .
[pkb@chimi dev]$

The following demonstrates an older technique that merges the '''Development Area''' with code changes in the '''Repo Area''' spanning from revision: "''''6534''" to "'''HEAD (6537)'''".

'''On repo:'''
[root@vortex repo]# svn propget svn:mergeinfo
/dev:4409-4503,4516-4793
/dev/18:4795-5411,5419-5496
/dev/20:5419-5501,5503-6533
/maintenance/18:4794
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex repo]#

'''On Dev:'''
[root@vortex dev]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST!
Status against revision: 6533
[root@vortex dev]# svn merge -r 6534:HEAD ${SVNROOT}/repo .
[root@vortex dev]# svn propget svn:mergeinfo
/dev/18:5419-5496
/repo:4494,4505-4514,4516-4551,4555-4568,4586-4587,4614,4695,4717,4781,4812,5413-5415,5662-5666,6535-6537
/trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex dev]# svn status -u
... shows files that were updated by the merge ...
[root@vortex dev]# svn commit -m "Merging up to 6537 from repo for new release"
... output from commit ...
[root@vortex dev]#

== Switching To A New Root ==

There can be many different branches of the same source tree at different levels of development within the Subversion repository. You can use the ''switch'' command to switch from one branch to another. When making a switch, the source code you have checked out will be updated to match the state of the source code in the new branch. Before making a switch, it is important to make sure that all of your changes are checked into the current branch. For example, the following demonstrates how to switch to the ''dev'' branch from the ''trunk'' branch:

[root@taco-dev32 repo]# svn info
Path: .
Working Copy Root Path: /root/repo
URL: https://svn.code.sf.net/p/nst/code/repo
Relative URL: ^/repo
Repository Root: https://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 6540
Node Kind: directory
Schedule: normal
Last Changed Author: rwhalb
Last Changed Rev: 6540
Last Changed Date: 2015-02-09 13:57:38 -0500 (Mon, 09 Feb 2015)

[root@taco-dev32 repo]# export SVNROOT="$(svn info | awk -- '$2 == "Root:" { print $3; }')";
[root@taco-dev32 repo]# echo $SVNROOT
https://svn.code.sf.net/p/nst/code
[root@taco-dev32 repo]# svn switch $SVNROOT/dev/20
At revision 3577.
[root@taco-dev32 repo]#

After making a switch, you can use the ''info'' command to verify the switch was successful.

[root@taco-dev32 repo]# svn info
Path: .
URL: https://nst.svn.sourceforge.net/svnroot/nst/dev
Repository Root: https://nst.svn.sourceforge.net/svnroot/nst
Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586
Revision: 3577
Node Kind: directory
Schedule: normal
Last Changed Author: jdoe
Last Changed Rev: 3577
Last Changed Date: 2012-05-29 10:04:54 -0400 (Tue, 29 May 2012)

[root@taco-dev32 repo]#

== Relocate To A New Repository Root ==

This section demonstrates switching repository root from one URL to another. In this example we switch from "'''http://svn.code.sf.net/p/nst/code'''" to "'''svn+ssh://USERID@svn.code.sf.net/p/nst/code'''". The svn "'''relocate'''" command is used.

[root@vortex dev]# svn info;
Path: .
Working Copy Root Path: /root/dev
URL: http://svn.code.sf.net/p/nst/code/dev/26
Relative URL: ^/dev/26
Repository Root: http://svn.code.sf.net/p/nst/code
Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c
Revision: 9274
Node Kind: directory
Schedule: normal
Last Changed Author: user
Last Changed Rev: 9274
Last Changed Date: 2017-10-11 16:07:51 -0400 (Wed, 11 Oct 2017)
[root@vortex dev]#
[root@vortex dev]# svn --username USERID relocate http://svn.code.sf.net/p/nst/code svn+ssh://USERID@svn.code.sf.net/p/nst/code;

== Switching User Repository Root ==
Use this subversion method to switch the "'''Repository Root'''" user from "'''USERID1'''" to "'''USERID2'''":
svn relocate svn+ssh://USERID1@svn.code.sf.net/p/nst/code/dev/38 svn+ssh://USERID2@svn.code.sf.net/p/nst/code/dev/38;

= New NST Release Setup =

Currently the directory structure under Subversion is fairly straight forward. As an example we use ''dev/30'' when working on Fedora 30 based builds. To move to Fedora 32 we do the following:

svn copy ${SVNROOT}/dev/30 ${SVNROOT}/dev/32;

When we are ready to push out a release we want to create our pristine repository area:

svn copy ${SVNROOT}/dev/32 ${SVNROOT}/repo/32;

= Related Links =

; http://nst.svn.sourceforge.net/viewvc/nst
: Use this link to browse the NST Subversion repository (the 'trunk' folder corresponds to the current development tree).

Wireless

2026-04-15T15:36:32Z

Rwh: /* Broadcom Chipset Discovery */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network;
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci | rg Network;
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Driver Installation ==
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;
[nst@nst44-mbp ~]$ sudo systemctl reboot;

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:36:19Z

Rwh: /* Broadcom Chipset Discovery */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Driver Installation ==
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;
[nst@nst44-mbp ~]$ sudo systemctl reboot;

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:35:47Z

Rwh: /* Driver Installation = */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Driver Installation ==
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;
[nst@nst44-mbp ~]$ sudo systemctl reboot;

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:35:21Z

Rwh: /* Driver Installation = */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Driver Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;
[nst@nst44-mbp ~]$ sudo systemctl reboot;

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:33:52Z

Rwh: /* Installation = */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Driver Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:33:36Z

Rwh: /* Discovery */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Broadcom Chipset Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:33:14Z

Rwh: /* Recommended */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended Driver ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:32:47Z

Rwh: /* Discovery */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Discovery ==
First determine which Broadcom Chipset you have:

Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:32:30Z

Rwh: /* Discovery */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Discovery ==
First determine which Broadcom Chipset you have:
Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:32:06Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

== Discovery ==
* First determine which Broadcom Chipset you have:
Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

== Recommended ==
* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

== Installation ===
To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T15:30:39Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* First determine which Broadcom Chipset you have:
Example: 1 (BCM4360)
[root@nst44-mbp ~]# lspci | rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03)

Example: 2 (BCM43602)
[root@ccii-nst42 ~]# lspci|rg Network
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 01)

* BCM4360 (many 2013–2015 models) → broadcom-wl
* BCM43224 / BCM4331 etc. → broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) Use the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T13:31:52Z

Rwh:

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T13:30:47Z

Rwh: /* Broadcom Modules Descriptions */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ nmcli radio wifi on;

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T13:28:57Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

== Enable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi on;

== Disable WiFi using nmcli ==
[nst@nst44-mbp ~]$ sudo nmcli radio wifi off;

Wireless

2026-04-15T12:25:33Z

Rwh: /* Broadcom Modules Descriptions */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (Optional) — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

Wireless

2026-04-15T12:25:10Z

Rwh: /* Broadcom Modules Descriptions */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl — A metapackage that pulls in a pre-built module for the newest kernel.
* akmods — The build tool itself (and kernel-devel is required for building).

Wireless

2026-04-15T12:23:51Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

== Broadcom Modules Descriptions ==
The akmod-wl package is an akmod (Automatic Kernel Module) package from RPM Fusion (non-free repository) that provides the proprietary Broadcom wl (STA) kernel module for certain legacy Broadcom Wi-Fi chipsets.

The wl driver is Broadcom's official closed-source Linux driver for many older Broadcom wireless cards (e.g., BCM43xx series like BCM4312, BCM4322, BCM43228, BCM4331, etc.).
Unlike the open-source b43 or brcmfmac drivers in the mainline kernel (which often have limited or no support for these chips), wl offers better performance/features for unsupported hardware.
akmod-wl does not contain a pre-built module. Instead, it contains the source code and build system so that the akmods framework can automatically compile the wl.ko module for your current (and future) kernel versions whenever you install a new kernel.

These are the related packages:

* broadcom-wl — Provides the license, README, configuration files, and firmware blobs (the actual driver source is in the akmod).
* kmod-wl (optional) — A metapackage that pulls in a pre-built module for the newest kernel (if available from RPM Fusion).
* akmods — The build tool itself (and kernel-devel is required for building).

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T12:16:23Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document describes the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Next use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn off the mouse for ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for a bluetooth connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

== How To Remove (Unpair) the Magic Mouse ==
Use this command to remove the magic mouse from the bluetooth adapter:

[nst@nst44-mbp ~]$ bluetoothctl
remove A4:E9:75:06:E5:BA
quit

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:17:10Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document describes the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Next use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn off the mouse for ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for a bluetooth connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:16:27Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document describes the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Next use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn off the mouse for ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:15:38Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document describes the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Next use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:14:10Z

Rwh: /* Overview */

__TOC__

= Overview =
This document describes the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:13:55Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document shows the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with your NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:13:37Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
This document shows the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guidelines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:12:39Z

Rwh: /* Overview */

__TOC__

= Overview =
This document shows the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enabled. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:12:00Z

Rwh: /* Overview */

__TOC__

= Overview =
This document shows the steps on how to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:10:53Z

Rwh: /* Scrolling Solution */

__TOC__

= Overview =
How to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
To allow a Magic Mouse to scroll add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:09:57Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
How to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:07:02Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
How to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA
quit

* The above sequence should allow for connection. Use the following to check:
[nst@nst44-mbp ~]$ bluetoothctl info A4:E9:75:06:E5:BA
Device A4:E9:75:06:E5:BA (public)
Name: RWH Mouse2
Alias: RWH Mouse2
Class: 0x00000580 (1408)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
CablePairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v004Cp0269d0192

= Scrolling Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T02:04:55Z

Rwh: /* Bluetooth Connection Sequence */

__TOC__

= Overview =
How to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =
Use the following guild lines to get an Apple Magic Mouse to work with you NST system:

* Start and enable the Bluetooth service:
[nst@nst44-mbp ~]$ sudo systemctl start bluetooth.service;
[nst@nst44-mbp ~]$ sudo systemctl enable bluetooth.service;

* Use the Bluetooth Applet to scan and determine the MAC Address of the mouse (e.g., A4:E9:75:06:E5:BA)

* Use the Bluetooth Control utility: bluetoothctl for trust, pair, bond and connection.
[nst@nst44-mbp ~]$ bluetoothctl
power on
agent on
default-agent
scan on

* Now put the mouse in pairing mode (i.e., Turn of the mouse ~5sec and then back on.):
trust A4:E9:75:06:E5:BA
pair A4:E9:75:06:E5:BA
connect A4:E9:75:06:E5:BA

= Scrolling Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T01:56:28Z

Rwh: /* Bluetooth Connection Sequence */

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T01:48:55Z

Rwh:

__TOC__

= Overview =
How to configure an Apple Magic Mouse using Bluetooth with scrolling. An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Bluetooth Connection Sequence =

= Scrolling Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

HowTos

2026-04-15T01:46:48Z

Rwh:

* [[HowTo Adjust The Display Brightness On A Laptop In Console Mode Using The Command Line]]
* [[HowTo Adjust The Keyboard Backlight Brightness On A Laptop In Console Mode Using The Command Line]]
* [[HowTo Backup And Restore The Master Boot Record (MBR)]]

* [[HowTo BackupPC SSH Key Authentication Setup For rsync Transfer]]
* [[HowTo Change The LVM Volume Group Name That Includes The Root Partition]]
* [[HowTo Configure And Run A Ring Buffer Capture Session Using: "nstringbufcap"]]
* [[HowTo Configure Apache SSL For davfs, subversion, etc.]]
* [[HowTo Configure The Default Terminal Application for ssh:// For A Browser]]
* [[HowTo Create A Patch File For A RPM]]
* [[HowTo Create A GPT Disk With EFI System And exFAT Partitions Using Parted]]
* [[HowTo Curl Examples]]
* [[HowTo Fix The rngd.service]]
* [[HowTo Determine If Hardware Virtualization Is Enabled]]
* [[HowTo Disable The "relatime" Method For File "atime" Updates]]
* [[HowTo Download From The Command Line Using: "wget"]]
* [[HowTo Dual Boot NST With Windows 8.1]]
* [[HowTo Enable The Gnome Sound Applet]]
* [[HowTo Configure An Apple Magic Mouse With Scrolling]]
* [[HowTo Generate a 3D Pie Chart of nDPI Detected Protocols]]
* [[HowTo Geolocate Data Using The NST WUI]]
* [[HowTo Headless Intel NUC vPro AMT]]
* [[HowTo Install Microsoft PowerShell]]
* [[HowTo Install The MATE (GNOME 2) Desktop]]
* [[HowTo Install VirtualBox]]
* [[HowTo Keep Processes Running After Logging Out Using: "setsid"]]
* [[HowTo Limit Remote Access To "ssh" Connections]]
* [[HowTo Monitor Network Traffic]]
* [[HowTo One Liners]]
* [[HowTo Perform A Security Audit With hping3 (DoS)]]
* [[HowTo Prevent A Laptop Lid Close Suspension]]
* [[HowTo Regenerate The TLS (SSL) Certificate For The NST WUI]]
* [[HowTo Remote Connect to a Mate Desktop Session Using the Vino Server]]
* [[HowTo Resize The "root" File System Using LVM]]
* [[HowTo Quickly Get A Project Started With Subversion]]
* [[HowTo Quickly Setup A VPN Using WireGuard On NST]]
* [[HowTo Put Multiple Live Images On One USB Memory Stick]]
* [[HowTo Recreate Grub Install And The Master Boot Record (MBR) If Corrupted]]
* [[HowTo Run A Script At Boot]]
* [[OpenVAS | HowTo Setup OpenVAS]]
* [[HowTo Setup An NST System With Multiple Network Interface Adapters Using: "nstnetcfg"]]
* [[HowTo Setup Guacamole]]
* [[HowTo Setup Suricata - A Simple Live Configuration]]
* [[HowTo Share A Terminal Session Using Screen]]
* [[HowTo Shutdown NST Using A USB Flash Drive Install For Relocation]]
* [[Upgrade to NST 20|HowTo Upgrade from NST 18 to NST 20]]
* [[HowTo Upscale An Image]]
* [[HowTo Use an Android Phone as a GPSd Source]]
* [[HowTo Use A Touch Device (iPad) with NST]]
* [[HowTo Use Gmail API to send emails]]
* [[HowTo Use The NST CloudShark Upload Manager]]
* [[HowTo Use The NST Network Tools Widgets]]
* [[NST Mapping Tools | HowTo Use The NST Map Tools Widgets]]
* [[HowTo Use The NST Shell Command Console]]
* [[HowTo Use The NST WUI arp-scan Page To Quickly Locate Hosts]]
* [[HowTo Use The Scapy: Multi-Traceroute - MTR]]
* [[Console Output and Serial Terminals | HowTo Setup Console Output and Serial Terminals]]
* [[DVD_md5sum | HowTo Verify The Md5Sum On An DVD ISO]]
* [[HowTo Install NST 2.16 on an Asus Zenbook Prime]]

HowTo Enable Scrolling With An Apple Magic Mouse

2026-04-15T01:45:55Z

Rwh: Rwh moved page HowTo Enable Scrolling With An Apple Magic Mouse to HowTo Configure An Apple Magic Mouse With Scrolling: Renamed for content

#REDIRECT [[HowTo Configure An Apple Magic Mouse With Scrolling]]

HowTo Configure An Apple Magic Mouse With Scrolling

2026-04-15T01:45:55Z

Rwh: Rwh moved page HowTo Enable Scrolling With An Apple Magic Mouse to HowTo Configure An Apple Magic Mouse With Scrolling: Renamed for content

__TOC__

= Overview =
An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "'''hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40'''".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

Then rebuild the grub2 configuration file:
[root@nst42-mbp grub2]# nstboot -v --grub2;

Wireless

2026-04-15T01:39:55Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Use the following if the built-in WiFi adapter does not appear as a network interface. Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

Wireless

2026-04-15T01:38:53Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

To install the broadcom-wl driver:

[nst@nst44-mbp ~]$ sudo dnf install broadcom-wl akmod-wl kernel-devel-$(uname -r) -y;
[nst@nst44-mbp ~]$ sudo akmods --force;
[nst@nst44-mbp ~]$ sudo depmod -a;
[nst@nst44-mbp ~]$ sudo modprobe -v wl;

Reboot.

Wireless

2026-04-15T01:35:53Z

Rwh: /* Apple MacBook Pro Broadcom Wireless Adapter */

= What Wireless Cards Are Supported? =

Unfortunately, getting a wireless card to work with Linux, can be quite tricky. Often, it comes down to searching the Internet, making your best guess from bits of information, and then purchasing a card and trying it. It doesn't help that manufacturers like to change chip sets without changing model numbers.

The following lists the manufacturers of WIFI card chip sets that we have had good luck with ''working out of the box''.

* [http://www.atheros.com/ Atheros]
* [http://www.intel.com/network/connectivity/products/wireless/ Intel]

See the "[http://linux-wless.passys.nl/ Linux wireless LAN support]" web site to access a WIFI compatibility database.

= How Do I Get My Broadcom Card Working? =

Since the NST system is based off of Fedora, it comes with a kernel module that can be used to support some Broadcom WIFI cards. The kernel module is named: ''b43''. Unfortunately, it appears that the required firmware for this module is not provided by Fedora.

Instructions and more information on dealing with Broadcom cards can be found on the "[http://wireless.kernel.org/en/users/Drivers/b43 b43 and b43legacy]" page at the [http://wireless.kernel.org/ Linux Wireless] web site.

= How do I determine the manufacturer of the chip set in my WIFI card? =

The '''lspci''' command is useful in determining who manufacturers the WIFI chip set in your WIFI adapter and what version of the chip set is used. For example:

[root@cayenne ~]# lspci | grep -i network
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
[root@cayenne ~]#

The output of the above command suggests that the WIFI card is manufactured by ''Atheros Communications Inc.'' and that it has a model number of ''AR9285''. This card happens to work well in a NST system, however if it didn't, a [http://www.google.com/search?q=Atheros+AR9285+Fedora Google search on "Atheros AR9285 Fedora"] would likely provide some clues as to what would need to be done to make it work.

= Will My Wireless Card Work At Boot? =

It is unlikely that when you boot a live NST system that it will use your wireless card at boot as the default network device. In order for this to occur during a ''Console'' mode boot, all of the following must be true:

* The NST system must recognize and support your WIFI card.
* The NST system must associate the ''eth0'' interface with your WIFI card (it typically won't do this if your system has any Ethernet devices).
* There must be a wireless access point within range that has no authentication/encryption in place.

However, if you boot a live NST system to ''Desktop'' mode instead of ''Console'' mode, the '''NetworkManager''' service will be running. The '''NetworkManager''' service tries very hard to determine and establish a connection to networks. If there is a open wireless access point within range of your system, its possible that your NST system will connect to it automatically when you log in.

= How Do I Configure My Wireless Card For Network Access? =

== From The GNOME Desktop ==

If you plan on using your WIFI card as your connection to the network, it is recommended to boot your NST system to ''Desktop'' mode, log into the system using the GNOME desktop manager and use the '''NetworkManager''' applet. There will be a network icon on the top bar of your desktop you click on to work with the applet. The '''NetworkManager''' applet makes it very easy to connect to different WIFI networks and to enter in the necessary key(s) to join encrypted networks.

== From The NST WUI ==

If you are not running the '''NetworkManager''' service, you can use the NST WUI to setup a secure WPA connection. From the top menu bar on the NST WUI, select: ''Network|Wireless|WPA-PSK Setup''. This should open up a page in the NST WUI which allows you to select which interface to configure, to scan for available networks and to enter your pre-shared key.

== WIFI From The Command Line (with NetworkManager) ==

If you are using NetworkManager to manage your wireless interface, you can use the '''nmcli''' (NetworkManager Command Line utility) to connect your wireless card to an access point. It works as follows:

* Scan your system for WIFI cards
* Scan for access points
* Connect to the access point

[root@chimi ~]# nmcli device wifi rescan
[root@chimi ~]# nmcli device wifi list
* SSID MODE CHAN RATE SIGNAL BARS SECURITY
ringo-2.4 Infra 9 54 Mbit/s 100 ▂▄▆█ WPA2
* ringo-5.0 Infra 153 54 Mbit/s 100 ▂▄▆█ WPA2
-- Infra 9 54 Mbit/s 67 ▂▄▆_ WPA2
HP-Print-88-ENVY 4500 series Infra 3 54 Mbit/s 52 ▂▄__ WPA2
NETGEAR58 Infra 10 54 Mbit/s 42 ▂▄__ WPA2
ATT8u3W7d9 Infra 6 54 Mbit/s 40 ▂▄__ WPA1 WPA2
belkin.d43.guests Infra 11 54 Mbit/s 30 ▂___ --
belkin.d43 Infra 11 54 Mbit/s 30 ▂___ WPA1 WPA2
ATT9Zug2Nn Infra 4 54 Mbit/s 29 ▂___ WPA2
2WIRE201 Infra 9 54 Mbit/s 29 ▂___ WPA1 WPA2
MotoVAP_M91427SA0MS8 Infra 108 54 Mbit/s 29 ▂___ WPA2
ATT2IAK24t_guest Infra 8 54 Mbit/s 25 ▂___ WPA2
HP-Print-5A-Deskjet 2540 series Infra 3 54 Mbit/s 24 ▂___ WPA2
NETGEAR58-5G Infra 153 54 Mbit/s 19 ▂___ WPA2
[root@chimi ~]#
[root@chimi ~]# nmcli device wifi connect ringo-5.0 password WIFI_PASSWORD
Device 'wlp3s0' successfully activated with 'ff3fee57-dbb1-4c04-854a-ee3a3c4f9b75'.
[root@chimi ~]#

== WEP From The Command Line (no NetworkManager) ==

We do not recommend using WEP for accessing WIFI networks as WEP does not provide much security. However, if you need to connect your NST system to a wireless access point using WEP, you should be able to use '''NetworkManager''' if you've logged into a GNOME desktop.

If you need to access WEP from the command line, here are some dated notes from 2005 which might prove useful:

The first problem is to determine the name of the device (eth0, eth1, wlan0, etc) which Linux associates with your wireless card. After inserting your wireless card into your system, you can use the '''iwconfig''' command to determine its device name.

[root@cayenne ~]# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

wlan0mon IEEE 802.11bgn Mode:Monitor Frequency:2.472 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

[root@cayenne ~]#

The above shows that ''wlan0'' is the device name associated with a wireless card.

Once you determine the device name of your wireless card, you will need to create the appropriate configuration file under the: "''/etc/sysconfig/network-scripts''" directory. The following shows how one could create the necessary configuration for the wireless card and then restart the network drivers to enable the card.

[root@probe root]# cdnet
[root@probe network-scripts]# cp nst-eth0.dhcp ifcfg-wlan0
[root@probe network-scripts]# vim ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

ESSID="bogus"
MODE="Managed"
RATE="auto"

:wq
[root@probe root]# cat >| keys-wlan0
KEY="FEDCBA9876543210123456789A"
^D
[root@probe root]# chmod 600 keys-wlan0
[root@probe root]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface wlan0: [ OK ]
[root@probe root]#

For your card, you will need to change the values assigned to the ''ESSID'' and ''KEY'' variables above. You may also need to specify something other than ''wlan0'' if the '''iwconfig''' output shows your WIFI card having a different device name.

= Will My Wireless Card Work With Kismet and Airsnort? =

Some wireless cards that work perfectly fine for general networking, won't work with ''Kismet'' or ''Airsnort''. It turns out that in order for a wireless card to be used by either of these two programs, the driver for the card needs to support ''monitor mode''. If ''monitor mode'' is not supported, then you won't be able to use programs such as ''Kismet'' or ''Airsnort''.

The best way to determine whether your WIFI card supports ''monitor mode'' or not is to setup and try using ''Kismet''. To do this:

* Select ''Network|Wireless|Kismet Server'' from the NST WUI menu bar.
* Press the ''Setup System To Run Kismet'' button.
* Press the ''Return'' button after setup completes.
* Press the ''Kismet README'' file to read up on the ''ncsource'' configuration line.
* Press the ''Edit Kismet Config'' button and check and/or adjust the ''ncsource'' parameter.
* Press the ''Save & Return'' button.
* Press the ''Start'' button to start the ''kismet_server'' service.
* Press the ''Server Log'' button and look for ''ERROR'' messages indicating that ''Kismet'' failed to use your WIFI card or failed to put your WIFI card into ''monitor mode''.

Note for a complete walk through on setting up ''Kismet'', see: [[HowTo Geolocate kismet Data]] - you can ignore the steps related to setting up a GPS as you don't have to have a GPS connected to run ''Kismet''.

= Can I Monitor And Use the Wireless Card For Networking? =

Typically you can not use a wireless card for both monitoring and networking at the same time. It is definitely not possible if you enable channel hopping while using the wireless card in monitor mode.

= iwd Replacement for wpa_supplicant with Network Manager =
[https://wiki.archlinux.org/title/Iwd iwd] is a modern replacement for [https://wiki.archlinux.org/title/Wpa_supplicant wpa_supplicant], offering advantages like a smaller codebase, faster connections, and more intuitive command-line tools. wpa_supplicant is a more traditional and long-standing daemon, while iwd ((iNet wireless daemon) is a wireless daemon for Linux written by Intel) is a newer, faster alternative developed by Intel that uses only kernel functions for security. Both can be used as a backend for connection managers like [https://wiki.archlinux.org/title/NetworkManager NetworkManager], but iwd is generally considered more efficient and user-friendly for modern use cases.

Steps for iwd replacement of wpa_supplicant for a backend wireless daemon with NetworkManager:

* Install the iwd package:
[root@nst42-mbp ~]# dnf install iwd;

* Create a NetworkManager configuration file: "'''/etc/NetworkManager/conf.d/iwd.conf'''"
[device]
# Use iwd instead of wpa_supplicant
wifi.backend=iwd

* Restart the NetworkManager Service:
[root@nst42-mbp ~]# systemctl restart NetworkManager.service;

* Check that the iwd daemon is now running:
[root@nst42-mbp ~]# ps -ef|rg -i iwd
root 894 1 0 Dec03 ? 00:00:00 /usr/libexec/iwd
root 173022 172626 0 09:50 pts/1 00:00:00 rg -i iwd

* Make sure the wpa_supplicant daemon has terminated. If not kill the process.
[root@nst42-mbp ~]# ps -ef|rg -i wpa
root 173017 172626 0 09:50 pts/1 00:00:00 rg -i wpa

= Apple MacBook Pro Broadcom Wireless Adapter =

Common chips on MacBook Pro:

* BCM4360 (many 2013–2015 models) → usually needs broadcom-wl
* BCM43224 / BCM4331 etc. → also broadcom-wl
* Newer ones (BCM43602, BCM437x, etc.) sometimes work better with the in-kernel brcmfmac driver.

Wireless

2026-04-15T01:29:22Z

Rwh: /* iwd Replacement for wpa_supplicant with Network Manager */

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:50:37Z

Rwh: /* Solution */

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:48:41Z

Rwh: /* Solution */

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:47:58Z

Rwh: /* Solution */

__TOC__

= Overview =
An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:47:37Z

Rwh: /* Solution */

__TOC__

= Overview =
An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<pre class="computerOutput">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</pre>
</div>

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:44:41Z

Rwh: /* Solution */

__TOC__

= Overview =
An Apple Magic mouse by default does not have its scrolling enable. One must add Kernel parameters to enable scrolling.

= Solution =
Add the following parameters to the "'''/etc/nst/grub2/nst_grub2_defaults'''" file: "hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40".

<div class="screen">
<div class="screenTitle">''Section:'' NST Desktop (Graphical) Boot</div>
<div class="userInput"><span class="prompt">
#
# NST Desktop (Graphical) Boot
# --- ------- ----------- ----
NST_SERIAL[idx]="false";
NST_SERIAL_DEV[idx]="ttyS0";
NST_SERIAL_BAUD[idx]="115200";
NST_TITLE[idx]="Graphical Desktop";
NST_GRUB_CMDLINE_LINUX[idx]="audit=0 systemd.unit=graphical.target hid_magicmouse.emulate_3button=0 hid_magicmouse.scroll_acceleration=1 hid_magicmouse.scroll_speed=40";
NST_GRUB_SAVEDEFAULT[idx]="true";
NST_GRAPHICAL_BOOT[idx]="true";
idx=idx+1;
</div>
</div>

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:41:38Z

Rwh:

HowTo Configure An Apple Magic Mouse With Scrolling

2026-03-28T18:36:14Z

Rwh:

__TOC__

= Overview =