[Novalug] tool for wireless

Peter Larsen peter@peterlarsen.org
Sat Dec 17 19:21:38 EST 2016


On 12/15/2016 01:11 PM, Walt Smith via Novalug wrote:
> Off the top of my head, the web interfaces to the boxes
> won't do a radio "survey" -- at least not the boxes I have.

What boxes? AP's aren't "in the business" of connecting to other APs.
Higher end models can join an existing SSID and need to connect to it's
peer stations, and it will indeed list the peers it can see. But home
APs are basic models - they provide wireless service, they don't use
it.  Only the client benefit from looking at existing APs.

This is a fairly basic thing - I have "an app" I use on my phone that
scans the area I'm in for networks. It gives me a lot of stats to help
me figure out why the WiFi is having issues. It's a client - not a
server/service.

> Also, I notice that when sold new, most pci wireless cards
> ( not the standalone boxes ???  ) come with an application
> CD for Windows which included software that do/can do 
> things other than the setup web interface. 

If you purchase hardware for Windows, you get Windows drivers. Why is
that a surprise?  When looking for hardware: Step 1) Check for platform
certification
(http://www.newegg.com/Product/Product.aspx?Item=9SIA0ZX21V0856&cm_re=pci_wireless_linux-_-33-389-005-_-Product),
step 2, check Hardware Compatibility List for your OS
(https://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/sn-Is_Your_Hardware_Compatible-x86.html)

Note, that a lot of the Windows stuff is adware. You're forced to
install a bunch of other crap than just a driver. Even though Windows
has capability to use Wireless networks, vendors will install their own
crap software that only works with their models (if you're lucky). 
Linux tends to work very differently here. We look at the chipsets used,
and people then create kernel modules for those chipsets. It makes it
fairly straight forward to see if a chipset you're using will work -
regardless of vendor. And it doesn't require any additional software
installed. There are disadvantages to this too - but for this writeup
verifying that things will work is straight forward. What you shouldn't
EVER want to do is be concerned about the Windows software. Leave that
to the Windows people and let that be their headache. Linux is simple -
we rarely need 3rd party "drivers" installed.

>  They don't come with
> linux software to do the same: note I speak of wireless PCI cards
> first, and don't know if the boxes purchased separately do. 

They actually CAN do that, but it would be dangerous to use with a
standard linux kernel. The moment  you download a patched kernel, that
old module will not be visible. So we have dkms and other nasty "dynamic
kernel modules" stuff out there, which has served only to make my Linux
life tougher in the past. Better to just use the FOSS and standard
kernel modules if possible. And if not, purchase hardware that supports
Linux - don't sponsor Windows Only vendors.

>  This would
> mean they could communicate over the wired ethernet  to 
> the box LAN connection.

?  No. If the chipset is known to Linux, your "lspci -k" will show the
card and the kernel module associated with it. That's all you need.

> so iw works with the pci wireless cards only.  A curious query was
> " why is this so ".  Can't we just redirect the i/o ?

You're talking about physical stuff here. Wireless has nothing in common
with Ethernet. NOTHING. So I would be interested in hearing how you
would abstract this.

That said - DO NOT USE IW !!!!!
Just use NetworkManager as I've stated 50 times now. It will handle all
the different interfaces, including wireless. It knows when to use "ip",
"iw" and how to interface with udev and much more to find the device
IDs, MACs and much more. It's a single interface to you.

So let's redefine your "redirect the i/o" to "management abstraction"
and the answer is: Done - NetworkManager.
>   Speculation is that the linux kernel has
> specific driver modules for the pci wireless card. and so programs like
> iw do specific system/peripheral calls to the module to control/obtain
> data.   

I get the feeling you've never had to do direct hardware interfaces like
what the kernel does? I think a Thank You letter to the kernel mailing
list may be in place, as their hard work is now creating the perception
that all hardware "just works" and interfaces the same way to the OS.
Even two PCI cards that both provides NIC stuff can have vastly
different electrical interfaces, ports, interrupts and options.

> This is not possible with a standalone box at the other
> end of an ethernet cable-- unless one know the special interface
> that may or may not be there... MAC level ??  Varies by Manufacturer ?
> standard ?

It *is* standardlized. That's what the OSI model does! You have the
freedom to implement each layer as you want, as the current level of
technology allows us to do, while still being able to use all the rest
of the layers as you always did. So  you don't have to know what
differences the hardware makes when creating your IP connection. That
was a design feature from the get go. Consider that our OSI model has
been used for 40+ years now, without needing adjusting. That's darn
powerful in IT.

> If so ( no standard ), this would explain why every blog/tech/Q&A
> website I look at with the word "linux" tells how to flash DD-wrt or
> Open-WRT, or whatever the new name is, and, taking your 
> Other suggestion, ssh to dd-wrt may be possible.

?? I'm really not following. What does that have to do with anything you
just said?

-- 

Regards
  Peter Larsen





More information about the Novalug mailing list