Re: how to find out regdomain/country of wifi network

[Jeremy Ardley]

On 13/5/23 17:19, hl wrote:
>
> To view the current list of regulatory domains and SKUs:
>
>  # ifconfig wlan0 list countries
>
> To view the current regulatory domain frequency and operating modes:
>
>  # ifconfig wlan0 list regdomain
>
>
> but ifconfig isn't available in buster
>
ifconfig needs to be run as root or sudo. e.g.

sudoifconfig wlan0 list countries

--
Jeremy
(Lists)

[Jeremy Ardley]

On 13/5/23 17:38, Jeremy Ardley wrote:
>>
> ifconfig needs to be run as root or sudo. e.g.
>
> sudoifconfig wlan0 list countries

Wrong.

sudo ifconfig wlan0 list countries


--
Jeremy
(Lists)

[Nicolas George]

Jeremy Ardley (12023-05-13):

> ifconfig needs to be run as root or sudo. e.g.

Wrong.

cigaes@ssecem ~ $ sudo ifconfig wlan0 list countries
wlan0 list co: error fetching interface information: Device not found

cigaes@ssecem ~ $ /sbin/ifconfig wlan0 list countries
wlan0 list co: error fetching interface information: Device not found

I so wish people would be careful in making the difference between a
problem of path and a problem of permissions.

Also, ifconfig has nothing to do with wireless, so it was a red herring
from the start.

[Vincent Lefevre]

On 2023-05-13 17:41:14 +0800, Jeremy Ardley wrote:
> On 13/5/23 17:38, Jeremy Ardley wrote:
> > ifconfig needs to be run as root or sudo. e.g.
> >
> > sudoifconfig wlan0 list countries
>
> Wrong.
>
> sudo ifconfig wlan0 list countries

Wrong again. You must not use no-break spaces.

Moreover, it should not be necessary to be root: you are just
reading non-private data. However, "list countries" does not
seem to exist.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[jeremy ardley]

On 13/5/23 17:51, Nicolas George wrote:

Also, ifconfig has nothing to do with wireless, so it was a red herring
from the start.

wlan0 is an interface like any other and ifconfig works with it

Your issue is you don't have a wlan0 on your particular system so you got an error.

The OP indicated they do have a wlan0, so lets see what they find without speculating.

--

Jeremy

[Vincent Lefevre]

On 2023-05-13 17:19:01 +0800, hl wrote:
> but ifconfig isn't available in buster

I've used it for many years, and it is still there, currently in
the net-tools package (try "apt-file search bin/ifconfig").

[Nicolas George]

jeremy ardley (12023-05-13):

> wlan0 is an interface like any other and ifconfig works with it
>
> Your issue is you don't have a wlan0 on your particular system so you got an
> error.

<sigh> Check before saying something wrong.

--
Nicolas George

[Jeremy Ardley]

On 13/5/23 17:57, Vincent Lefevre wrote:
> Moreover, it should not be necessary to be root: you are just
> reading non-private data. However, "list countries" does not
> seem to exist.

Debian 11 seems to have a different opinion on who can run ifconfig. Sudo or root is required.

jeremy@client:~$ ifconfig enp8s0
bash: ifconfig: command not found
jeremy@client:~$ sudo ifconfig enp8s0
enp8s0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 0c:9d:92:75:b4:f7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



--
Jeremy
(Lists)

[Vincent Lefevre]

On 2023-05-13 17:56:48 +0800, jeremy ardley wrote:
>
> On 13/5/23 17:51, Nicolas George wrote:
> > Also, ifconfig has nothing to do with wireless, so it was a red herring
> > from the start.
>
> wlan0 is an interface like any other and ifconfig works with it

For me, since the wireless interface is wlp61s0:

