Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228493 > unrolled thread

Instructions for command line usage of WiFi.

Back to article view | Back to linux.debian.user

Contents

  Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-06 01:00 +0100
    Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-06 06:30 +0100
      Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-15 23:00 +0100
        Re: Instructions for command line usage of WiFi. Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-15 23:10 +0100
        Re: Instructions for command line usage of WiFi. David Wright <deblis@lionunicorn.co.uk> - 2020-11-17 16:40 +0100
      Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-25 00:50 +0100
        Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 08:50 +0100
          Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 15:20 +0100
            Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 15:50 +0100
              Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 16:40 +0100
                Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 17:20 +0100
                  Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 19:10 +0100
          Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 01:00 +0100
            Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-27 02:10 +0100
              Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 17:10 +0100
            Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-27 07:40 +0100
              Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 18:40 +0100
                Re: Instructions for command line usage of WiFi. Dan Ritter <dsr@randomstring.org> - 2020-11-27 18:50 +0100
                Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-27 19:10 +0100
                  Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-30 04:10 +0100
                    Re: Instructions for command line usage of WiFi. Doug McGarrett <dmcgarrett@optonline.net> - 2020-11-30 05:50 +0100
                    Re: Instructions for command line usage of WiFi. ghe2001 <ghe2001@protonmail.com> - 2020-11-30 07:10 +0100
                    Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-30 09:50 +0100
                      Use of external connectors on a Sharp Mebius laptop; was Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-12-01 03:10 +0100
                Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-27 22:00 +0100
                  Re: Instructions for command line usage of WiFi. Richard Hector <richard@walnut.gen.nz> - 2020-11-29 11:40 +0100
                    Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-29 13:40 +0100
          Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 04:50 +0100
        Re: Instructions for command line usage of WiFi. Wim <factotum_muth@web.de> - 2020-11-29 20:40 +0100
          Graphical environment; was, Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-12-01 15:50 +0100

Page 1 of 2  [1] 2  Next page →

#228493 — Instructions for command line usage of WiFi.

The instructions at https://wiki.debian.org/WiFi/HowToUse#Command_Line
required installation of these packages.

libiw30_30_pre9-13_i386.deb
wireless-tools_30_pre9-13_i386.deb
libnl-genl-3-200_3.4.0-1_i386.deb
libnl-3-200_3.4.0-1_i386.deb
iw_5.0.1-1_i386.deb

This stanza was added in /etc/network/interfaces
allow-hotplug wlxe894f6248352
iface wlxe894f6248352 inet dhcp
	wpa2-ssid Alcatel
	wpa2-psk  <thePassword>

ifup wlxe894f6248352
gives
ifup: interface wlxe894f6248352 already configured

iw wlxe894f6248352 link
gives
Not connected.

ip a
gives
   ...
4: wlxe894f6248352: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc 
mq state DOWN group default qlen 1000
     link/ether e8:94:f6: ... brd ff:ff:ff ...

Any ideas about this failure?  Additional software needed?

Thanks,                                ... Peter E.

[toc] | [next] | [standalone]

#228495

On Thu, Nov 05, 2020 at 05:35:18PM -0600, peter@easthope.ca wrote:
> This stanza was added in /etc/network/interfaces
> allow-hotplug wlxe894f6248352
> iface wlxe894f6248352 inet dhcp
> 	wpa2-ssid Alcatel
> 	wpa2-psk  <thePassword>

[1] also states that:

The wpasupplicant package provides wpa-* ifupdown options for
/etc/network/interfaces. If these options are specified, wpa_supplicant
is started in the background when your wireless interface is raised and
stopped when brought down.


In simplier terms: no wpasupplicant = no WPA2.


> ifup wlxe894f6248352
> gives
> ifup: interface wlxe894f6248352 already configured

"allow-hotplug" tells udev to raise a network interface after it's
attached to the kernel. This result of ifup is expected.

Reco

[1] https://wiki.debian.org/WiFi/HowToUse#Command_Line

[toc] | [prev] | [next] | [standalone]

