On 8/1/20 7:20 PM, ToddAndMargo via users wrote: > Is there a way to get nmcli to tell you if an interface > is a gateway like you can with `netstat -rn`? Very related to the previous question. # nmcli --fields IP4.GATEWAY d show wlo1 IP4.GATEWAY:                            10.0.1.1 # nmcli --fields IP4.GATEWAY d show lo IP4.GATEWAY:                            --

On 8/1/20 7:20 PM, ToddAndMargo via users wrote: > Is there a way to get nmcli to tell you if an interface > is a gateway like you can with `netstat -rn`? Very related to the previous question. # nmcli --fields IP4.GATEWAY d show wlo1 IP4.GATEWAY:                            10.0.1.1 # nmcli --fields IP4.GATEWAY d show lo IP4.GATEWAY:                            --

On 2020-08-03 07:10, ToddAndMargo via users wrote: > On 2020-08-01 19:42, Samuel Sieb wrote: >> On 8/1/20 7:20 PM, ToddAndMargo via users wrote: >>> Is there a way to get nmcli to tell you if an interface >>> is a gateway like you can with `netstat -rn`? >> >> Very related to the previous question. >> >> # nmcli --fields IP4.GATEWAY d show wlo1 >> IP4.GATEWAY:                            10.0.1.1 >> >> # nmcli --fields IP4.GATEWAY d show lo >> IP4.GATEWAY:                            -- > > Uh Oh! > > This tells me "what" the gateway is, but not > "if" the device is a gateway: > > $ netstat -rn | grep eno2 > 0.0.0.0         192.168.250.1   0.0.0.0         UG        0 0          0 eno2 > 192.168.250.0   0.0.0.0         255.255.255.0   U         0 0          0 eno2 > > > > $ nmcli device show eno2 > GENERAL.DEVICE:                         eno2 > GENERAL.TYPE:                           ethernet > GENERAL.HWADDR:                         AC:1F:6B:62:10:07 > GENERAL.MTU:                            1500 > GENERAL.STATE:                          100 (connected) > GENERAL.CONNECTION:                     eno2 > GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveCo > nnection/5 > WIRED-PROPERTIES.CARRIER:               on > IP4.ADDRESS[1]:                         192.168.250.135/24 > IP4.GATEWAY:                            192.168.250.1 > IP4.ROUTE[1]:                           dst = 192.168.250.0/24, nh = 0.0.0.0, mt >  = 0 > IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 192.168.250.1, mt > = 0 > IP4.DNS[1]:                             127.0.0.1 > IP6.ADDRESS[1]:                         fe80::ae1f:6bff:fe62:1007/64 > IP6.GATEWAY:                            -- > IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 100 > IP6.ROUTE[2]:                           dst = ff0 > > I don't know what you're trying to determine. Are you thinking that the G in the netstat output means the interface is a Gateway?  It doesn't. The U means the "route" is valid and the G means the "route" is to a gateway rather than a directly connected network or host.

On 8/2/20 6:22 PM, ToddAndMargo via users wrote: > I am not after what the gateway address is, but rather > > 1) if gateway is up or not That can only be determined by pinging it or something past it.

> 2) if my device connected to the gateway that is up Since you should know which interface goes to the gateway, why isn't it enough to check if the interface is connected?

On 2020-08-03 09:36, ToddAndMargo via users wrote: > On 2020-08-02 18:26, Samuel Sieb wrote: >> On 8/2/20 6:22 PM, ToddAndMargo via users wrote: >>> I am not after what the gateway address is, but rather >>> >>> 1) if gateway is up or not >> >> That can only be determined by pinging it or something past it. > > That is one way of doing it, but it gives a lot > more information than I want.  It tell me the > Internet is working.  I am not testing that. > > I only want to know if the device is connected to the > gateway and the gateway is up. So, ping the gateway?

> >> >>> 2) if my device connected to the gateway that is up >> >> Since you should know which interface goes to the gateway, why isn't it enough to check if the interface is connected? > > I am setting up my iptables so it is universal.  This > is only one of about 15 parameters I read from the > system. > Define "connected to".  If by mean "accessible" then a ping or may do.  That is assuming the gateway is configured to respond to pings.  "Connected" usually means a connection is established.  As in an ssh session.