zira:~> ifconfig wlp61s0 list countries
list: Unknown host
ifconfig: `--help' gives usage information.

What you gave is unknown to ifconfig.

[Vincent Lefevre]

On 2023-05-13 18:02:18 +0800, Jeremy Ardley wrote:
>
> On 13/5/23 17:57, Vincent Lefevre wrote:
> > Moreover, it should not be necessary to be root: you are just
> > reading non-private data. However, "list countries" does not
> > seem to exist.
>
> Debian 11 seems to have a different opinion on who can run ifconfig.
> Sudo or root is required.

Wrong.

> jeremy@client:~$ ifconfig enp8s0
> bash: ifconfig: command not found
> jeremy@client:~$ sudo ifconfig enp8s0
> enp8s0: flags=4098<BROADCAST,MULTICAST> mtu 1500

[...]

You should learn what a run path is. A "command not found" just means
that the command isn't in your path. So, provide the path explicitly
or add /sbin to $PATH.

zira:~> ifconfig enp0s25
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 30:8d:99:25:ad:3f txqueuelen 1000 (Ethernet)
device interrupt 20 memory 0xd2100000-d2120000

No need to be root or use sudo (I've always had /sbin in my path).

[Nicolas George]

Jeremy Ardley (12023-05-13):
> The reason it's not on the path is because the Debian designers
> thought it would best if users did not routinely run it

This is your interpretation, not an official stance. It might as well be
that they considered polluting the completion namespace of users with a
command they rarely need was less convenient.

Regards,

--
Nicolas George

[Jeremy Ardley]

On 13/5/23 18:07, Vincent Lefevre wrote:
> You should learn what a run path is. A "command not found" just means
> that the command isn't in your path. So, provide the path explicitly
> or add /sbin to $PATH.

The reason it's not on the path is because the Debian designers thought it would best if users did not routinely run it

You can configure your way around most things and likely get up to all sorts of mischief.

In a list with a wide variety of users, sticking to showing how to use the standard configuration will be helpful to more people

--
Jeremy
(Lists)

[Nicolas George]

Jeremy Ardley (12023-05-13):
> The actual reason is they have deprecated it in favour of the ip command

<sigh> No it is not the actual reason, as ifconfig has been in /sbin
since way before ip existed.

--
Nicolas George

[Jeremy Ardley]

On 13/5/23 18:17, Nicolas George wrote:
> This is your interpretation, not an official stance. It might as well be
> that they considered polluting the completion namespace of users with a
> command they rarely need was less convenient.

The actual reason is they have deprecated it in favour of the ip command but left it available for now with a bit of searching.

--
Jeremy
(Lists)

[to...@tuxteam.de]

On Sat, May 13, 2023 at 06:14:57PM +0800, Jeremy Ardley wrote:
>
> On 13/5/23 18:07, Vincent Lefevre wrote:
> > You should learn what a run path is. A "command not found" just means
> > that the command isn't in your path. So, provide the path explicitly
> > or add /sbin to $PATH.
>
> The reason it's not on the path is because the Debian designers thought it would best if users did not routinely run it

Sorry for being blunt: this is nonsense. Unices have been giving
root a different PATH by default since I know them (and this is
already longer than I care to admit).

Cheers
--
t

[to...@tuxteam.de]

On Sat, May 13, 2023 at 06:02:18PM +0800, Jeremy Ardley wrote:
>
> On 13/5/23 17:57, Vincent Lefevre wrote:
> > Moreover, it should not be necessary to be root: you are just
> > reading non-private data. However, "list countries" does not
> > seem to exist.
>
> Debian 11 seems to have a different opinion on who can run ifconfig. Sudo or root is required.

Nonsense.

> jeremy@client:~$ ifconfig enp8s0
> bash: ifconfig: command not found
> jeremy@client:~$ sudo ifconfig enp8s0
> enp8s0: flags=4098<BROADCAST,MULTICAST> mtu 1500
> ether 0c:9d:92:75:b4:f7 txqueuelen 1000 (Ethernet)
> RX packets 0 bytes 0 (0.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 0 bytes 0 (0.0 B)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

You achieve the same effect as regular user if you say /sbin/ifconfig.

That's because sudo is in /sbin (or, perhaps, in /usr/sbin, for the
young'uns), which by default isn't in a regular user's PATH. That's
all. That's not an "opinion" of Debian (I had that already in HP/UX
around 1995 or so).

Only if you try to do root-y things (change an interface's IP, for
example) you'll need root privileges.

Cheers
--
t

[to...@tuxteam.de]

Again: no.

Ip is by default in /bin, perhaps because it's more "modern". Ifconfig
has always been in /sbin, long before Debian existed.

Cheers
--
t

[Nicolas George]

hl (12023-05-13):
> root@debian:~# /sbin/ifconfig  wlx12345 list regdomain
> list: Unknown host

Told you ifconfig was a red herring.

--
Nicolas George

[jeremy ardley]

On 13/5/23 18:36, to...@tuxteam.de wrote:

Ip is by default in /bin, perhaps because it's more "modern". Ifconfig
has always been in /sbin, long before Debian existed.

--
Some programs are on the root path and some on the user path and most (all?) on both.

The exact reasons are in the mists of time, but it seems likely the powers didn't want users to routinely use programs better run by adminstrators.

Using sudo automatically gives you the root path so you can run programs 'better run by admins' without extra work figuring out paths and any local variations.

In some cases sudo is actually required and in some cases it makes no difference.

Jeremy

[Jeremy Ardley]

On 13/5/23 18:46, jeremy ardley wrote:

> Some programs are on the root path and some on the user path and most
> (all?) on both.

Correction

Most (all?) are on the root path, not including programs specific to a user or application.

--
Jeremy
(Lists)

[Nicolas George]

jeremy ardley (12023-05-13):

> In some cases sudo is actually required and in some cases it makes no
> difference.

If you use sudo just to run programs that are not in the default path
but do not require privileges, then please keep away from any system I
administrate and refrain from giving advice to anybody who might
co-administrate with me.

--
Nicolas George

[didier gaumet]

Hello,

some info here:
https://www.kernel.org/doc/html/latest/networking/regulatory.html

[Michel Verdier]

Le 13 mai 2023 jeremy ardley a écrit :

> The exact reasons are in the mists of time, but it seems likely the powers
> didn't want users to routinely use programs better run by adminstrators.

As I learned it a long time ago, /bin /sbin are historically for system
commands, /usr/bin /usr/sbin for user ones. sbin stands for "static
binaries" for commands needed while libs are not available (boot,
recovery, etc). Potentially commands for root. Nowadays we have binaries
and libs on same device so bin sbin are less significant. And of course
since debian merge /usr there is no difference between system and user
commands :

lrwxrwxrwx 1 root root 7 17 sept. 2022 bin -> usr/bin
lrwxrwxrwx 1 root root 7 17 sept. 2022 lib -> usr/lib
lrwxrwxrwx 1 root root 9 17 sept. 2022 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 17 sept. 2022 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 17 sept. 2022 libx32 -> usr/libx32
lrwxrwxrwx 1 root root 8 17 sept. 2022 sbin -> usr/sbin

[to...@tuxteam.de]

On Sat, May 13, 2023 at 02:26:58PM +0200, Michel Verdier wrote:
> Le 13 mai 2023 jeremy ardley a écrit :
>
> > The exact reasons are in the mists of time, but it seems likely the powers
> > didn't want users to routinely use programs better run by adminstrators.
>
> As I learned it a long time ago, /bin /sbin are historically for system
> commands, /usr/bin /usr/sbin for user ones.

No. /bin and /usr/bin are for the "normal" users, /sbin, /usr/sbin for
the admin (typically). The "s" meaning "system".

There's a wikipedia page [1] on that.

The difference between /usr and non-/usr stems from the times you had
only a small disk at boot (/usr being mounted later, perhaps as a NFS
mount). You possibly needed a minimal viable system to set up all the
rest to be able to mount /usr.

These days all those things happen typically at initramfs time. That's
why usrmerge was possible at all.

Cheers

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
--
t

[David]

On Sat, 13 May 2023 at 09:35, hl <hlyg...@outlook.com> wrote:

> freebsd ask me regdomain/country of wifi when i set up wifi
>
> my wifi works in buster, how to find out regdomain/country it uses?

[root@satpro ~]# iw help | grep reg
reg reload
Reload the kernel's regulatory database.
phy <phyname> reg get
Print out the devices' current regulatory domain information.
reg get
Print out the kernel's current regulatory domain information.
reg set <ISO/IEC 3166-1 alpha2>
Notify the kernel about the current regulatory domain.

[root@satpro ~]# iw list | grep phy
Wiphy phy0
wiphy index: 0
* set_wiphy_netns

[root@satpro ~]# iw phy phy0 reg get
global
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR

[root@satpro ~]# iw reg get
global
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR

[root@satpro ~]# type iw
iw is hashed (/usr/sbin/iw)

[root@satpro ~]# dpkg -S /usr/sbin/iw
dpkg-query: no path found matching pattern /usr/sbin/iw

[root@satpro ~]# dpkg -S /sbin/iw
iw: /sbin/iw

[root@satpro ~]# apt show iw
Package: iw
Version: 5.9-3
Priority: optional
Section: net
Maintainer: Paride Legovini <par...@debian.org>
Installed-Size: 300 kB
Depends: libc6 (>= 2.17), libnl-3-200 (>= 3.2.7), libnl-genl-3-200 (>= 3.2.7)
Recommends: wireless-regdb
Homepage: https://wireless.wiki.kernel.org/en/users/documentation/iw
Tag: hardware::TODO, implemented-in::c, interface::commandline,
network::configuration, role::program, use::configuring
Download-Size: 100 kB
APT-Manual-Installed: yes
APT-Sources: http://approx:9999/debian bullseye/main amd64 Packages
Description: tool for configuring Linux wireless devices
This package contains the 'iw' command line tool which allows to configure and
show information about wireless devices.
.
iw is based on the nl80211 kernel interface and supports the majority of
fairly recent hardware. The old tool iwconfig, which uses Wireless Extensions
interface, is deprecated and it is strongly recommended to switch to iw and
nl80211.

[root@satpro ~]# cat /etc/debian_version
11.7

[gene heskett]

On 5/13/23 05:35, hl wrote:
> freebsd ask me regdomain/country of wifi when i set up wifi
>
> my wifi works in buster, how to find out regdomain/country it uses?
>

> https://wiki.freebsd.org/action/show/WiFi/RegulatoryDomainSupport?action=show&redirect=WiFiRegulatory

>
> To view the current list of regulatory domains and SKUs:
>
>  # ifconfig wlan0 list countries
>
> To view the current regulatory domain frequency and operating modes:
>
>  # ifconfig wlan0 list regdomain
>
>

> but ifconfig isn't available in buster
>

I've got an old, now shoved under the bus and sold to the money cats,
1st phone ticket in my billfold, issued back when it meant something,
and I am also a CET, teaching EE's how to get their hands dirty if
needed. This gentleman's concern is very real, with potentially costly
results in this world of everything being made in china with no regard
for our laws.

Unless there is a replacement utility that will supply him with the info
he needs the legal consequences exposure is an unknown.

ip does not in my man reading, offer similar performance. Is there a
replacement utility for ifconfig that will supply this info?

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, 1940)
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 heskett]

On 5/13/23 05:39, Jeremy Ardley wrote:

>
> On 13/5/23 17:19, hl wrote:
>>
>> To view the current list of regulatory domains and SKUs:
>>
>>  # ifconfig wlan0 list countries
>>
>> To view the current regulatory domain frequency and operating modes:
>>
>>  # ifconfig wlan0 list regdomain
>>
>>
>> but ifconfig isn't available in buster
>>

> ifconfig needs to be run as root or sudo. e.g.
>

> sudo ifconfig wlan0 list countries
>

It is not available for bullseye either. And the buster version has been
emasculated, no mention of the radio's exists in the --help menu.

[gene heskett]

On 5/13/23 06:04, Vincent Lefevre wrote:
> On 2023-05-13 17:56:48 +0800, jeremy ardley wrote:
>>
>> On 13/5/23 17:51, Nicolas George wrote:
>>> Also, ifconfig has nothing to do with wireless, so it was a red herring
>>> from the start.
>>
>> wlan0 is an interface like any other and ifconfig works with it
>
> For me, since the wireless interface is wlp61s0:
>
> zira:~> ifconfig wlp61s0 list countries
> list: Unknown host
> ifconfig: `--help' gives usage information.
>
> What you gave is unknown to ifconfig.
>

So also is wlan0 or any other name that may have been assigned to the
radio. Radio's are unk to ifconfig today. So it is worthless to the OP.

[gene heskett]

That is not a radio interface, so for the OP use is just noise.

[Bret Busby]

On 13/5/23 22:22, gene heskett wrote:
> On 5/13/23 05:35, hl wrote:
>> freebsd ask me regdomain/country of wifi when i set up wifi
>>
>> my wifi works in buster, how to find out regdomain/country it uses?
>>
>> https://wiki.freebsd.org/action/show/WiFi/RegulatoryDomainSupport?action=show&redirect=WiFiRegulatory
>>
>> To view the current list of regulatory domains and SKUs:
>>
>>   # ifconfig wlan0 list countries
>>
>> To view the current regulatory domain frequency and operating modes:
>>
>>   # ifconfig wlan0 list regdomain
>>
>>
>> but ifconfig isn't available in buster
>>
> I've got an old, now shoved under the bus and sold to the money cats,
> 1st phone ticket in my billfold, issued back when it meant something,
> and I am also a CET, teaching EE's how to get their hands dirty if
> needed.  This gentleman's concern is very real, with potentially costly
> results in this world of everything being made in china with no regard
> for our laws.
>
> Unless there is a replacement utility that will supply him with the info
> he needs the legal consequences exposure is an unknown.
>
> ip does not in my man reading, offer similar performance. Is there a
> replacement utility for ifconfig that will supply this info?
>
> Cheers, Gene Heskett.

Having viewed the web page at the URL cited by the original poster, to
me, the original poster's question is "Why does this FreeBSD command not
work on Linux?"

The command and the options, as stated in the original post, are in the
exact format and syntax, specified explicitly for FreeBSD, and, not for
Linux.

I have ifconfig installed and operational.

Did the original poster (and, the poster above), type
man ifconfig
to find what options are available on the distribution and version
number of Linux, that they have installed?

The syntax as cited in the original post, is not available for the
version of ifconfig that I have installed.

See also
https://unix.stackexchange.com/questions/629134/how-to-set-country-region-for-wifi-globally-in-linux-mint-20

https://wiki.archlinux.org/title/Network_configuration/Wireless

to find the information that is sought.