#228697

From: Reco <recoverym4n@enotuniq.net>
Date: Fri, 6 Nov 2020 08:25:39 +0300
> [1] also states that:
>
> The wpasupplicant package ...
> 
> In simplier terms: no wpasupplicant = no WPA2.

Your simplified statement is invaluable.  "Less is more".

The rather inscrutable section entitled "wpa_supplicant" follows the 
section entitled "WPS" which follows the section entitled "Command 
Line".  The structure of the document certainly doesn't explain the 
relationship of components well. Unhelpful to a novice.  Obvously no 
problem for an expert.  But who should be helped by documentation?

I guess most connections now require authentication.  The explanation 
should be consistent with reality.

My effort to make WiFi work, using network access by a mobile tablet, 
was tough going.  Installation of packages was painful.  I abandoned 
the effort, took the HDD back to a system with wired Ethernet, 
installed LXDE, wicd and dependencies and got WiFI to work.  =8~)

I wonder why the netinstall process in the ISO image doen't include at 
least the base support for WiFi?  Too much data?  Negligence in 
planning the ISO build?

Incidentally, I'd prefer to say that authentication is conducted by 
"authenticator" and "authenticatee".  Meaning is fairly obvious.  
Symmetry is as valuable in technical terminology as in vehicle design.
Yah, I've read https://en.wikipedia.org/wiki/Supplicant_(computer).
Can't help but think that the authors of 802.1X were being a little 
too clever with "authenticator" and "supplicant".  Make it simple as 
possible!

Thanks for the help,                      ... P.





-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#228698

> Incidentally, I'd prefer to say that authentication is conducted by 
> "authenticator" and "authenticatee".  Meaning is fairly obvious.

There's also client/server, but I think the 11x people felt this would
too easy to grasp.


        Stefan

[toc] | [prev] | [next] | [standalone]

#228724

On Sun 15 Nov 2020 at 10:59:10 (-0800), peter@easthope.ca wrote:
> From: Reco <recoverym4n@enotuniq.net>
> Date: Fri, 6 Nov 2020 08:25:39 +0300
> > [1] also states that:
> >
> > The wpasupplicant package ...
> > 
> > In simplier terms: no wpasupplicant = no WPA2.
> 
> Your simplified statement is invaluable.  "Less is more".
> 
> The rather inscrutable section entitled "wpa_supplicant" follows the 
> section entitled "WPS" which follows the section entitled "Command 
> Line".  The structure of the document certainly doesn't explain the 
> relationship of components well. Unhelpful to a novice.  Obvously no 
> problem for an expert.  But who should be helped by documentation?

The trouble is that someone with expertise has to empathise with
new users ignorant of the process and terminology, and then
restructure or rewrite the whole page.

> I guess most connections now require authentication.  The explanation 
> should be consistent with reality.
> 
> My effort to make WiFi work, using network access by a mobile tablet, 
> was tough going.  Installation of packages was painful.  I abandoned 
> the effort, took the HDD back to a system with wired Ethernet, 
> installed LXDE, wicd and dependencies and got WiFI to work.  =8~)

There's no need for a DE in order to run wicd—I didn't think of
suggesting it because your first post seemed to say that you
wanted to try making connections with low-level tools like iw,
wpasupplicant, etc, something that I've always intended to
try out but never quite found the time for. Perhaps if and when
wicd gets dropped through lack of Python3 support.

> I wonder why the netinstall process in the ISO image doen't include at 
> least the base support for WiFi?  Too much data?  Negligence in 
> planning the ISO build?

They're all there, viz:

$ ls -Glg netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/w*[sa]
netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/wireless-tools:
total 164
-r--r--r-- 1  12624 Sep 15  2018 libiw30-udeb_30~pre9-13_amd64.udeb
-r--r--r-- 1  21548 Sep 15  2018 libiw30_30~pre9-13_amd64.deb
-r--r--r-- 1  12184 Sep 15  2018 wireless-tools-udeb_30~pre9-13_amd64.udeb
-r--r--r-- 1 113580 Sep 15  2018 wireless-tools_30~pre9-13_amd64.deb

netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/wpa:
total 1548
-r--r--r-- 1  324536 Sep 18  2019 wpasupplicant-udeb_2.7+git20190128+0c1e29f-6+deb10u1_amd64.udeb
-r--r--r-- 1 1254660 Sep 18  2019 wpasupplicant_2.7+git20190128+0c1e29f-6+deb10u1_amd64.deb
$ 

The same wireless packages are also on the free-firmware-only
versions of netinst, which I don't bother to download myself,
but usually the problem is that so much wireless hardware
requires non-free firmware to fully function.

The other problem is (or was¹) the removal of the contents of
/etc/network/interfaces as the final step of the installer,
meaning you have to immediately enter it all again.

> Incidentally, I'd prefer to say that authentication is conducted by 
> "authenticator" and "authenticatee".  Meaning is fairly obvious.  
> Symmetry is as valuable in technical terminology as in vehicle design.
> Yah, I've read https://en.wikipedia.org/wiki/Supplicant_(computer).
> Can't help but think that the authors of 802.1X were being a little 
> too clever with "authenticator" and "supplicant".  Make it simple as 
> possible!

Hmm. It gives a lot of scope for a typo to cause havoc. Perhaps the
authors of 802.1X (if they coined it) learnt something from PPP,
where the supplicant was known as the peer, in a system designed
for connecting two peers. What's more, I think that most people
consider themselves as the authenticator when they authenticate
themselves with a passport at immigration control. So, quite ambiguous.

¹ I haven't followed up on whether there have been improvements
  surrounding bug #694068.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#229046

    From: Reco <recoverym4n@enotuniq.net>
    Date: Fri, 6 Nov 2020 08:25:39 +0300
> The wpasupplicant package provides wpa-* ifupdown options for
> /etc/network/interfaces. If these options are specified, wpa_supplicant
> is started in the background when your wireless interface is raised and
> stopped when brought down.

> "allow-hotplug" tells udev to raise a network interface after it's
> attached to the kernel. This result of ifup is expected.

OK, thanks.  Same as "auto <interface>"?

The best documentation I've found is here.
https://wiki.archlinux.org/index.php/wpa_supplicant

For command line operation, authentication credentials can be in 
/etc/network/interfaces.  

