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:
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
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:
-- meaning that class of device cannot be something other than a network adaptor. Further, it may be that the subclass
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
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 netconfigSuggestions:
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
Code:
sysctl -a dev.ath0 | grep subdevice=0x000d4. 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