Perhaps, both posters above, should try searching (with something like
the Borg search engine named google), for how to find the relevant
information on the distribution and version number of Linux, that they
have installed, rather than complaining that a FreeBSD command does not
work on it?

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[gene heskett]

On 5/13/23 06:02, Vincent Lefevre wrote:
> On 2023-05-13 17:19:01 +0800, hl wrote:
>> but ifconfig isn't available in buster
>
> I've used it for many years, and it is still there, currently in
> the net-tools package (try "apt-file search bin/ifconfig").
>

Thank you Vincent, not ordinarily installed in bullseye. And it still
knows nothing about radio's.

[gene heskett]

> .
Some useful info above. Useful to the OP? IDK.

[to...@tuxteam.de]

On Sat, May 13, 2023 at 10:22:50AM -0400, gene heskett wrote:

[...]

> ip does not in my man reading, offer similar performance. Is there a
> replacement utility for ifconfig that will supply this info?

Sigh. Yes. There is a replacement. It is called ifconfig. Package
net-tools, as `apt-file search' has surely told you.

FWIW, I have *both* ifconfig and ip installed. I use *both*.

Cheers
--
t

[David Wright]

On Sat 13 May 2023 at 17:19:01 (+0800), hl wrote:
> freebsd ask me regdomain/country of wifi when i set up wifi
>
> my wifi works in buster, how to find out regdomain/country it uses?

For bullseye:

$ /sbin/iw reg get
global
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

to find out what it's set to.

# /sbin/iw reg set US

to set it (the usual two-letter codes).

$ /sbin/regdbdump /usr/lib/crda/regulatory.bin | less

to list all that it knows about.

$ apt-file find foo

to find out which package foo is in.

AFAIK buster is the same.

Whare are you? China?

Cheers,
David.

[gene heskett]

Unfortunately Tomas, neither util knows anything about radio's. Someone
just reminded me that iw is now the tool. I've found that /sbin/iw can
output regulatory info, but the shorthand used is a bit opaque. From my
one lonesome wifi equipt rpi4b:
pi@rpi4:~ $ /sbin/iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

I have all of mine turned off and everything is wired to prevent the AH
across the street from using my bandwidth to watch his porn. He had a
utility on his cell phone capable of hijacking my radios. I hear he is
back in the hotel for the 2nd time. Life in the neighborhood is much
improved w/o him.

iw's output seems complete even if there is no radio, which the bpi's
don't have, but from bpi54:
gene@bpi54:~$ /sbin/iw reg get
global
country 00: DFS-UNSET
(2402 - 2472 @ 40), (6, 20), (N/A)
(2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
(5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)

note the 00: DFS-UNSET for country. the board doesn't even have a socket
for a radio, but in practice its a supercharged rpi4b for $65 USD at
alliexpress. I have yet to find something an rpi4b can do that the bpi's
can't do. I have a sw problem with cups but I suspect its a software fix
too. Just got to find the magic mushroom. ;o)>

Take care & stay well, Tomas.

[to...@tuxteam.de]

On Sat, May 13, 2023 at 11:55:57AM -0400, gene heskett wrote:

[...]

> Unfortunately Tomas, neither util knows anything about radio's.

As far as I know they never did.

> Someone
> just reminded me that iw is now the tool. I've found that /sbin/iw can
> output regulatory info, but the shorthand used is a bit opaque. From my one
> lonesome wifi equipt rpi4b:

Yes, I think that one is your buddy.

Hm. As far as I understand the docs, this is telling you about
the regulatory database, i.e. how many dB your WiFi is supposed
to yell out at which freq depending on where your computer thinks
it is.

This exists independently of whether your hw is on or off, or
on whether you've got any radio hardware at all.

Cheers
--
t

[Nicolas George]

Thomas Schweikle (12023-05-13):
> No, not really. But some do have a short memory. Computers used to have
> "lots of memory" at some times in the past if they had 64KiB. The Harddisk
> used to be large if it had 5MiB available. Systems had to mount drives over
> networks to access more storage. You had to put all parts boot up a system
> on one HD. "/sbin" was the answer. /sbin held all parts to boot up a system,
> then mount further HD directly or over network.

Some have short memory, some believe they have long memory but it is not
very reliable.

What you describe is the reason for /(s)bin vs /usr/(s)bin, not the
reason for (/usr)/bin vs (/usr)/sbin.

--
Nicolas George

[to...@tuxteam.de]

On Sat, May 13, 2023 at 04:25:26PM +0000, Thomas Schweikle wrote:

[...]

> This was never the reason for "/bin" vs. "/sbin". "/sbin" held just tools
> needed to startup the system and mount the rest.

No. You needed *both* /bin and /sbin for start up; /usr/bin and /usr/sbin
could come later.

One prominent example: /bin/sh. No shell, no system.

It's pretty well explained here [1].

The difference between "s" and no "s" was "system" vs. "user". And this
wasn't done to "keep the users from messing with the system"; rather to
not clutter the user's path with programs (s)he couldn't use anyway.

[Nicholas Geovanis]

Ifconfig has been deprecated in Debian for some years. IIRC the wiki tells you that but i honestly did not know that for years after.... Until i took care of ubuntu servers: no root login period; no old network tools period. 

Jeremy
(Lists)

[to...@tuxteam.de]

On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> On Sat, May 13, 2023, 5:23 AM Jeremy Ardley <jer...@ardley.org> wrote:
>
> >
> > On 13/5/23 18:17, Nicolas George wrote:
> > > This is your interpretation, not an official stance. It might as well be
> > > that they considered polluting the completion namespace of users with a
> > > command they rarely need was less convenient.
> >
> > The actual reason is they have deprecated it in favour of the ip command
> > but left it available for now with a bit of searching.
> >
>
> Ifconfig has been deprecated in Debian for some years.

It is *not* deprecated. It is just optional, not essential. As is the
Gnu C compiler or Lua or... you name it. If you need it, you install
it. It is in stable (version 1.60), coming in testing (v 2.10) and is
in unstable. It is not going away, folks!

> IIRC the wiki tells
> you that but i honestly did not know that for years after.... Until i took
> care of ubuntu servers: no root login period; no old network tools period.

Where?

Cheers
--
t

[Arno Lehmann]

Hi hl,

Am 13.05.2023 um 11:19 schrieb hl:
> freebsd ask me regdomain/country of wifi when i set up wifi

Shouldn't there be some documentation available?

> my wifi works in buster, how to find out regdomain/country it uses?

Try this:

root@redacted:~# iw phy phy0 reg get
global
country 00: DFS-UNSET
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
(5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR

(57240 - 63720 @ 2160), (N/A, 0), (N/A)

> but ifconfig isn't available in buster

I doubt that ifconfig is aware of such information.

Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

[Greg Wooledge]

On Sat, May 13, 2023 at 08:29:11PM +0200, to...@tuxteam.de wrote:
> On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> > Ifconfig has been deprecated in Debian for some years.
>
> It is *not* deprecated. It is just optional, not essential.

I don't know what Debian's official stance is, but if you do web searches
for "Linux ifconfig deprecated", you find MANY results.

<https://www.redhat.com/sysadmin/ifconfig-vs-ip>:
The ip command is the future of network config commands. ifconfig
has been officially deprecated for the ip suite, so while many of
us are still using the old ways, it is time to put those habits to
rest and move on with the world.

<https://en.wikipedia.org/wiki/Ifconfig>:
Many Linux distributions have deprecated the use of ifconfig and route
in favor of the software suite iproute2, such as ArchLinux[3] or RHEL
since version 7,[4] which has been available since 1999 for Linux 2.2.

<https://www.linux.com/training-tutorials/replacing-ifconfig-ip/>:
[...] back around 2009 when the debian-devel mailing list
announced plans on deprecating the net-tools package due to lack of
maintenance. It is now 2015 and net-tools is still around.


Those are the most official-sounding references I can find in a few
minutes.

[debia...@howorth.org.uk]

A couple more useful-looking pages I found that explain some of the
issues and history:

https://phoenixnap.com/kb/ifconfig-command-not-found

https://lwn.net/Articles/710533/

[gene heskett]

On 5/13/23 15:40, Greg Wooledge wrote:
> On Sat, May 13, 2023 at 08:29:11PM +0200, to...@tuxteam.de wrote:
>> On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
>>> Ifconfig has been deprecated in Debian for some years.
>>
>> It is *not* deprecated. It is just optional, not essential.
>
> I don't know what Debian's official stance is, but if you do web searches
> for "Linux ifconfig deprecated", you find MANY results.
>
> <https://www.redhat.com/sysadmin/ifconfig-vs-ip>:
> The ip command is the future of network config commands. ifconfig
> has been officially deprecated for the ip suite, so while many of
> us are still using the old ways, it is time to put those habits to
> rest and move on with the world.

While you are correct, Greg, the lack of documentation to help with that
transition is staggering. They just thru it on the table and didn't even
say use this instead.

>
> <https://en.wikipedia.org/wiki/Ifconfig>:
> Many Linux distributions have deprecated the use of ifconfig and route
> in favor of the software suite iproute2, such as ArchLinux[3] or RHEL
> since version 7,[4] which has been available since 1999 for Linux 2.2.
>
> <https://www.linux.com/training-tutorials/replacing-ifconfig-ip/>:
> [...] back around 2009 when the debian-devel mailing list
> announced plans on deprecating the net-tools package due to lack of
> maintenance. It is now 2015 and net-tools is still around.
>
>
> Those are the most official-sounding references I can find in a few
> minutes.
>

[gene heskett]

On 5/13/23 18:38, hl wrote:
> i try old  FreeBSD-12.4, accept default FCC/US though i am not in US,
> wifi scan succeeds
>
> .
you did not post it all, if unset you can scan which is rx only, you
cannot transmit until its set. That is regulatory edict all over this
particular planet.

[David Wright]

On Sun 14 May 2023 at 06:37:52 (+0800), hl wrote:
> i try old  FreeBSD-12.4, accept default FCC/US though i am not in US,
> wifi scan succeeds

I don't know how freebsd handles this. In linux, setting the wrong
country can only reduce the performance you get, because it's likely
that the equipment you're using is already constrained by its
burned-in regulatory domain, and any limits (to TX power, channels,
etc) are combined. So you might as well get it right.

If the page you cited in your OP is up-to-date, then also bear in mind
that freebsd claims to use different country codes from the usual ISO
ones that linux uses (/usr/share/misc/countries.gz). One of them is
Australia, as it happens, a country partly running 8 hours ahead, like
wherever you are.

Cheers,
David.

[David Wright]

On Sat 13 May 2023 at 18:18:57 (-0400), gene heskett wrote:
> On 5/13/23 15:40, Greg Wooledge wrote:
> > On Sat, May 13, 2023 at 08:29:11PM +0200, to...@tuxteam.de wrote:
> > > On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> > > > Ifconfig has been deprecated in Debian for some years.
> > >
> > > It is *not* deprecated. It is just optional, not essential.
> >
> > I don't know what Debian's official stance is, but if you do web searches
> > for "Linux ifconfig deprecated", you find MANY results.
> >
> > <https://www.redhat.com/sysadmin/ifconfig-vs-ip>:
> > The ip command is the future of network config commands. ifconfig
> > has been officially deprecated for the ip suite, so while many of
> > us are still using the old ways, it is time to put those habits to
> > rest and move on with the world.
>
> While you are correct, Greg, the lack of documentation to help with
> that transition is staggering. They just thru it on the table and
> didn't even say use this instead.

From the way you have quoted, I don't know whether you're complaining
specifically about redhat, but as far as Debian is concerned, it was
well documented in the Release Notes for stretch:

5.1.3. Noteworthy obsolete packages

The following is a list of known and noteworthy obsolete packages
(see Section 4.8, “Obsolete packages” for a description).

The list of obsolete packages includes:

[ … ]

* The net-tools package is being deprecated in favor of
iproute2. See Section 5.3.9, “net-tools will be deprecated in
favor of iproute2” or the Debian reference manual (https://
www.debian.org/doc/manuals/debian-reference/ch05#
_the_low_level_network_configuration) for more information.

[ … ]

5.3.9. net-tools will be deprecated in favor of iproute2

The net-tools package is no longer part of new installations by
default, since its priority has been lowered from important to
optional. Users are instead advised to use the modern iproute2
toolset (which has been part of new installs for several releases
already). If you still prefer to continue using the net-tools
programs you can simply install it via

apt install net-tools

Warning

Please keep in mind that net-tools may be uninstalled during the
upgrade if it was only installed to satisfy a dependency. If you
rely on net-tools, please remember to mark it as a manual
installed package before the upgrade via:

apt-mark manual net-tools

Here is a summary of the net-tools commands, together with their
iproute2 equivalent:

+---------------------------------------------------------------+
| legacy | |
| net-tools | iproute2 replacement commands |
| commands | |
|--------------+------------------------------------------------|
|arp |ip n (ip neighbor) |
|--------------+------------------------------------------------|
|ifconfig |ip a (ip addr), ip link, ip -s (ip -stats) |
|--------------+------------------------------------------------|
|iptunnel |ip tunnel |
|--------------+------------------------------------------------|
|nameif |ip link |
|--------------+------------------------------------------------|
|netstat |ss, ip route (for netstat -r), ip -s link (for |
| |netstat -i), ip maddr (for netstat -g) |
|--------------+------------------------------------------------|
|route |ip r (ip route) |
+---------------------------------------------------------------+

I posted this for you a few years ago:

https://lists.debian.org/debian-user/2019/05/msg00868.html

But all this is moot, like most of this thread, because one or two
posts already mentioned iw and regdbdump as the tools of choice.

Cheers,
David.

[to...@tuxteam.de]

On Sat, May 13, 2023 at 03:39:50PM -0400, Greg Wooledge wrote:
> On Sat, May 13, 2023 at 08:29:11PM +0200, to...@tuxteam.de wrote:
> > On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> > > Ifconfig has been deprecated in Debian for some years.
> >
> > It is *not* deprecated. It is just optional, not essential.
>
> I don't know what Debian's official stance is, but if you do web searches
> for "Linux ifconfig deprecated", you find MANY results.

[...]

> Those are the most official-sounding references I can find in a few
> minutes.

So Redhat. But hey, look at packages.debian.org (I know, looking at
a Debian resource is totally... counterintuitive). Net-tools seems
active as of currently, has an upstream, there are bug reports worked
on, and testing has a major version upgrade wrt. stable.

Just because some is "on the internet" it isn't necessarily true
(I'd propose "argumentum ad internetum" for that ;-)

So no, it doesn't look dead to me. Whatever Redhat and Arch think
they think.

Cheers
--
t

[Vincent Lefevre]

On 2023-05-13 10:47:33 -0400, gene heskett wrote:
> On 5/13/23 06:04, Vincent Lefevre wrote:
> > On 2023-05-13 17:56:48 +0800, jeremy ardley wrote:
> > >
> > > On 13/5/23 17:51, Nicolas George wrote:
> > > > Also, ifconfig has nothing to do with wireless, so it was a red herring
> > > > from the start.
> > >
> > > wlan0 is an interface like any other and ifconfig works with it
> >
> > For me, since the wireless interface is wlp61s0:
> >
> > zira:~> ifconfig wlp61s0 list countries
> > list: Unknown host
> > ifconfig: `--help' gives usage information.
> >
> > What you gave is unknown to ifconfig.
> >
> So also is wlan0 or any other name that may have been assigned to the radio.
> Radio's are unk to ifconfig today. So it is worthless to the OP.