Alternatively credentials can be in 
/etc/wpa_supplicant/wpa_supplicant.conf 
with this line in /etc/network/interfaces.
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
(I haven't seen an example with all the wpa-supplicant configuration in interfaces.)

Once that is arranged I need only three commands.
ifdown wlxa0f3c10a28f7
ifup   wlxa0f3c10a28f7
ip a     # To see the current status.

Wicd is no longer needed but leaving it installed seems harmless. (When 
wayland/weston is reliable I'll try to survive without lxde.)

This is the only oddity evident after ifup wlxa0f3c10a28f7.

  DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
  send_packet: No buffer space available
  dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.

Nevertheless, after a few more lines from DHCP the link works.
Any ideas about buffer space?

As Stefan mentioned, terms "client/server" work.  I'm the client attempting 
to authenticate to a server.

Thanks,                                 ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#229053

On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:
> > "allow-hotplug" tells udev to raise a network interface after it's
> > attached to the kernel. This result of ifup is expected.
> 
> OK, thanks.  Same as "auto <interface>"?

No. "auto" means (taken directly from interfaces(5)):

Lines beginning with the word "auto" are used to identify the physical
interfaces to be brought up when ifup is run  with the  -a option.
(This option is also used by the system boot scripts, so interfaces
marked "auto" are brought up at boot time). 


The main difference between "auto" and "allow-hotplug" is, well, hotplug
processing. And judging from that "predictable" interface name, you're
using an USB dongle, so hotplug is important here.


> This is the only oddity evident after ifup wlxa0f3c10a28f7.
> 
>   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
>   send_packet: No buffer space available
>   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> 
> Nevertheless, after a few more lines from DHCP the link works.
> Any ideas about buffer space?

The kernel has no free RAM to queue a packet or that Tp-Link device
you're is using low-quality kernel module. Happens with Tp-Link, but
there's a bright side - it could've been Broadcom.

Try increasing a value of vm.min_free_kbytes, it may help.

Reco

[toc] | [prev] | [next] | [standalone]

#229062

On Wed, 25 Nov 2020 10:42:59 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:

...

> > This is the only oddity evident after ifup wlxa0f3c10a28f7.
> > 
> >   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
> >   send_packet: No buffer space available
> >   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> > 
> > Nevertheless, after a few more lines from DHCP the link works.
> > Any ideas about buffer space?
> 
> The kernel has no free RAM to queue a packet or that Tp-Link device
> you're is using low-quality kernel module. Happens with Tp-Link, but

With TP-Link? Aren't they just using other manufacturers' chipsets? I
know people don't like Realtek and Broadcom, but does TP-Link make
their own silicon? In any event, I've always been pretty happy with
their products.

> there's a bright side - it could've been Broadcom.
> 
> Try increasing a value of vm.min_free_kbytes, it may help.
> 
> Reco
> 


Celejar

[toc] | [prev] | [next] | [standalone]

#229063

On Wed, Nov 25, 2020 at 09:19:08AM -0500, Celejar wrote:
> On Wed, 25 Nov 2020 10:42:59 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:
> > > This is the only oddity evident after ifup wlxa0f3c10a28f7.
> > > 
> > >   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
> > >   send_packet: No buffer space available
> > >   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> > > 
> > > Nevertheless, after a few more lines from DHCP the link works.
> > > Any ideas about buffer space?
> > 
> > The kernel has no free RAM to queue a packet or that Tp-Link device
> > you're is using low-quality kernel module. Happens with Tp-Link, but
> 
> With TP-Link? Aren't they just using other manufacturers' chipsets?

The hardware is definitely OEM'ed. The firmware is most likely theirs.


> I know people don't like Realtek and Broadcom,

Realtek is a hit-or-miss. Too many incompatible revisions of the same
hardware.
Broadcom is the definition of Adult Entertainment with the user put at
the receiving end.


If one needs a good and proper WiFi/Bluetooth combo, there's Intel and
Atheros.

Reco

[toc] | [prev] | [next] | [standalone]

#229065

On Wed, 25 Nov 2020 17:43:00 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> On Wed, Nov 25, 2020 at 09:19:08AM -0500, Celejar wrote:
> > On Wed, 25 Nov 2020 10:42:59 +0300
> > Reco <recoverym4n@enotuniq.net> wrote:
> > 
> > > On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:
> > > > This is the only oddity evident after ifup wlxa0f3c10a28f7.
> > > > 
> > > >   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
> > > >   send_packet: No buffer space available
> > > >   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> > > > 
> > > > Nevertheless, after a few more lines from DHCP the link works.
> > > > Any ideas about buffer space?
> > > 
> > > The kernel has no free RAM to queue a packet or that Tp-Link device
> > > you're is using low-quality kernel module. Happens with Tp-Link, but
> > 
> > With TP-Link? Aren't they just using other manufacturers' chipsets?
> 
> The hardware is definitely OEM'ed. The firmware is most likely theirs.

Really? I thought that network drivers load firmware based solely on
the chipset.

Celejar

[toc] | [prev] | [next] | [standalone]

#229068

On Wed, Nov 25, 2020 at 10:31:55AM -0500, Celejar wrote:
> On Wed, 25 Nov 2020 17:43:00 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > On Wed, Nov 25, 2020 at 09:19:08AM -0500, Celejar wrote:
> > > On Wed, 25 Nov 2020 10:42:59 +0300
> > > Reco <recoverym4n@enotuniq.net> wrote:
> > > 
> > > > On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:
> > > > > This is the only oddity evident after ifup wlxa0f3c10a28f7.
> > > > > 
> > > > >   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
> > > > >   send_packet: No buffer space available
> > > > >   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> > > > > 
> > > > > Nevertheless, after a few more lines from DHCP the link works.
> > > > > Any ideas about buffer space?
> > > > 
> > > > The kernel has no free RAM to queue a packet or that Tp-Link device
> > > > you're is using low-quality kernel module. Happens with Tp-Link, but
> > > 
> > > With TP-Link? Aren't they just using other manufacturers' chipsets?
> > 
> > The hardware is definitely OEM'ed. The firmware is most likely theirs.
> 
> Really? I thought that network drivers load firmware based solely on
> the chipset.

It's more complicated than this. For instance, to identify a NIC chip
you need something that responds to said identification.

To put it simple, to load a firmware you need something to accept it.
Some chips (ESP, nRF to name a few) allow you to write a firmware, but
can hide lower-level functions like actual frame sending (i.e. - blobs
in SDK). I.e. you provide a chip a tiny, yet complete OS, because
otherwise all you have a chip that cannot even boot. From the host POV
you just put some bits on a appropriate bus and hope that the other
side is something you expect it to be. An example - [1].

Some chips (Broadcom, Realtek or Intel, for instance), have an OS part
baked-in (or, very rarely - stored at EEPROM), and payload (i.e.
application-level software) needs to be loaded by host.  And that my
"firmware" statement was referred to a part that's baked-in, not a blob
from linux-firmware. After all, A0:F3:C1 in that NIC above is Tp-Link,
not Realtek.

Reco

[1] https://github.com/espressif/esp-hosted

[toc] | [prev] | [next] | [standalone]

#229070

On Wed, 25 Nov 2020 19:18:43 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> On Wed, Nov 25, 2020 at 10:31:55AM -0500, Celejar wrote:
> > On Wed, 25 Nov 2020 17:43:00 +0300
> > Reco <recoverym4n@enotuniq.net> wrote:
> > 
> > > On Wed, Nov 25, 2020 at 09:19:08AM -0500, Celejar wrote:
> > > > On Wed, 25 Nov 2020 10:42:59 +0300
> > > > Reco <recoverym4n@enotuniq.net> wrote:
> > > > 
> > > > > On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote:
> > > > > > This is the only oddity evident after ifup wlxa0f3c10a28f7.
> > > > > > 
> > > > > >   DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3
> > > > > >   send_packet: No buffer space available
> > > > > >   dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface.
> > > > > > 
> > > > > > Nevertheless, after a few more lines from DHCP the link works.
> > > > > > Any ideas about buffer space?
> > > > > 
> > > > > The kernel has no free RAM to queue a packet or that Tp-Link device
> > > > > you're is using low-quality kernel module. Happens with Tp-Link, but
> > > > 
> > > > With TP-Link? Aren't they just using other manufacturers' chipsets?
> > > 
> > > The hardware is definitely OEM'ed. The firmware is most likely theirs.
> > 
> > Really? I thought that network drivers load firmware based solely on
> > the chipset.
> 
> It's more complicated than this. For instance, to identify a NIC chip
> you need something that responds to said identification.
> 
> To put it simple, to load a firmware you need something to accept it.
> Some chips (ESP, nRF to name a few) allow you to write a firmware, but
> can hide lower-level functions like actual frame sending (i.e. - blobs
> in SDK). I.e. you provide a chip a tiny, yet complete OS, because
> otherwise all you have a chip that cannot even boot. From the host POV
> you just put some bits on a appropriate bus and hope that the other
> side is something you expect it to be. An example - [1].
> 
> Some chips (Broadcom, Realtek or Intel, for instance), have an OS part
> baked-in (or, very rarely - stored at EEPROM), and payload (i.e.
> application-level software) needs to be loaded by host.  And that my
> "firmware" statement was referred to a part that's baked-in, not a blob
> from linux-firmware. After all, A0:F3:C1 in that NIC above is Tp-Link,
> not Realtek.

Thanks for the detailed explanation, although I'm afraid that it's
still a little above my head. So when you referred above to a
"low-quality kernel module," you weren't referring to the linux kernel,
but something that TP-Link installs onto their products?

Celejar

[toc] | [prev] | [next] | [standalone]

#229123

From: Reco <recoverym4n@enotuniq.net>
Date: Wed, 25 Nov 2020 10:42:59 +0300
> No. "auto" means (taken directly from interfaces(5)):
> ...

OK, thanks.  Several years since I last read the man page. Can't say 
it's inspiring prose; absolutely no offense to authors; just my honest 
impression.

> The main difference between "auto" and "allow-hotplug" is, well, hotplug
> processing. And judging from that "predictable" interface name, you're
> using an USB dongle, so hotplug is important here.

Righto.  From a naive English language perspective, hot-plug 
processing is a form of automation.  So "hot-plug" is a subset of 
"auto".  But, as you say, not really.

I'll speculate that these directives came from evolution rather than 
comprehensive design. "In the beginning" there was coax Ethernet.  
When a programmer was sufficiently tired of starting links manually, 
auto was invented. Later USB came along.  When a programmer was 
sufficiently tired of raising and lowering a link, after plugging or 
unplugging an adapter, allow-hotplug was invented. With twisted pair 
I've been in the habit of "setting and forgetting" both directives.

With an access point which shuts down unpredictably I've omitted both 
directives and use ifup and ifdown interactively. If review and 
overhaul of the software is announced in the next decade, that won't 
be too shocking. 

> The kernel has no free RAM to queue a packet or that Tp-Link device
> you're is using low-quality kernel module. Happens with Tp-Link, but
> there's a bright side - it could've been Broadcom. 
> 
> Try increasing a value of vm.min_free_kbytes, it may help.

Righto, thanks.

The TP-Link TL-WN722N adapters were recommended here a few years back.
If someone has better advice now, I'm interested.

Blue-sky idea.  FPGAs are routinely available.  Is anyone working on a 
FPGA wifi adapter?  That would eliminate the specs. mystery.

Regards,                               ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#229126

On Thursday 26 November 2020 18:12:20 peter@easthope.ca wrote:

> From: Reco <recoverym4n@enotuniq.net>
> Date: Wed, 25 Nov 2020 10:42:59 +0300
>
> > No. "auto" means (taken directly from interfaces(5)):
> > ...
>
> OK, thanks.  Several years since I last read the man page. Can't say
> it's inspiring prose; absolutely no offense to authors; just my honest
> impression.
>
> > The main difference between "auto" and "allow-hotplug" is, well,
> > hotplug processing. And judging from that "predictable" interface
> > name, you're using an USB dongle, so hotplug is important here.
>
> Righto.  From a naive English language perspective, hot-plug
> processing is a form of automation.  So "hot-plug" is a subset of
> "auto".  But, as you say, not really.
>
> I'll speculate that these directives came from evolution rather than
> comprehensive design. "In the beginning" there was coax Ethernet.
> When a programmer was sufficiently tired of starting links manually,
> auto was invented. Later USB came along.  When a programmer was
> sufficiently tired of raising and lowering a link, after plugging or
> unplugging an adapter, allow-hotplug was invented. With twisted pair
> I've been in the habit of "setting and forgetting" both directives.
>
> With an access point which shuts down unpredictably I've omitted both
> directives and use ifup and ifdown interactively. If review and
> overhaul of the software is announced in the next decade, that won't
> be too shocking.
>
> > The kernel has no free RAM to queue a packet or that Tp-Link device
> > you're is using low-quality kernel module. Happens with Tp-Link, but
> > there's a bright side - it could've been Broadcom.
> >
> > Try increasing a value of vm.min_free_kbytes, it may help.
>
> Righto, thanks.
>
> The TP-Link TL-WN722N adapters were recommended here a few years back.
> If someone has better advice now, I'm interested.
>
> Blue-sky idea.  FPGAs are routinely available.  Is anyone working on a
> FPGA wifi adapter?  That would eliminate the specs. mystery.
>
Sure it could be done, but it likely can't be if you want to seel the 
product in an open market. Because it's a radio, and generally a 
software radio at that, its going to be subject to the rules and 
regulations governing those 2 basics which are that it can't be told to 
go outside its assigned frequency range, which often varies country by 
country, and it cannot be forced to generate more than its assigned by 
license power level. Those requirements absolutely preclude having those 
features available in open code where an intelligent hacker could make 
them violate those 2 requirements.  That leaves range improvements up to 
the receivers ability to pick a legit signal out of all the trash we 
generate.  That is not going to change in this so-called civilization, 
so get over it.  You don't have pockets deep enough to change that.

Who am I? A retired carrier of a 1st phone license since 1962, so I am 
quite familiar with the law.


> Regards,                               ... P.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#229133

From: Gene Heskett <gheskett@shentel.net>
Date: Thu, 26 Nov 2020 20:07:24 -0500
> ... seel the product in an open market.

I was thinking open DIY.
https://en.wikipedia.org/wiki/Do_it_yourself
Scroll down to "Electronics World 1959, home assembled amplifier".

https://en.wikipedia.org/wiki/Amateur_radio

Regards,               ... P.



-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#229128

	Hi.

On Thu, Nov 26, 2020 at 03:12:20PM -0800, peter@easthope.ca wrote:
> > The kernel has no free RAM to queue a packet or that Tp-Link device
> > you're is using low-quality kernel module. Happens with Tp-Link, but
> > there's a bright side - it could've been Broadcom. 
> > 
> > Try increasing a value of vm.min_free_kbytes, it may help.
> 
> Righto, thanks.
> 
> The TP-Link TL-WN722N adapters were recommended here a few years back.
> If someone has better advice now, I'm interested.

This one works for me:

$ lspci  | grep Wireless
03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)


It's a mini-PCI card, inserted in PCI-X adapter.


> Blue-sky idea.  FPGAs are routinely available.  Is anyone working on a 
> FPGA wifi adapter?  That would eliminate the specs. mystery.

It would be illegal in US, and you have to thank FCC for that - [1].
Applies to WiFi cards too.


Reco

[1] https://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/

[toc] | [prev] | [next] | [standalone]

#229134

From: Reco <recoverym4n@enotuniq.net>
Date: Fri, 27 Nov 2020 09:30:04 +0300
> This one works for me:
> 
> $ lspci  | grep Wireless
> 03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)
> 
> It's a mini-PCI card, inserted in PCI-X adapter.