On 2020-08-03 14:22, ToddAndMargo via users wrote: > On 2020-08-02 19:03, Ed Greshko wrote: >> On 2020-08-03 09:36, ToddAndMargo via users wrote: >>> On 2020-08-02 18:26, Samuel Sieb wrote: >>>> On 8/2/20 6:22 PM, ToddAndMargo via users wrote: >>>>> I am not after what the gateway address is, but rather >>>>> >>>>> 1) if gateway is up or not >>>> >>>> That can only be determined by pinging it or something past it. >>> >>> That is one way of doing it, but it gives a lot >>> more information than I want.  It tell me the >>> Internet is working.  I am not testing that. >>> >>> I only want to know if the device is connected to the >>> gateway and the gateway is up. >> >> So, ping the gateway? > > > You are presuming I know anything about several > networks at this point ??? You earlier posted... IP4.ADDRESS[1]:                         192.168.250.135/24 IP4.GATEWAY:                            192.168.250.1 IP4.ROUTE[1]:                           dst = 192.168.250.0/24, nh = 0.0.0.0, mt   = 0 IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 192.168.250.1, mt = 0 So, you know the gateway is 192.168.250.1 and you know your local IP address is 192.168.250.135. What am I missing? > >> >>> >>>> >>>>> 2) if my device connected to the gateway that is up >>>> >>>> Since you should know which interface goes to the gateway, why isn't it enough to check if the interface is connected? >>> >>> I am setting up my iptables so it is universal.  This >>> is only one of about 15 parameters I read from the >>> system. >>> >> >> Define "connected to".  If by mean "accessible" then a ping or may do.  That is assuming the gateway >> is configured to respond to pings.  "Connected" usually means a connection is established.  As in an >> ssh session. > > Presuming I know which device (eno2 in this instance), > is part of which network (192.168.250.0/24 in this > instance), this will tell me that I am connected to > the router of that network.  And what that router is. > > > $ netstat -rn > Kernel IP routing table > Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface > 0.0.0.0         192.168.250.1   0.0.0.0         UG        0 0          0 eno2 > 192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0 > 192.168.250.0   0.0.0.0         255.255.255.0   U         0 0          0 eno2 > 192.168.255.0   0.0.0.0         255.255.255.0   U         0 0 Which is the same information given by nmcli. And you're not "connected" to the router.  You're just being pointed to an IP address with more routing information than what your system has.  Meaning, this host can only directly communicate with hosts in the 192.168.250.0/24 and 192.168.122.0/24 subnets.  Any traffic not within those subnets must be sent to 192.168.250.1.  And, of course, you'd find that 192.168.250.1 itself would have a default gateway defined. Assuming that is the LAN segment of your Internet facing router the default route would be that of a device at your ISP. I still don't see any mystery or unknown.

You are presuming I know anything about several networks at this point

Hi Ed, Okay, lets look at this as a network detective. You start only know that there are two network connections. One to the to Internet, which I will call the Black connection. The other one to the internal network, which I will call the Red connection.  You need to know which is which.

Currently    $ netstat -rn    Kernel IP routing table    Destination     Gateway         Genmask         Flags   MSS Window irtt Iface    0.0.0.0         192.168.250.1   0.0.0.0         UG        0 0   0 eno2    192.168.122.0   0.0.0.0         255.255.255.0   U         0 0   0 virbr0    192.168.250.0   0.0.0.0         255.255.255.0   U         0 0   0 eno2    192.168.255.0   0.0.0.0         255.255.255.0   U         0 0   0 br0 and    $ route -n    Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    0.0.0.0         192.168.250.1   0.0.0.0         UG    100    0  0 eno2    192.168.122.0   0.0.0.0         255.255.255.0   U     0      0  0 virbr0    192.168.250.0   0.0.0.0         255.255.255.0   U     100    0  0 eno2    192.168.255.0   0.0.0.0         255.255.255.0   U     425    0  0 br0