This isn't related to the radio. This is a syntax issue. See the
"ifconfig --help" output: there is no such thing as "list", whatever
the interface. Hence the "list: Unknown host", because ifconfig
thinks that "list" is a hostname.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre]

On 2023-05-13 10:43:54 -0400, gene heskett wrote:
> On 5/13/23 06:02, Jeremy Ardley wrote:
> >
> > On 13/5/23 17:57, Vincent Lefevre wrote:
> > > Moreover, it should not be necessary to be root: you are just
> > > reading non-private data. However, "list countries" does not
> > > seem to exist.
> >
> > Debian 11 seems to have a different opinion on who can run ifconfig.
> > Sudo or root is required.
> >
> > jeremy@client:~$ ifconfig enp8s0
> > bash: ifconfig: command not found
> > jeremy@client:~$ sudo ifconfig enp8s0
> > enp8s0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
> >         ether 0c:9d:92:75:b4:f7  txqueuelen 1000  (Ethernet)
> >         RX packets 0  bytes 0 (0.0 B)
> >         RX errors 0  dropped 0  overruns 0  frame 0
> >         TX packets 0  bytes 0 (0.0 B)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> That is not a radio interface, so for the OP use is just noise.

The fact that ifconfig can be found in the run path or not is not
related to whether it is used with a radio interface.

[to...@tuxteam.de]

On Sat, May 13, 2023 at 11:00:23PM -0500, David Wright wrote:

[...]

> 5.1.3. Noteworthy obsolete packages
>
> The following is a list of known and noteworthy obsolete packages
> (see Section 4.8, “Obsolete packages” for a description).

[...]

Now this one has more substance. It seems to me, though, that
upstream found maintainers and someone in Debian cares enough
to keep the package alive -- so it went from deprecated to
just non-default.

Cheers
--
t

[Vincent Lefevre]

On 2023-05-13 18:41:12 +0800, hl wrote:

> On 5/13/23 18:01, Vincent Lefevre wrote:
> > On 2023-05-13 17:19:01 +0800, hl wrote:

> > > but ifconfig isn't available in buster

> > I've used it for many years, and it is still there, currently in
> > the net-tools package (try "apt-file search bin/ifconfig").
> >

> Thank Vincent! i install net-tools, but it doesn't work as i have hoped
>
> root@debian:~# /sbin/ifconfig  wlx12345 list regdomain

> list: Unknown host
> ifconfig: `--help' gives usage information.

> root@debian:~#

Indeed, "ifconfig --help" doesn't mention a "list" feature.
ifconfig accepts some other keywords, otherwise an address
(possibly specified as a hostname), hence the "Unknown host"
error.

[David Wright]

On Sun 14 May 2023 at 07:10:02 (+0200), Vincent Lefevre wrote:
> On 2023-05-13 18:41:12 +0800, hl wrote:
> > On 5/13/23 18:01, Vincent Lefevre wrote:
> > > On 2023-05-13 17:19:01 +0800, hl wrote:
> > > > but ifconfig isn't available in buster
> > > I've used it for many years, and it is still there, currently in
> > > the net-tools package (try "apt-file search bin/ifconfig").
> > >
> > Thank Vincent! i install net-tools, but it doesn't work as i have hoped
> >
> > root@debian:~# /sbin/ifconfig  wlx12345 list regdomain
> > list: Unknown host
> > ifconfig: `--help' gives usage information.
> > root@debian:~#
>
> Indeed, "ifconfig --help" doesn't mention a "list" feature.
> ifconfig accepts some other keywords, otherwise an address
> (possibly specified as a hostname), hence the "Unknown host"
> error.