OK, thanks.  A USB TP-Link here is used with a laptop.  For a desktop 
system, a PCI-X adapter might perform better than a USB.  Will see 
what is available.

> It would be illegal in US, and you have to thank FCC for that - [1].
> Applies to WiFi cards too.
> [1] https://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/

Interesting article about commercial products. 

I imagined FPGA based hardware assembled by J. Doe on the kitchen 
table.  It would need to be licensed similar to amateur radio? But 
available licenses don't cover the WiFi band? Wouldn't it be similar 
to licensing outdoor Christmas lights because they radiate a week EM 
field?  Isn't radiated power below some level exempted?  

Does the FCC (Industry Canada) drive around every residential 
neighbourhood and knock on every door where a field is detected and 
ask to verify that it is generated by licensed equipment?  Seems 
unrealistic.

Regards,                                  ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#229135

peter@easthope.ca wrote: 
> I imagined FPGA based hardware assembled by J. Doe on the kitchen 
> table.  It would need to be licensed similar to amateur radio? But 
> available licenses don't cover the WiFi band? Wouldn't it be similar 
> to licensing outdoor Christmas lights because they radiate a week EM 
> field?  Isn't radiated power below some level exempted?  
> 
> Does the FCC (Industry Canada) drive around every residential 
> neighbourhood and knock on every door where a field is detected and 
> ask to verify that it is generated by licensed equipment?  Seems 
> unrealistic.