both tell me that "eno2" is the Black connection and "br0" is the Red connection.  "virbr0" is also Red, but that is another story.  And that the ONLY connection that has a gateway is "eno2".  (More that one and all hell breaks loose.) In the above, I can determine:      Red network    = 192.168.255.0/24      Black network  = 192.168.250.0/24      Black Gateway  = 192.168.250.1 The giveaway is the "G" flag

So, I do believe you are connect.  "nmcli" can not tell me who is Red and who is Black.  "route" or "netstat" are what is initially called for.

I see you have two gateways.  Would you mind posting your `netstat -n`?

>> So, I do believe you are connect.  "nmcli" can not >> tell me who is Red and who is Black.  "route" or >> "netstat" are what is initially called for. > > I *didn't* say that at all.  In another message I said nmcli can't tell you if the gateway is UP.  not looking for that kind of "up"

> And, neither > can netstat or route.  And, that I thought was your goal to verify the gateway being up. > > For that, you normally use ping. Again, I am looking for the configuration, not whether it works or not.

On 2020-08-03 16:10, Ed Greshko wrote: > $ netstat -rn > Kernel IP routing table > Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface > 0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 enp2s0 > 0.0.0.0         192.168.2.5     0.0.0.0         UG        0 0          0 wlp4s0 > 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0 > 192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 wlp4s0 > 192.168.56.6    192.168.2.116   255.255.255.255 UGH       0 0          0 wlp4s0 > 192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0 I was just curious. Why so many gateways?   I see three.  Got an "H (target is a host)" flag too.

Since I presume it works, there is something new to be learned!

On Mon, 3 Aug 2020 at 08:19, ToddAndMargo via users <users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>> wrote: Okay, lets look at this as a network detective. You start only know that there are two network connections. One to the to Internet, which I will call the *Black* connection. The other one to the internal network, which I will call the *Red* connection.  You need to know which is which. Batten the hatches -- you may be attracting attention you don't want.   More descriptive names will avoid the "names can hurt me" problem, maybe "int*er*net" or "public" versus "int*ra*net" or "private". -- George N. White III

On 8/2/20 6:36 PM, ToddAndMargo via users wrote: > On 2020-08-02 18:26, Samuel Sieb wrote: >> On 8/2/20 6:22 PM, ToddAndMargo via users wrote: >>> I am not after what the gateway address is, but rather >>> >>> 1) if gateway is up or not >> >> That can only be determined by pinging it or something past it. > > That is one way of doing it, but it gives a lot > more information than I want.  It tell me the > Internet is working.  I am not testing that. > > I only want to know if the device is connected to the > gateway and the gateway is up. The only way to tell if the gateway is up is to ping it or connect to it in some way.

Pinging past it would also possibly test the internet connection.  How else do you think you could test for the gateway being up?