The OP is on freebsd. It seems every linux/unix has its own
version of ifconfig, all different.

Cheers,
David.

[David Wright]

In 2009, the path ahead was outlined in:

https://lists.debian.org/debian-devel/2009/03/msg00780.html

but I don't think some of the options (like wrappers) are under
consideration after more than a decade of parallel working with ip.

This opinion raised a chuckle in the lwn article:

"But I'm not seeing any real advantage here. Sure,
ifconfig doesn't support all the new networking features,
but basic "ifconfig blah0 up" still works just fine.

Cheers,
David.

[Andy Smith]

Hello,

On Sun, May 14, 2023 at 06:48:59AM +0200, to...@tuxteam.de wrote:
> So no, it doesn't look dead to me.

It (Linux ifconfig) exists and is still installable but will not be
getting any new features. It also displays incorrect information for
some features it does not understand.

So the arguments for its continued usage are extremely tenuous and
basically boil down to, "it's always worked for me!" Which is fine,
but does lead to situations like this where we have a whole thread
of confusion about why it doesn't have some particular feature that
a user, who was not aware that ifconfig is no longer the thing to
use, continued to try to use it.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Andy Smith]

Hello,

On Sat, May 13, 2023 at 06:18:57PM -0400, gene heskett wrote:
> On 5/13/23 15:40, Greg Wooledge wrote:
> > <https://www.redhat.com/sysadmin/ifconfig-vs-ip>:
> > The ip command is the future of network config commands. ifconfig
> > has been officially deprecated for the ip suite, so while many of
> > us are still using the old ways, it is time to put those habits to
> > rest and move on with the world.
>
> While you are correct, Greg, the lack of documentation to help with that
> transition is staggering. They just thru it on the table and didn't even say
> use this instead.

This is not true. The first hit on most web searches for "linux wifi
regulatory domain" will be the "iw" command.

Both you and the OP have been sidetracked (blinded?) by assumptions
that iufconfig is and will always be the command to use, and then
gave up without doing any further research,

Elsewhere in this thread copious links to documentation from Red Hat
and Arch were posted, to which the old guard say, "don't believe
everything you read on the web".

Live in the 20th century if you want, but don't tell me the
information isn't out there.

Thanks,

[Curt]

On 2023-05-14, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
> So Redhat. But hey, look at packages.debian.org (I know, looking at

https://wiki.debian.org/NetToolsDeprecation

https://lists.debian.org/debian-devel/2009/03/msg00780.html

2009!!

Luk Claes and me, as the current maintainers of net-tools, we've been
thinking about it's future. Net-tools has been a core part of Debian and any
other linux based distro for many years, but it's showing its age.

It doesnt support many of the modern features of the linux kernel, the
interface is far from optimal and difficult to use in automatisation, and also,
it hasn't got much love in the last years.

On the other side, the iproute suite, introduced around the 2.2 kernel
line, has both a much better and consistent interface, is more powerful, and is
almost ten years old, so nobody would say it's untested.

Hence, our plans are to replace net-tools completely with iproute, maybe
leading the route for other distributions to follow. Of course, most people and
tools use and remember the venerable old interface, so the first step would be
to write wrappers, trying to be compatible with net-tools.

At the same time, we believe that most packages using net-tools should be
patched to use iproute instead, while others can continue using the wrappers
for some time. The ifupdown package is obviously the first candidate, but it
seems that a version using iproute has been available in experimental since
2007.

[gene heskett]

That is all fine & dandy Andy, but how about replacing ifconfig with a
bash script that recommends to the user, ip for hard wired stuff, iw for
radio stuff. User education solved in one swell foop. Makes perfect
sense to me.

[to...@tuxteam.de]

I think the problem here is that the user dreamt up a feature ifconfig
has never had. At least not the linux ifconfig.

Cheers
--
t

[to...@tuxteam.de]

On Sun, May 14, 2023 at 04:27:31PM -0000, Curt wrote:
> On 2023-05-14, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
> >
> > So Redhat. But hey, look at packages.debian.org (I know, looking at
>
> https://wiki.debian.org/NetToolsDeprecation
>
> https://lists.debian.org/debian-devel/2009/03/msg00780.html
>
> 2009!!
>
> Luk Claes and me, as the current maintainers of net-tools, we've been
> thinking about it's future. Net-tools has been a core part of Debian and any
> other linux based distro for many years, but it's showing its age.

Thanks for the interesting data point. History seems to have unfolded
differently from plan (happens all the time :) but it wouldn't be too
late to fix.

Who is writing the wrappers?

Cheers
--
t

[gene heskett]

All are good ideas, Curt, but the power in iproute is, maybe now s/b was
lacking, I've literally spent a frigging week trying to get iproute to
over-ride the broken 169.xx.xx.xx primary route that earlier avahi's
insisted on putting into a network config, that is why to this day the
first thing I do after an install, is find avahi and rm it and reboot.
rm because you could not remove it with apt w/o tearing down the system
far enough the only recourse was to reinstall. That is obviously an
endless loop.

I find that in bullseye, finally, avahi has developed some manners in
that it is now happy to the the 2nd route. Ditto for NM, it finally
after a decade of insisting it be done its way even when its way didn't
work, so that stuff got fixed and immediately a "sudo chattr +i" applied
so NM could not screw it up. Fortunately, NM had the good graces not to
flood the logs with "I can't screw it up" complaints.

So while we are making progress in just works networking and its not
nice to dig up old dirt, but why did it take 10 years to get those
major, show stopping problems fixed? That's what I have failed to
understand. I've been networking stuff since the middle 80's, Went from
os9 level 1 on an original coco,then level 2 on a coco3 to amigados,
running exclusively linux since 1998, I've seen kernel bugs get fixed in
an hour so why did it take a decade to fix that show stopper routing
problem? I think that is a legitimate question.

[David Wright]

On Sun 14 May 2023 at 16:27:31 (-0000), Curt wrote:
> Hence, our plans are to replace net-tools completely with iproute, maybe
> leading the route for other distributions to follow. Of course, most people and
> tools use and remember the venerable old interface, so the first step would be
> to write wrappers, trying to be compatible with net-tools.
>
> At the same time, we believe that most packages using net-tools should be
> patched to use iproute instead, while others can continue using the wrappers
> for some time. The ifupdown package is obviously the first candidate, but it
> seems that a version using iproute has been available in experimental since
> 2007.

On Sun 14 May 2023 at 20:11:28 (+0200), to...@tuxteam.de wrote:
> Thanks for the interesting data point. History seems to have unfolded
> differently from plan (happens all the time :) but it wouldn't be too
> late to fix.
>
> Who is writing the wrappers?

In 2023?

"Debian, as it happens, is having this discussion a bit late.
OpenSUSE discussed removing net-tools in 2009, but has not
done so. Red Hat and Fedora got serious in 2011, and the
RHEL 7 release no longer installs net-tools by default.
The fact that this change is not universally popular shows
how reluctant users can be to let go of their long-used tools."

AIUI people thought patching software that used net-tools was more
productive than writing and supporting wrappers.

"Distributors have to choose where to expend their energy,
and there will come a point where dragging along obsoleted
tools that the old folks want falls off the list."

Final thought from this (lwn) source:

"Software transitions like this are invariably an unwanted
distraction for users who are uninterested in whatever new
features are available and would prefer that their systems
(and their habits) just continue to work. But the world we
live in does not stand still, so such transitions are simply
going to happen, and distributors will find themselves caught
in the middle. As those distributors strive to keep everybody
happy, we should not be surprised to see more of these
transitions take a decade or more."

Cheers,
David.

[Jeffrey Walton]

On Sat, May 13, 2023 at 5:35 AM hl <hlyg...@outlook.com> wrote:
>
> freebsd ask me regdomain/country of wifi when i set up wifi
>

> my wifi works in buster, how to find out regdomain/country it uses?
>

> https://wiki.freebsd.org/action/show/WiFi/RegulatoryDomainSupport?action=show&redirect=WiFiRegulatory
>
> To view the current list of regulatory domains and SKUs:
>
> # ifconfig wlan0 list countries
>
> To view the current regulatory domain frequency and operating modes:
>
> # ifconfig wlan0 list regdomain

>
> but ifconfig isn't available in buster

Boy, this thread reached critical mass and melted down quickly...

Is this going to be another thread that never dies :)

[Andy Smith]

Hello,

On Sun, May 14, 2023 at 01:41:40PM -0400, gene heskett wrote:
> On 5/14/23 12:09, Andy Smith wrote:
> > the arguments for its continued usage are extremely tenuous and
> > basically boil down to, "it's always worked for me!" Which is
> > fine, but does lead to situations like this where we have a
> > whole thread of confusion about why it doesn't have some
> > particular feature that a user, who was not aware that ifconfig
> > is no longer the thing to use, continued to try to use it.
> >

> That is all fine & dandy Andy, but how about replacing ifconfig with a bash
> script that recommends to the user, ip for hard wired stuff, iw for radio
> stuff. User education solved in one swell foop. Makes perfect sense to me.

By all means contact the current maintainers of net-tools and say
something like

On behalf of experienced ifconfig users who also won't read
manuals or do the simplest of Internet searches, please will you
implement every command and feature of FreeBSD ifconfig but with
prompts that direct the user to the appropriate command in
Linux, for example if I type "ifconfig wlan0 list" then if wlan0
is a valid wifi interface I want it to respond with "The correct
tool for this on Linux is iw" instead of interpreting "list" as
a hostname like Linux ifconfig did before wifi was a thing.

I am guessing for an even split between:

- No I don't feel like that is a good use of my time, sorry

and

- I hate this suggestion and think experienced ifconfig users should
be able to work things out for themselves

but I'm not one of those maintainers so what I think matters very
little, those are just my predictions. Sending your suggestions
anywhere else (such as debian-user) will do no good whatsoever.

Personally I think time is better spent doing a 5 second search and
moving on with life.

Every thread about ifconfig now is just people wishing that other
people would do some work to keep it alive, when it's so far dead
that even mentioning it is now a distraction for people coming into
this after the thing ceased being relevant. The OP's user experience
would have been clearly better had there been no ifconfig command
even present in Debian - they would have been forced to search for
the correct command and would have found it very easily.

Thanks,

[Andy Smith]

Hello,

On Sun, May 14, 2023 at 08:08:06PM +0200, to...@tuxteam.de wrote:
> I think the problem here is that the user dreamt up a feature ifconfig
> has never had. At least not the linux ifconfig.

Yes, it seems their use of FreeBSD ifconfig led them to believe that
ifconfig would work the same on every platform.

So would you agree that had Debian NOT given in to the people who
demanded ifconfig remain packaged, OP would have been in a better
position as then they would have known that ifconfig is not the
command they need in Debian even if it is in FreeBSD?

(Making net-tools ifconfig behave the way FreeBSD ifconfig does is
presumably not an option on the table since clearly no one wants to
do that work, and anyway possibly there are yet some other platforms
that have an ifconfig that behaves differently again.)

Thanks,

[Andy Smith]

Dear debian-user archives,

On Sun, May 14, 2023 at 02:42:05PM -0400, gene heskett wrote:
> I've literally spent a frigging week trying to get iproute to
> over-ride the broken 169.xx.xx.xx primary route that earlier
> avahi's insisted on putting into a network config, that is why to
> this day the first thing I do after an install, is find avahi and
> rm it and reboot. rm because you could not remove it with apt w/o
> tearing down the system far enough the only recourse was to
> reinstall. That is obviously an endless loop.

Routine note for the archive that avahi is another one of Gene's
Demons and the above is not in any way true. I have 50+ Debian hosts
that do not have avahi installed at all, and several more that
intentionally do and work fine.

As usual, Gene's experiences are due to a misconfiguration that
Gene made and cannot be helped with, despite many people trying over
a period of years.

When you see a post from Gene mentioning liberal use of "rm" and
"chattr +i" on parts of the operating system, do begin to question
what you are reading.

[gene heskett]

Thanks for the vote of no confidence Andy.

The diff as I see it, is that I refuse to actually run a dns server
here, bind and I agreed to disagree nearly 25 years ago when bind was at
4 something and half the planet was cleaning after attacks on bind. The
other half wasn't aware of anything except the net was dead, no dns.

The box in question was running rh 6.1 so that might give you a time
frame. 2001 maybe. IDK, IDC.

We bought a block of 16 ipv4 addresses and registered & ran the tv
stations net access, about 40 mostly windoze boxes preferring /etc/host
files for local lookups. It works if the router relays, its fast, and
bulletproof. The way I've configured is to first check the hosts file
for a match, and failing that, fwd the lookup request to my dd-wrt
router, and if dnsmasq doesn't know it, forward it to my ISP. And its
all transparent in about 30 milliseconds. The reason I used rm on it is
because back about wheezy I tried to remove it with apt, and its
dependencies took 247 other packages with it totally killing the system.

I screamed about it at the time, years ago, everybody sneered and made
fun of me, and ever so slowly the dependencies went away and I can now
remove it with apt, but it appears I no longer need to. So it has been
reinstalled.

Take care & stay well Andy.

[to...@tuxteam.de]

On Sun, May 14, 2023 at 01:59:10PM -0500, David Wright wrote:

[...]

> Final thought from this (lwn) source:
>
> "Software transitions like this are invariably an unwanted

> distraction [...] But the world we live in does not stand
> still, so such transitions are simply going to happen [...]

To me, this seems like an unnecessary authoritarian stance,
which, in free software's context seems strange.

As long as there are maintainers and upstream I see no reason
to drop a package.

Which one is the default, of course, is a decision to be taken
by the distribution as a whole. After all, the system scripts
have to be adapted to it.

And whining is not maintaining, so if someone really wants the
package, (s)he better puts the keyboard where the mouth is :)

