Network Interfaces/devices on FreeBSD, Device Hardening (beta testing)

Please take my notes here as a benefit to the community that enjoys FreeBSD and aims to betterment and improvement of the system. I am writing with the hope that some of the issues I run into will eventually be heard at the HEAD level and corrected in the next release. Although facts about time and motion when testing would not make sense, I see explaining my findings based on events occurred on a particular release.

1. FreeBSD 10.1 does recognizes the network interface correctly (limitations would apply) but reacts to a coexistence problem between the Ethernet and Wireless device.

2. FreeBSD 10.1 has some problems with wpa_supplicant that I couldn’t figure neither I could get help to further investigate.

3. FreeBSD 10.2 and 10.3 would behave much as a FreeBSD 11.x on the subject of Network Interfaces/devices.

4. FreeBSD 11.x as of today does not recognizes the network interface correctly. The error in my case is no Wireless connection at all.

Problem can be replicated:

Code:
more /var/run/dmesg.boot | grep ath0
RESULTS: ath0: <Atheros 9280> mem 0xc24
--------------------------------------------------------------------------------------------
pciconf -lv ath0
RESULTS:
ath0@pci0:7:0:0:  class=0x028000 card=0x3042103c chip=0x002a168c rev=0x01 hdr=0x00
  vendor  = 'Atheros Communications Inc.'
  device  = 'AR928X Wireless Network Adapter (PCI-Express)'
  class  = network
--------------------------------------------------------------------------------------------
sysctl -a dev.ath.0.%desc | cut -d':' -f2
RESULTS: Atheros 9280
--------------------------------------------------------------------------------------------

Conclusion:
First, sysctl and dmesg.boot gets a description that is not correct while pciconf results are.
Second, this indicates that there are two databases of references to devices in FreeBSD and are not synchronized. Q1. Where is the pciconf results are coming from?
Third, why there is a need for more than one database of devices to begin with.
Forth, even bsdinstall has a problem with it when running
Code:
bsdinstall -D /tmp/test1net.log netconfig


Suggestions:
1. Consolidate into a single source of info pertinent to devices which would require all developers to comply with the standards.
2. Clean up the mess in the inventory of devices
3. Searching the device description to initiate install it is a bad idea and totally unprofessional. Here you can adapt to standards where there is an inventory of devices and accordingly a precise class – as an example:
Code:
sysctl -a dev | grep class=0x02
-- meaning that class of device cannot be something other than a network adaptor. Further, it may be that the subclass
Code:
sysctl -a dev.ath0 | grep subdevice=0x000d
is a wireless (see http://pci-ids.ucw.cz/ -- class and subclass ).
4. Create a FreeBSD proprietary extension of same database to further improve identifying devices. The extension would be very useful to cover precise info on hardware that was tested and working as well as those are waiting to be tested.

References on the subject of Interfaces/devices database:
Much of the paper published on this subject suggested that any tree root will start with the provider in our case a manufacturer who build the device. Thereafter, the product class, subclass (card=), and proprietary data.

Thomas Register -- now thomasnet
http://www.thomasnet.com/nsearch.html?heading=96003017&what=PCI+devices&cov=NA

pcidatabase.com
http://pcidatabase.com/search.php?device_search_str=network&device_search=Search

sourceforge
http://pciids.sourceforge.net/

Device classes per http://pci-ids.ucw.cz/read/PD/
[02]Network controller
[0d]Wireless controller

Device subclasses: http://pci-ids.ucw.cz/mods/PD?action=help?help=pci_class
[00]Ethernet controller
[80]Network controller
 
First, sysctl and dmesg.boot gets a description that is not correct while pciconf results are.
sysctl(8)s are created by the driver. If the wrong driver detects the card, the info will be wrong too.

Q1. Where is the pciconf results are coming from?
It's read directly from pci(4):
Code:
     The pciconf utility provides a command line interface to functionality
     provided by the pci(4) ioctl(2) interface.  As such, some of the func-
     tions are only available to users with write access to /dev/pci, normally
     only the super-user.

Third, why there is a need for more than one database of devices to begin with.
These aren't "databases".
 
Thank you, SirDice – well, then we should create one database (of attached/unattached to system) as a permanent resident. May be auto updated by system or manual update and following a simple format as fouond in /etc/group. Any refrences on this subject please?

PS: I’ll look into pci(4) ioctl(2) interface more.
 
First, sysctl and dmesg.boot gets a description that is not correct while pciconf results are.
Second, this indicates that there are two databases of references to devices in FreeBSD and are not synchronized. Q1. Where is the pciconf results are coming from?
Third, why there is a need for more than one database of devices to begin with.
The value you see in the pciconf output are just strings read directly from the chip. There is no database involved. The driver (ath(4) in your case) matches the vendor and chip id and other data against a list of known cards. This is hardcoded in the driver and it has determined that you have an Atheros 9280 based on that. It uses a different string here, because what the device
4. FreeBSD 11.x as of today does not recognizes the network interface correctly. The error in my case is no Wireless connection at all.
In FreeBSD 11.0 wireless network interfaces (i.e. ath0) won't show up in ifconfig anymore unless you've created your wlan0 device first. But there a new sysctl that lists WLAN interfaces: net.wlan.devices

EDIT: I just wanted to add that bsdinstall(8) uses this on FreeBSD 10.x to detect if an interface is wireless: ifconfig $1 | grep -q 'media: IEEE 802.11 Wireless'
 
Boot into 10.1 and select shell

Code:
mkdir /tmp/t1 # our test results
touch /tmp/t1/test1net.log
bsdinstall -D /tmp/t1/test1net.log netconfig

# select ath0 (which is properly described) then press OK

# ERR: Could not start wpa_supplicant 
# – I agree with the error as wpa_supplicant was not installed and may be will not work even if loaded in memory.

# OK… then cancel (buttons hit); back to shell now

# Plug in a USB stick in my case da1

mkdir /tmp/usb
mount –t msdosfs /dev/da1s1 /tmp/usb
cp /tmp/t1/test1net.log /tmp/usb/test1net.log

Same test with FreeBSD 11 latest DVD but set the output to test2net.log
-- Here we can select the "ath0 Atheros 9280" but nothing more as may be a wireless
-- Received the same ERR as on 10.1 of no WPA_...

I will post results when have the time to install FreeBSD 11 and go through a full install then getting the wireless up - curious just to see if the config files from 10.1 will make WPA_ work on 11.x

Again, while coding and searching the description for Wireless is not proper - works for now but not the pathway to "rock solid sys" - I am still vouching for a proposed database simple effective with proprietary extension.

I also looked a little at:
FreeBSD: releng/10.1/usr.sbin/bsdconfig/share/device.subr 266290 2014-05-17 03:28:43Z dteske
# Network interfaces/names: isn't that a database? Even loaded as an array!
May be that is where the problem with wrong description comes from. Of course not on 10.1 -- (line 1289) f_network "ath%d" "Atheros IEEE 802.11 wireless adapter"

Both files (test1net.log, test2net.log) uploaded as
testnet20160404.zip
 

Attachments

  • testnet20160404.zip
    5 KB · Views: 371
Back
Top