On Mon, Aug 3, 2020 at 3:53 AM ToddAndMargo via users <users(a)lists.fedoraproject.org&gt; wrote: > On 2020-08-02 16:30, Ed Greshko wrote: >> On 2020-08-03 07:10, ToddAndMargo via users wrote: >>> On 2020-08-01 19:42, Samuel Sieb wrote: >>>> On 8/1/20 7:20 PM, ToddAndMargo via users wrote: >>>>> >>>>> Is there a way to get nmcli to tell you if an interface >>>>> is a gateway like you can with `netstat -rn`? >>>> >>>> Very related to the previous question. >>>> >>>> # nmcli --fields IP4.GATEWAY d show wlo1 >>>> IP4.GATEWAY: 10.0.1.1 >>>> >>>> # nmcli --fields IP4.GATEWAY d show lo >>>> IP4.GATEWAY: -- >>> >>> Uh Oh! >>> >>> This tells me "what" the gateway is, but not >>> "if" the device is a gateway: >>> >>> $ netstat -rn | grep eno2 >>> 0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0 eno2 >>> 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2 >>> >>> $ nmcli device show eno2 >>> GENERAL.DEVICE: eno2 >>> GENERAL.TYPE: ethernet >>> GENERAL.HWADDR: AC:1F:6B:62:10:07 >>> GENERAL.MTU: 1500 >>> GENERAL.STATE: 100 (connected) >>> GENERAL.CONNECTION: eno2 >>> GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveCo >>> nnection/5 >>> WIRED-PROPERTIES.CARRIER: on >>> IP4.ADDRESS[1]: 192.168.250.135/24 >>> IP4.GATEWAY: 192.168.250.1 >>> IP4.ROUTE[1]: dst = 192.168.250.0/24, nh = 0.0.0.0, mt >>> = 0 >>> IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.250.1, mt >>> = 0 >>> IP4.DNS[1]: 127.0.0.1 >>> IP6.ADDRESS[1]: fe80::ae1f:6bff:fe62:1007/64 >>> IP6.GATEWAY: -- >>> IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 100 >>> IP6.ROUTE[2]: dst = ff0 >> >> I don't know what you're trying to determine. >> >> Are you thinking that the G in the netstat output means the >> interface is a Gateway? It doesn't. The U means the "route" is >> valid and the G means the "route" is to a gateway rather than a >> directly connected network or host. > > I did not state my question very well. My Bad. > > I am not after what the gateway address is, but rather > > 1) if gateway is up or not > > 2) if my device connected to the gateway that is up > > Note that in this instance, if my device is down, > it is also not connected to a gateway. > > I was after a way to get nmcli to also give > me this information. > > man netstat: > > --route, -r > Display the kernel routing tables. > > --numeric, -n > Show numerical addresses instead of trying to determine symbolic > host, > port or user names. > > man route: > Flags Possible flags include > U (route is up) > H (target is a host) > G (use gateway) > R (reinstate route for dynamic routing) > D (dynamically installed by daemon or redirect) > M (modified from routing daemon or redirect) > A (installed by addrconf) > C (cache entry) > ! (reject route) > > $ route -n | grep -i eno2 > 0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0 eno2 > 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2 > > > $ netstat -rn | grep -i eno2 > 0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0 > eno2 > 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0 > eno2 > > $ ifconfig eno2 | grep "inet " > inet 192.168.250.135 netmask 255.255.255.0 broadcast > 192.168.250.255 > > $ nmcli connection down eno2 > Connection 'eno2' successfully deactivated (D-Bus active path: > /org/freedesktop/NetworkManager/ActiveConnection/5) > > $ route -n | grep -i eno2 > <nothing> > > $ netstat -rn | grep -i eno2 > <nothing> "resolvectl query _gateway" will tell you that the gateway's set to X ip address, but only if you have "myhostname" in "nsswitch.conf". You can only check whether the gateway's up with "ping". If you mean that you want to check whether the NIC's up and you don't want to trust nmcli's "GENERAL.STATE" property, you can check "/sys/class/net/ens3/carrier" and/or "/sys/class/net/ens3/operstate".

On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users <users(a)lists.fedoraproject.org&gt; wrote: > On 2020-08-03 03:40, Tom H wrote: >> "resolvectl query _gateway" will tell you that the gateway's set to >> X ip address, but only if you have "myhostname" in "nsswitch.conf". > I think I misunderstand. > > $ resolvectl query _gateway > _gateway: resolve call failed: Could not activate remote peer. grep myhostname /etc/nsswitch.conf

On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: > On 2020-08-05 17:09, Tom H wrote: >> On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users >> <users(a)lists.fedoraproject.org&gt; wrote: >>> On 2020-08-03 03:40, Tom H wrote: >>>> "resolvectl query _gateway" will tell you that the gateway's set >>>> to X ip address, but only if you have "myhostname" in >>> "nsswitch.conf". I think I misunderstand. >>> >>> $ resolvectl query _gateway >>> _gateway: resolve call failed: Could not activate remote peer. >> grep myhostname /etc/nsswitch.conf > In addition, in order for this to work I believe you need to have > systemd-resolved.service running. I don't think so. But I'm now curious; I'll grab a Debian or Devuan ISO later and test myhostname in a VM.