Cheers
--
t

[to...@tuxteam.de]

On Sun, May 14, 2023 at 03:44:42PM -0400, Jeffrey Walton wrote:

[...]

> Boy, this thread reached critical mass and melted down quickly...

Probably with a reason (OK, there were some blind alleys
around, as that one giving ifconfig powers it never had,
at least in Linux distros), but those transitions are
always big social events. No wonder there's discussion.

I think this is healthy.

> Is this going to be another thread that never dies :)

With a live community you get that from time to time.
People have been polite all along, as far as I can see.
What's not to like?

Cheers
--
t

[to...@tuxteam.de]

On Sun, May 14, 2023 at 09:11:55PM +0000, Andy Smith wrote:
> Hello,
>
> On Sun, May 14, 2023 at 08:08:06PM +0200, to...@tuxteam.de wrote:
> > I think the problem here is that the user dreamt up a feature ifconfig
> > has never had. At least not the linux ifconfig.
>
> Yes, it seems their use of FreeBSD ifconfig led them to believe that
> ifconfig would work the same on every platform.
>
> So would you agree that had Debian NOT given in to the people who
> demanded ifconfig remain packaged, OP would have been in a better
> position as then they would have known that ifconfig is not the
> command they need in Debian even if it is in FreeBSD?

As I mentioned in another post -- no, I don't like authoritarian
approaches. As long as someone's willing to keep the thing alive
(upstream and packaging) it should exist.

Cheers
--
t

[David Wright]

On Mon 15 May 2023 at 06:37:32 (+0200), to...@tuxteam.de wrote:
> On Sun, May 14, 2023 at 01:59:10PM -0500, David Wright wrote:
>
> [...]
>
> > Final thought from this (lwn) source:
> >
> > "Software transitions like this are invariably an unwanted
> > distraction [...] But the world we live in does not stand
> > still, so such transitions are simply going to happen [...]
>
> To me, this seems like an unnecessary authoritarian stance,
> which, in free software's context seems strange.
>
> As long as there are maintainers and upstream I see no reason
> to drop a package.

It doesn't necessarily imply dropping any package, but just that
if a new package is written that handles cases that the old
package can't, then gradually the old package may break under
various circumstances, and the people who might have fixed it
may have moved on.

AIUI, in the packages under discussion, ifconfig both lacks
netlink support, and produces wrong information when it
encounters information it doesn't understand. So the transition
is not just because "ip is better than ifconfig", but because
ifconfig just isn't up to it in certain situations.

> Which one is the default, of course, is a decision to be taken
> by the distribution as a whole. After all, the system scripts
> have to be adapted to it.

Choosing ifconfig as the default would be a strange choice indeed.

> And whining is not maintaining, so if someone really wants the
> package, (s)he better puts the keyboard where the mouth is :)

I read somewhere that the recent tweaks (improvements?) to
ifconfig's output were breaking scripts, which is hardly surprising.

Cheers,
David.

[Tom Dial]

Sometimes I can't resist ...

I've been running DNS on two or three local hosts for around 25 years, roughly since the number of images on my local net grew beyond about 4 or 5. I don't knowingly allow access from the public Internet or configure it to resolve any but local addresses. As I recall, I set it up based on the Debian HOWTO of the time, it worked upon deployment, it never has faulted except for hardware failure or my own mistypes. It is as easy to maintain as two or three hosts files, and easier to maintain consistency across what now are a couple of dozen system images.

Rejecting DNS now, and for local use, because there were failures or successful or unsuccessful attacks on public DNS servers a quarter century ago makes no sense.

>
> The box in question was running rh 6.1 so that might give you a time frame. 2001 maybe. IDK, IDC.
>
> We bought a block of 16 ipv4 addresses and registered & ran the tv stations net access, about 40 mostly windoze boxes preferring /etc/host files for local lookups. It works if the router relays, its fast, and bulletproof. The way I've configured is to first check the hosts file for a match, and failing that, fwd the lookup request to my dd-wrt router, and if dnsmasq doesn't know it, forward it to my ISP. And its all transparent in about 30 milliseconds.  The reason I used rm on it is because back about wheezy I tried to remove it with apt, and its dependencies took 247 other packages with it totally killing the system.