No, they take complaints and investigate them.

The license to the public for certain frequencies requires
non-interference, and specifies effective radiated power limits.
The amateur radio licenses aren't to the general public, they're
to members of the public who have passed certain technical
tests... and they also specify non-interference and power
limits.

Your wifi, your microwave, and your wireless baby monitor all
use spectrum that doesn't require a test of the operator, just a
test of samples of the equipment to make sure that they don't
exceed the power limits.

Should any actual installation create inteference and
complaints, the FCC can literally drive vans around your
neighborhood until they triangulate the source, then require you
to stop transmitting until you fix the problem, possibly by
replacing or fixing the microwave oven, and possibly issue a
fine.

-dsr-

[toc] | [prev] | [next] | [standalone]

#229136

On Fri, Nov 27, 2020 at 08:51:49AM -0800, peter@easthope.ca wrote:
> > This one works for me:
> > 
> > $ lspci  | grep Wireless
> > 03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)
> > 
> > It's a mini-PCI card, inserted in PCI-X adapter.
> 
> OK, thanks.  A USB TP-Link here is used with a laptop.

That one was pulled out from an old laptop. I'm mildly curious how you
managed to obtain a laptop which does not have any kind of wireless
connectivity, so you have to resort to USB-plugged adapters.


> > It would be illegal in US, and you have to thank FCC for that - [1].
> > Applies to WiFi cards too.
> > [1] https://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> 
> Interesting article about commercial products.
> 
> I imagined FPGA based hardware assembled by J. Doe on the kitchen 
> table.  It would need to be licensed similar to amateur radio?