On Wed, Aug 5, 2020 at 11:48 AM Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: > On 2020-08-05 17:39, Tom H wrote: >> On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko <ed.greshko(a)greshko.com&gt; >> wrote: >>> On 2020-08-05 17:09, Tom H wrote: >>>> On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users >>>> <users(a)lists.fedoraproject.org&gt; wrote: >>>>> On 2020-08-03 03:40, Tom H wrote: >>>>>> >>>>>> "resolvectl query _gateway" will tell you that the gateway's set >>>>>> to X ip address, but only if you have "myhostname" in >>>>> "nsswitch.conf". I think I misunderstand. >>>>> >>>>> $ resolvectl query _gateway >>>>> _gateway: resolve call failed: Could not activate remote peer. >>>> >>>> grep myhostname /etc/nsswitch.conf >>> >>> In addition, in order for this to work I believe you need to have >>> systemd-resolved.service running. >> >> I don't think so. But I'm now curious; I'll grab a Debian or Devuan >> ISO later and test myhostname in a VM. > > Why wait? :-) > > [egreshko@f32g ~]$ resolvectl query _gateway > _gateway: resolve call failed: Could not activate remote peer. > > [egreshko@f32g ~]$ sudo systemctl start systemd-resolved.service > > [egreshko@f32g ~]$ resolvectl query _gateway > _gateway: 192.168.122.1 -- link: enp1s0 > 2001:b030:112f:2::2 -- link: enp1s0 > > -- Information acquired via protocol DNS in 255.7ms. > -- Data is authenticated: yes Sorry. I was focused on "_gateway" and forgot about "resolvectl". Stupid! Of course that you can't use "resolvectl" if "resolved-systemd" isn't running. But, no need to install Debian or Devuan, "getent [a]hosts _gateway" will return the gateway ip address.

On 2020-08-05 21:02, Tom H wrote: > > Hopefully Todd, the OP, realized that you were implying that he > might not have "systemd-resolved" running... Hopefully.... I may be dense, but it seems to me there is no particular advantage to using resolvectl, or getent over the "ip route" command to learn the IP address of the gateway. For my $ those give too little info to understand how traffic may be routed. And that is what I am normally also wanting to know when looking at a gateway. But that may just be me.

On 2020-08-07 18:44, Tom H wrote: > On Wed, Aug 5, 2020 at 3:49 PM Ed Greshko <ed.greshko(a)greshko.com&gt; > wrote: >> On 2020-08-05 21:02, Tom H wrote:

>>> Hopefully Todd, the OP, realized that you were implying that he >>> might not have "systemd-resolved" running... >> >> Hopefully.... >> >> I may be dense, but it seems to me there is no particular advantage >> to using resolvectl, or getent over the "ip route" command to learn >> the IP address of the gateway. For my $ those give too little info >> to understand how traffic may be routed. And that is what I am >> normally also wanting to know when looking at a gateway. But that >> may just be me. > The complaint was that the iproute tools spit out too much > information. Oh, I thought the complaint was that nmcli, at least the command I used, gave too much info. Granted, I was giving a command which returned all the info I though the OP wanted.

FWIW, I only use nmcli to create, edit, control connections/devices under the control of NetworkManager. I don't use, and wouldn't use, nmcli to search/determine how things are configured on a system I'm not familiar with.

Each tool has some "drawbacks" unless you are aware of their use cases or have a clear understanding of what you need/want to know. For example, [egreshko@meimei ~]$ resolvectl query _gateway _gateway: 192.168.1.1 -- link: enp2s0 192.168.2.5 -- link: wlp4s0 2001:b030:112f::1 -- link: enp2s0 Returns a list of "default gateways". But, it doesn't tell you which will actually be used.

[egreshko@meimei ~]$ ip -br -4 route show | grep default default via 192.168.1.1 dev enp2s0 proto static metric 100 default via 192.168.2.5 dev wlp4s0 proto dhcp metric 600 Tells one the same, but does have the metric so you know which route would be used first. But you can't, at least I've not found a way, to list both IPv4 and IPv6 routes with the same command. And even both of those, as written, don't show Host routes which also need a "gateway" but not one which is "default"

netstat -rn is sorta fine for IPv4, but spits out too much for my taste with IPv6. I don't normally care about scope link info. It also has a Flag of U which can confuse since some docs say "route is up" and other documentation say "route is valid". It can lead some to think that it may mean the physical gateway device is "up" and working. It also lacks a metric....but I suppose most setups are rather straight-forward.