DNS performs similarly to hosts files, is not hard to set up, and is easier to maintain once set up.

I checked a couple of my images and found they have one or more avahi* packages installed (avahi-daemon is there in all cases, I assume due to a connection with installation of CUPS). CUPS works fine, and if Ahavi contributes to that, it's fine by me.

>
> I screamed about it at the time, years ago, everybody sneered and made fun of me, and ever so slowly the dependencies went away and I can now remove it with apt, but it appears I no longer need to. So it has been reinstalled.

On several of my system images, removing avahi-daemon would also remove Gnome, so I wouldn't do it. But I have found no need: the only times I have noticed 169.x.x.x IPv4 addresses is when something went wrong with network setup at boot, mostly cable or switch malfunctions.

>
> Take care & stay well Andy.
>
> Cheers, Gene Heskett.

Regards,
Tom Dial

[Vincent Lefevre]

On 2023-05-13 23:00:23 -0500, David Wright wrote:

> On Sat 13 May 2023 at 18:18:57 (-0400), gene heskett wrote:
> > On 5/13/23 15:40, Greg Wooledge wrote:

> > > On Sat, May 13, 2023 at 08:29:11PM +0200, to...@tuxteam.de wrote:
> > > > On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> > > > > Ifconfig has been deprecated in Debian for some years.
> > > >
> > > > It is *not* deprecated. It is just optional, not essential.
> > >
> > > I don't know what Debian's official stance is, but if you do web searches
> > > for "Linux ifconfig deprecated", you find MANY results.
> > >

> > > <https://www.redhat.com/sysadmin/ifconfig-vs-ip>:
> > > The ip command is the future of network config commands. ifconfig
> > > has been officially deprecated for the ip suite, so while many of
> > > us are still using the old ways, it is time to put those habits to
> > > rest and move on with the world.
> >
> > While you are correct, Greg, the lack of documentation to help with
> > that transition is staggering. They just thru it on the table and
> > didn't even say use this instead.
>

> From the way you have quoted, I don't know whether you're complaining
> specifically about redhat, but as far as Debian is concerned, it was
> well documented in the Release Notes for stretch:

>
> 5.1.3. Noteworthy obsolete packages
>
> The following is a list of known and noteworthy obsolete packages
> (see Section 4.8, “Obsolete packages” for a description).
>

> The list of obsolete packages includes:
>
> [ … ]
>
> * The net-tools package is being deprecated in favor of
> iproute2. See Section 5.3.9, “net-tools will be deprecated in
> favor of iproute2” or the Debian reference manual (https://
> www.debian.org/doc/manuals/debian-reference/ch05#
> _the_low_level_network_configuration) for more information.
>
> [ … ]
>
> 5.3.9. net-tools will be deprecated in favor of iproute2
>
> The net-tools package is no longer part of new installations by
> default, since its priority has been lowered from important to
> optional.
[...]

Under Debian/unstable, i.e. more much recent than stretch:

zira:~> dpkg -s net-tools
Package: net-tools
Status: install ok installed
Priority: important
[...]

This is still priority important!

[Greg Wooledge]

On Mon, May 15, 2023 at 12:10:13AM -0500, David Wright wrote:
> I read somewhere that the recent tweaks (improvements?) to
> ifconfig's output were breaking scripts, which is hardly surprising.

I can personally confirm this as true. Some of the machines at work
run a proprietary software product that uses a license key, tied to
the machine's ethernet interface's MAC address. The vendor's script
runs ifconfig and tries to parse the output to get the MAC address.
This script fails on the recent versions of net-tools.

[David Wright]

Not at all; AFAICT, the /internal/ Priority of the package has never
changed. (Just guessing: if you installed it, you need it, and better
hang on to it.) But as far as installing it in the first place, that's
the role of the Packages file, where it is optional (plus you might
install it as a dependency).

Cheers,
David.

[Vincent Lefevre]

But this is what the user sees.

> (Just guessing: if you installed it, you need it, and better
> hang on to it.)

Wrong. It got installed automatically. I suppose that this is because
this was like that in the past, when I installed the machine in 2015,
thus before stretch was out. I suspect that it wasn't removed because
of the remaining "Recommends" from pbuilder:

zira:~> aptitude why net-tools
i pbuilder Recommends net-tools | iproute2

Note: iproute2 is installed too, but net-tools gets the preference.
This "Recommends" is rather strange if iproute2 is supposed to be
better!

[Andy Smith]

Hello,

On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > (Just guessing: if you installed it, you need it, and better
> > hang on to it.)
>
> Wrong. It got installed automatically. I suppose that this is because
> this was like that in the past, when I installed the machine in 2015,
> thus before stretch was out.

If you mean that it got installed automatically in an older install,
before the package was made optional, and then never removed, this
would make sense as things don't get removed on upgrades unless
there is a conflict. You even retain packages that are no longer in
Debian.

Most of my long-upgraded systems still have it, but newer installs
don't.

Some of my third party (i.e. not on my own hypervisor) bullseye VMs
have it because they have cloud-init, which in bullseye depends on
net-tools. Even though I don't use cloud-init. I see that in
bookworm cloud-init no longer depends upon net-tools, so there's
another route to install gone.

I'm sure there's still a lot of cases where it's pulled in as a
possible dependency but never knowingly used.

Cheers,

[Vincent Lefevre]

On 2023-05-15 15:09:24 +0000, Andy Smith wrote:
> On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> > Wrong. It got installed automatically. I suppose that this is because
> > this was like that in the past, when I installed the machine in 2015,
> > thus before stretch was out.
>
> If you mean that it got installed automatically in an older install,
> before the package was made optional, and then never removed, this
> would make sense as things don't get removed on upgrades unless
> there is a conflict. You even retain packages that are no longer in
> Debian.

No, aptitude removes automatically installed packages for which
there are no longer any dependencies.

[Vincent Lefevre]

On 2023-05-15 17:13:31 +0200, Vincent Lefevre wrote:
> On 2023-05-15 15:09:24 +0000, Andy Smith wrote:
> > On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> > > Wrong. It got installed automatically. I suppose that this is because
> > > this was like that in the past, when I installed the machine in 2015,
> > > thus before stretch was out.
> >
> > If you mean that it got installed automatically in an older install,
> > before the package was made optional, and then never removed, this
> > would make sense as things don't get removed on upgrades unless
> > there is a conflict. You even retain packages that are no longer in
> > Debian.
>
> No, aptitude removes automatically installed packages for which
> there are no longer any dependencies.

And there's also "apt autoremove", which I also use. The issue
for net-tools is that there is still a dependency (Recommends)
from pbuilder.

[Andy Smith]

Hello,

On Mon, May 15, 2023 at 05:15:58PM +0200, Vincent Lefevre wrote:
> On 2023-05-15 17:13:31 +0200, Vincent Lefevre wrote:
> > No, aptitude removes automatically installed packages for which
> > there are no longer any dependencies.
>
> And there's also "apt autoremove", which I also use. The issue
> for net-tools is that there is still a dependency (Recommends)
> from pbuilder.

Ah okay, my mistake. I only ever use the "aptitude why" part of
aptitude.

"Recommends" are quite liberally used on Debian so I expect that
will account for net-tools being retained in a lot of cases.

[gene heskett]

> .
One might be able to fix that with hexedit or a clone, by changing the
string causing the error back to the original version? Fix the files crc
of course. Better yet, dl the src, find that string and change it back
to the original, recompile and re-install. I note that today. neither
tool calls the MAC address MAC, and that ip and ifconfig label it with
different names. That s/b a std but insert the xckb reference to std's,
old even wrong ones never die...

This method of software protection, from my experience as broadcast
engineer, can be costly when it fails, and fixing what you paid good
money for in the faith that it would work forever but fails regularly
for whatever reason. And our copyright laws do not contain that I know
of, a provision to allow the possession of a canceled check to be
substituted for whatever scheme the vendor comes up with to enforce his
copyright. Disney got exactly what he asked for.

We at one time in the early 90's bought an editing system that had the
key buried in the serial port adapter that was used to control the tape
machines. With a limited life. The outfit was able to supply a new
adaptor, once, but had to drive the height of FL to get it from the
author of the scheme. And it was his only copy. Lasted about a month
and once again we had $25,000 worth of disabled software.

In a tv stations production dept, that's a major income hit. At that
time I knew a uni prof in germany who was pretty good at fixing buggy
amiga software, so w/o naming names I told the vendor it was not going
to be tuff excrement to us but to them, but that I would remove their
broken key and continue to use the software we had paid good money for 6
months earlier. Lots of sputtering, I hung up in the middle of it and
emailed the sw to the prof, had it back with a try this about 6 hours
later but he missed a third check, so had to go back and search thru it
again, finding the last check and nulling it out. We used the hacked
version for about a year, till we upgraded the editing machines and
never heard from that vendor again. I heard later thru the grapevine
that the vendor filed shortly after that. The hacked copy never left
the premises so as far as I was concerned the copyright was honored.

The point is that what can be done in software, can also be undone.

[Jeffrey Walton]

On Mon, May 15, 2023 at 12:01 PM gene heskett <ghes...@shentel.net> wrote:
> [...]

> The point is that what can be done in software, can also be undone.