As long as it has any kind of radio transmitter (WiFi, Bluetooth, SDR) -
it has to be licensed. At least, that's my understanding of it.


> But available licenses don't cover the WiFi band?

WiFI and ham radio use different frequencies, so probably no.


> Wouldn't it be similar to licensing outdoor Christmas lights because
> they radiate a week EM field?

Pump enough power into consumer-grade 802.1ad-capable WiFi (to cover a
mile radius or so), tweak a frequency a bit, and suddenly you can screw
a radar of any airplane above your head. At least that was the official
reason of locking down 802.1ad to "trusted and vetted firmware".


> Isn't radiated power below some level exempted?  

True. But the effective distance between two devices utilizing this form
of communication is measured in inches (so called NFC), and it's a
different frequency again.


> Does the FCC (Industry Canada) drive around every residential 
> neighbourhood and knock on every door where a field is detected and 
> ask to verify that it is generated by licensed equipment?  Seems 
> unrealistic.

US FCC restriction applies to devices sold to consumers on a US market.
Somehow I doubt that Canada's market suppliers (or Europe for that
matter) are different from US ones.
Therefore US FCC restrictions magically apply to most of the first-world
countries.

I.e. of course nobody can forbid you (or me) to build an unlicensed WiFi
transmitter of arbitrary power or frequency. But they won't sell it to
you (or me).

Reco

[toc] | [prev] | [next] | [standalone]

#229169

From: Reco <recoverym4n@enotuniq.net>
Date: Fri, 27 Nov 2020 21:09:26 +0300
> I'm mildly curious how you managed to obtain a laptop which does not 
> have any kind of wireless connectivity, ...

The machine is a Sharp Mebius PC-CB1-M1.  
https://jp.sharp/support/mebius/spec/pc_cb1_m1.html

It has an 8P8C socket and a 6P2C socket.  lspci reports VIA 
VT6102/VT6103 Ethernet Controller and VIA AC'97 Modem Controller. No 
evidence of IEEE 802.11 or Bluetooth.  

This is the only Sharp machine I've used.  They could have made a 
similar model with WiFi.  I don't know.  

Regards,                        ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web