alias gateways="ip route list | awk '/^default/ {print}'"

For me, Tom H has the right idea.

If Todd wants simple what's wrong with something like this: alias gateways="ip route list | awk '/^default/ {print}'" --or short form-- alias gateways="ip r l | awk '/^default/ {print}'"

On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users <users(a)lists.fedoraproject.org&gt; wrote: > On 2020-08-03 03:40, Tom H wrote: >> >> "resolvectl query _gateway" will tell you that the gateway's set to >> X ip address, but only if you have "myhostname" in "nsswitch.conf". > > I think I misunderstand. > > $ resolvectl query _gateway > _gateway: resolve call failed: Could not activate remote peer. grep myhostname /etc/nsswitch.conf

On 2020-08-07 07:05, ToddAndMargo via users wrote: > On 2020-08-05 02:09, Tom H wrote: >> On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users >> <users(a)lists.fedoraproject.org&gt; wrote: >>> On 2020-08-03 03:40, Tom H wrote: >>>> >>>> "resolvectl query _gateway" will tell you that the gateway's set to >>>> X ip address, but only if you have "myhostname" in "nsswitch.conf". >>> >>> I think I misunderstand. >>> >>> $ resolvectl query _gateway >>> _gateway: resolve call failed: Could not activate remote peer. >> >> grep myhostname /etc/nsswitch.conf > > $ grep myhostname /etc/nsswitch.conf > hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname I suppose you missed the discussion about resolvectl needing to work with systemd-resolved.service. So, to use resolvectl you need to have systemd-resolved.service running.  It is disabled by default.

On 2020-08-06 16:54, Ed Greshko wrote: > > I suppose you missed the discussion about resolvectl needing to work > with systemd-resolved.service. > > So, to use resolvectl you need to have systemd-resolved.service > running. It is disabled by default. What would it give me?

On Fri, Aug 7, 2020 at 1:05 AM ToddAndMargo via users <users(a)lists.fedoraproject.org&gt; wrote: > On 2020-08-05 02:09, Tom H wrote: >> On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users >> <users(a)lists.fedoraproject.org&gt; wrote: >>> On 2020-08-03 03:40, Tom H wrote: >>>> "resolvectl query _gateway" will tell you that the gateway's set >>>> to X ip address, but only if you have "myhostname" in >>>> "nsswitch.conf". >>> I think I misunderstand. >>> >>> $ resolvectl query _gateway >>> _gateway: resolve call failed: Could not activate remote peer. >> grep myhostname /etc/nsswitch.conf > $ grep myhostname /etc/nsswitch.conf > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname As Ed G's pointed out, you need "systemd-resolved" to be running to be able to use "resolve". You can use "getent ..." or even "ping -c1 _gateway".

On 2020-08-07 03:50, Ed Greshko wrote: > On 2020-08-07 18:48, Tom H wrote: >> On Fri, Aug 7, 2020 at 1:05 AM ToddAndMargo via users >> <users(a)lists.fedoraproject.org&gt; wrote: >>> On 2020-08-05 02:09, Tom H wrote: >>>> On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users >>>> <users(a)lists.fedoraproject.org&gt; wrote: >>>>> On 2020-08-03 03:40, Tom H wrote: >>>>>> "resolvectl query _gateway" will tell you that the gateway's set >>>>>> to X ip address, but only if you have "myhostname" in >>>>>> "nsswitch.conf". >>>>> I think I misunderstand. >>>>> >>>>> $ resolvectl query _gateway >>>>> _gateway: resolve call failed: Could not activate remote peer. >>>> grep myhostname /etc/nsswitch.conf >>> $ grep myhostname /etc/nsswitch.conf >>> hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname >> As Ed G's pointed out, you need "systemd-resolved" to be running to be >> able to use "resolve". >> >> You can use "getent ..." or even "ping -c1 _gateway". > > He keeps saying he doesn't want to use ping as he isn't interested in what I would term "up".  :-) > I am after "configured" not "functioning"

I am after "configured" not "functioning"