I spent a lot of time on Fravia's site back in the 1990's. There was
no protection scheme we couldn't break. Or I don't recall one.

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

Jeff

[Greg Wooledge]

On Mon, May 15, 2023 at 12:00:36PM -0400, gene heskett wrote:
> On 5/15/23 07:03, Greg Wooledge wrote:
> > On Mon, May 15, 2023 at 12:10:13AM -0500, David Wright wrote:
> > > I read somewhere that the recent tweaks (improvements?) to
> > > ifconfig's output were breaking scripts, which is hardly surprising.
> >
> > I can personally confirm this as true. Some of the machines at work
> > run a proprietary software product that uses a license key, tied to
> > the machine's ethernet interface's MAC address. The vendor's script
> > runs ifconfig and tries to parse the output to get the MAC address.
> > This script fails on the recent versions of net-tools.
> >
> > .
> One might be able to fix that with hexedit or a clone, by changing the

[...]

Thanks, but I don't require any assistance with this. I simply told
the vendor what the correct IP address and MAC address are. (They're
a small company, and we have direct contact with them.)

I was simply confirming that yes, the changes to net-tools did in fact
break some real-world scripts.

[Celejar]

On Sat, 13 May 2023 20:29:11 +0200

<to...@tuxteam.de> wrote:

> On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:

> > On Sat, May 13, 2023, 5:23 AM Jeremy Ardley <jer...@ardley.org> wrote:
> >
> > >
> > > On 13/5/23 18:17, Nicolas George wrote:
> > > > This is your interpretation, not an official stance. It might as well be
> > > > that they considered polluting the completion namespace of users with a
> > > > command they rarely need was less convenient.
> > >
> > > The actual reason is they have deprecated it in favour of the ip command
> > > but left it available for now with a bit of searching.

> > >
> >
> > Ifconfig has been deprecated in Debian for some years.
>

> It is *not* deprecated. It is just optional, not essential. As is the
> Gnu C compiler or Lua or... you name it. If you need it, you install
> it. It is in stable (version 1.60), coming in testing (v 2.10) and is
> in unstable. It is not going away, folks!

We can quibble about the term "deprecated," but the official Debian
Reference Manual repeatedly calls it "obsolete":

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html

--
Celejar

[David Wright]

On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > Under Debian/unstable, i.e. more much recent than stretch:
> > >
> > > zira:~> dpkg -s net-tools
> > > Package: net-tools
> > > Status: install ok installed
> > > Priority: important
> > > [...]
> > >
> > > This is still priority important!
> >
> > Not at all; AFAICT, the /internal/ Priority of the package has never
> > changed.
>
> But this is what the user sees.
>
> > (Just guessing: if you installed it, you need it, and better
> > hang on to it.)
>
> Wrong. It got installed automatically. I suppose that this is because
> this was like that in the past, when I installed the machine in 2015,
> thus before stretch was out.

Of course, how stupid of me—I should have known that from your post
about a system running sid (quoted above in its entirety).

> I suspect that it wasn't removed because
> of the remaining "Recommends" from pbuilder:
>
> zira:~> aptitude why net-tools
> i pbuilder Recommends net-tools | iproute2
>
> Note: iproute2 is installed too, but net-tools gets the preference.
> This "Recommends" is rather strange if iproute2 is supposed to be
> better!

That's a very odd recommendation: it's difficult to envisage someone
building packages on a system that doesn't have all the packages with
Priority important already installed.

And I haven't seen where any ranking should be understood from
the ordering of Recommends alternatives.

And AIUI aptitude why picks an arbitrary choice from equally
strong dependencies (sensu lato). There may be others present.

You say your system is pre-stretch, ie jessie. That means that you
will have had both iproute2 and net-tools installed, as in jessie
they are both ranked important. AFAICT iproute2 has never been
ranked lower than that, and its predecessor, iproute, was important
as far back as lenny. (Earlier than that, it could only be optional,
because you needed various options to have been compiled into the
kernel.)

As far as net-tools's survival is concerned, that's up to you.
Debian gives you some tools to help remove cruft, but aggressive
removal from systems could lead to scripts breaking and so on,
particularly where there are Recommends in play.

Cheers,
David.

[Vincent Lefevre]

On 2023-05-15 23:14:30 -0500, David Wright wrote:
> On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> > On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > > Under Debian/unstable, i.e. more much recent than stretch:
> > > >
> > > > zira:~> dpkg -s net-tools
> > > > Package: net-tools
> > > > Status: install ok installed
> > > > Priority: important
> > > > [...]
> > > >
> > > > This is still priority important!
> > >
> > > Not at all; AFAICT, the /internal/ Priority of the package has never
> > > changed.
> >
> > But this is what the user sees.
> >
> > > (Just guessing: if you installed it, you need it, and better
> > > hang on to it.)
> >
> > Wrong. It got installed automatically. I suppose that this is because
> > this was like that in the past, when I installed the machine in 2015,
> > thus before stretch was out.
>
> Of course, how stupid of me—I should have known that from your post
> about a system running sid (quoted above in its entirety).

Well, you should never try to guess, unless the guess is obvious.
BTW, I don't think that sid matters here; just the fact that the
machine was installed before stretch and that there is a current
dependency.

> > I suspect that it wasn't removed because
> > of the remaining "Recommends" from pbuilder:
> >
> > zira:~> aptitude why net-tools
> > i pbuilder Recommends net-tools | iproute2
> >
> > Note: iproute2 is installed too, but net-tools gets the preference.
> > This "Recommends" is rather strange if iproute2 is supposed to be
> > better!
>
> That's a very odd recommendation: it's difficult to envisage someone
> building packages on a system that doesn't have all the packages with
> Priority important already installed.

I suppose that this may be useful in case the priority is lowered
in the future.

> And I haven't seen where any ranking should be understood from
> the ordering of Recommends alternatives.
>
> And AIUI aptitude why picks an arbitrary choice from equally
> strong dependencies (sensu lato). There may be others present.

I don't know whether this lists all the dependencies (but the
man page uses the plural):

zira:~> deborphan net-tools
net-tools
pbuilder

And this one should give all of them:

zira:~> apt list '?any-version(?installed?depends(?exact-name(net-tools)))'
Listing... Done
zira:~> apt list '?any-version(?installed?recommends(?exact-name(net-tools)))'
Listing... Done
pbuilder/stable,testing,unstable,now 0.231 all [installed]

> You say your system is pre-stretch, ie jessie.

Indeed, it was installed from

http://cdimage.debian.org/debian-cd/8.1.0/amd64/jigdo-dvd/debian-8.1.0-amd64-DVD-1.jigdo

with just "SSH server" and "standard system utilities" in the
installer choices. I upgraded to sid shortly after.

> That means that you will have had both iproute2 and net-tools
> installed, as in jessie they are both ranked important.

Yes, both were installed at install time.

> As far as net-tools's survival is concerned, that's up to you.
> Debian gives you some tools to help remove cruft, but aggressive
> removal from systems could lead to scripts breaking and so on,
> particularly where there are Recommends in play.

I used some net-tools utilities, mainly ifconfig, in the past (on
older machines), but I no longer have any script that depends on
them, and I don't think that this is an issue for pbuilder as the
other ORed recommends will be satisfied.

However, a comment in /etc/postfix/main.cf.proto still mentions
"ifconfig" only (it appears that the corresponding sentence in
the postconf(5) man page was updated, but not this file):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036161

[Anssi Saari]

hl <hlyg...@outlook.com> writes:

> i try old  FreeBSD-12.4, accept default FCC/US though i am not in US,
> wifi scan succeeds

Is it out of the question to actually set the regulatory domain to match
the country you're in?

[David Wright]

On Tue 16 May 2023 at 11:38:27 (+0200), Vincent Lefevre wrote:
> On 2023-05-15 23:14:30 -0500, David Wright wrote:
> > On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> > > On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > > > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > > > Under Debian/unstable, i.e. more much recent than stretch:
> > > > >
> > > > > zira:~> dpkg -s net-tools
> > > > > Package: net-tools
> > > > > Status: install ok installed
> > > > > Priority: important
> > > > > [...]
> > > > >
> > > > > This is still priority important!
> > > >
> > > > Not at all; AFAICT, the /internal/ Priority of the package has never
> > > > changed.
> > >
> > > But this is what the user sees.
> > >
> > > > (Just guessing: if you installed it, you need it, and better
> > > > hang on to it.)
> > >
> > > Wrong. It got installed automatically. I suppose that this is because
> > > this was like that in the past, when I installed the machine in 2015,
> > > thus before stretch was out.
> >
> > Of course, how stupid of me—I should have known that from your post
> > about a system running sid (quoted above in its entirety).
>
> Well, you should never try to guess, unless the guess is obvious.

Well, excuse me, but are you the moderator here? I shall answer
posts in the manner I find appropriate, if you don't mind (and
even if you do).

> BTW, I don't think that sid matters here; just the fact that the
> machine was installed before stretch and that there is a current
> dependency.

Neither of which was mentioned in your post. Does anything in your
post actually matter? It it does, wouldn't it be better to file a
bug against the net-tools control file, rather than spending your
time criticising the fact that I had the temerity to write this
aside in a post:

"(Just guessing: if you installed it, you need it, and better hang on to it.)"

Cheers,
David.