Hi All,
Is there a way to get nmcli to tell you if an interface is a gateway like you can with `netstat -rn`?
Many thanks, -T
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-02 10: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: --
Well, that does tell you if it is a gateway. But, one may also be interested in
[egreshko@meimei ~]$ nmcli --fields IP4.ROUTE d show enp2s0 IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
To determine if it is a default gateway. As well as its metric.
[egreshko@meimei ~]$ nmcli --fields IP4.ROUTE d show wlp4s0 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.2.5, mt = 600 IP4.ROUTE[2]: dst = 192.168.2.0/24, nh = 0.0.0.0, mt = 600
Which indicates if enp2s0 is down then wlp4s0 becomes the default route.
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: --
Thank you!
$ nmcli device show eno2 | grep -i ip4.gateway IP4.GATEWAY: 192.168.250.1
$ nmcli device show eno2 | grep -i ip4.gateway | awk '{print $2}' 192.168.250.1
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
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 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.
Hi Ed,
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.
-T
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>
On 8/2/20 6:22 PM, ToddAndMargo via users wrote:
I am not after what the gateway address is, but rather
- if gateway is up or not
That can only be determined by pinging it or something past it.
- 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-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
- 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.
- 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.
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
- 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?
- 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-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
- 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
- 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
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
- 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?
- 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.
On 2020-08-03 00:16, Ed Greshko wrote:
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
- 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?
- 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.
I am just looking for alternate way to do things.
And NMCLI did not tell me if the router was up or not.
On 2020-08-03 14:22, ToddAndMargo via users wrote:
You are presuming I know anything about several networks at this point
I think I may have interpreted this incorrectly.
Do you mean your script will run on a system/network for which you have no prior knowledge?
If that is the case, maybe you should consider tools other than nmcli. While it can be used, it may not be easy to tease out information in a way that is simply to correlate.
You can do something like
nmcli -f IP4.ROUTE d show
and get all the ROUTE fields for all the devices but determining which belongs to which is not simple.
You may want to consider the ip command.
[egreshko@meimei ~]$ ip -br -4 add show lo UNKNOWN 127.0.0.1/8 enp2s0 UP 192.168.1.18/24 wlp4s0 UP 192.168.2.127/24 virbr0 UP 192.168.122.1/24
[egreshko@meimei ~]$ ip -br -4 route show default via 192.168.1.1 dev enp2s0 proto static metric 100 default via 192.168.2.5 dev wlp4s0 proto dhcp metric 600 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.18 metric 100 192.168.2.0/24 dev wlp4s0 proto kernel scope link src 192.168.2.127 metric 600 192.168.56.0/24 via 192.168.2.116 dev wlp4s0 proto static metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
Tells you everything you need to know about networking on the host meimei. (Note: I used -4 in the example since I'm also running IPV6 and didn't wish add complication)
You know that the default route will be via enp2s0 to 192.168.1.1 as long as enp2s0 is up. So, you'd naturally ping 192.168.1.1.
You know that if enp2s0 is down then the default route will be via wlp4v0 to 192.168.2.5. So, if enp2s0 is down you'd naturally ping 192.168.2.5.
On 2020-08-03 02:20, Ed Greshko wrote:
On 2020-08-03 14:22, ToddAndMargo via users wrote:
You are presuming I know anything about several networks at this point
I think I may have interpreted this incorrectly.
Do you mean your script will run on a system/network for which you have no prior knowledge?
yes. see below
If that is the case, maybe you should consider tools other than nmcli. While it can be used, it may not be easy to tease out information in a way that is simply to correlate.
You can do something like
nmcli -f IP4.ROUTE d show
and get all the ROUTE fields for all the devices but determining which belongs to which is not simple.
You may want to consider the ip command.
[egreshko@meimei ~]$ ip -br -4 add show lo UNKNOWN 127.0.0.1/8 enp2s0 UP 192.168.1.18/24 wlp4s0 UP 192.168.2.127/24 virbr0 UP 192.168.122.1/24
[egreshko@meimei ~]$ ip -br -4 route show default via 192.168.1.1 dev enp2s0 proto static metric 100 default via 192.168.2.5 dev wlp4s0 proto dhcp metric 600 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.18 metric 100 192.168.2.0/24 dev wlp4s0 proto kernel scope link src 192.168.2.127 metric 600 192.168.56.0/24 via 192.168.2.116 dev wlp4s0 proto static metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
Tells you everything you need to know about networking on the host meimei. (Note: I used -4 in the example since I'm also running IPV6 and didn't wish add complication)
You know that the default route will be via enp2s0 to 192.168.1.1 as long as enp2s0 is up. So, you'd naturally ping 192.168.1.1.
You know that if enp2s0 is down then the default route will be via wlp4v0 to 192.168.2.5. So, if enp2s0 is down you'd naturally ping 192.168.2.5.
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.
AND AFTER I have determined who is Red and Black, then nmcli is a world of information
-T
And a story for another day, determining the address of your dhcp server.
:-)
On 2020-08-03 18:21, ToddAndMargo via users wrote:
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.
Just a note of caution. Just because a default route exists it does not necessarily follow that that it will lead to the Internet. But, I doubt you're talking about cases where that would be.
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
Those are 2 ways to display the same information. As is "ip route show".
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
You can glean the same info from nmcli.
nmcli -f GENERAL.DEVICE,IP4.ADDRESS,IP4.GATEWAY,IP4.ROUTE device show.
For which I get on my system.
GENERAL.DEVICE: enp2s0 IP4.ADDRESS[1]: 192.168.1.18/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
GENERAL.DEVICE: virbr0 IP4.ADDRESS[1]: 192.168.122.1/24 IP4.GATEWAY: -- IP4.ROUTE[1]: dst = 192.168.122.0/24, nh = 0.0.0.0, mt = 0
GENERAL.DEVICE: wlp4s0 IP4.ADDRESS[1]: 192.168.2.127/24 IP4.GATEWAY: 192.168.2.5 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.2.5, mt = 600 IP4.ROUTE[2]: dst = 192.168.2.0/24, nh = 0.0.0.0, mt = 600 IP4.ROUTE[3]: dst = 192.168.56.0/24, nh = 192.168.2.116, mt = 600
And you now know the device names, IP address of the devices, you know the gateways, and dst=0.0.0.0/0 is equivalent to "G".
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. 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.
On 2020-08-03 03:57, Ed Greshko wrote:
On 2020-08-03 18:21, ToddAndMargo via users wrote:
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.
Just a note of caution. Just because a default route exists it does not necessarily follow that that it will lead to the Internet. But, I doubt you're talking about cases where that would be.
I know. I don't care. I am looking for the configuration, not whether it works or not
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
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
You can glean the same info from nmcli.
nmcli -f GENERAL.DEVICE,IP4.ADDRESS,IP4.GATEWAY,IP4.ROUTE device show.
For which I get on my system.
GENERAL.DEVICE: enp2s0 IP4.ADDRESS[1]: 192.168.1.18/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
GENERAL.DEVICE: virbr0 IP4.ADDRESS[1]: 192.168.122.1/24 IP4.GATEWAY: -- IP4.ROUTE[1]: dst = 192.168.122.0/24, nh = 0.0.0.0, mt = 0
GENERAL.DEVICE: wlp4s0 IP4.ADDRESS[1]: 192.168.2.127/24 IP4.GATEWAY: 192.168.2.5 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.2.5, mt = 600 IP4.ROUTE[2]: dst = 192.168.2.0/24, nh = 0.0.0.0, mt = 600 IP4.ROUTE[3]: dst = 192.168.56.0/24, nh = 192.168.2.116, mt = 600
This would allow me to careen through the list to find out who has a gateway. It is a lot easier to extract the device if the gateway and the device are on the same line. A loop withing a loop would be able to extract that. It is another way of doing it. Thank you!
And you now know the device names, IP address of the devices, you know the gateways, and dst=0.0.0.0/0 is equivalent to "G".
From the route man page U (route is up) G (use gateway)
0.0.0.0 does point to the UG interface, but you have to look to 0.0.0.0 to find if it is "up" (meaning "route is up"). This does not mean the configuration works, but I don't care.
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-04 06:48, ToddAndMargo via users wrote:
I see you have two gateways. Would you mind posting your `netstat -n`?
I think you want "netstat -rn". And, yes, I've already said, at least twice, that I have 2 "default gateways" I already said it is for the case where one path is down.
[egreshko@meimei ~]$ 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
This gives insufficient information about the usages of the "default gateways".
[egreshko@meimei ~]$ ip -4 route default via 192.168.1.1 dev enp2s0 proto static metric 100 default via 192.168.2.5 dev wlp4s0 proto dhcp metric 600 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.18 metric 100 192.168.2.0/24 dev wlp4s0 proto kernel scope link src 192.168.2.127 metric 600 192.168.56.6 via 192.168.2.116 dev wlp4s0 proto static metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
is better for that since it shows the metric. Not that it would always be of interest but with ip you know if the route was configured via dhcp, is a static route, or was added by the kernel.
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"
I do not know what kind of "up" you mean then.
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.
OK, but you kept saying.... "I only want to know if the device is connected to the gateway and the gateway is up." and even Samuel replied with "The only way to tell if the gateway is up is to ping it or connect to it in some way."
So, I don't know what your "up" means.
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 2020-08-04 07:45, ToddAndMargo via users wrote:
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.
Both 192.168.1.1 and 192.168.2.5 are "default" gateways. (dst=0.0.0.0). Any traffic for which a more specific route doesn't exist will be sent via 192.168.1.1 (metric=100). 192.168.2.5 is a "backup".
192.168.56.6 is a directly connected host connected to 192.168.2.116. That route is only used, for example, when ssh'ing to that host.
Since I presume it works, there is something new to be learned!
Well, I generally don't have non-working configurations. :-)
On Mon, 3 Aug 2020 at 08:19, ToddAndMargo via users < 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".
On 2020-08-03 04:55, George N. White III wrote:
On Mon, 3 Aug 2020 at 08:19, ToddAndMargo via users <users@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
It is disturbing that it has come to this. I hope the Religion of the Perpetually Offended goes away soon.
If you are interested the Red and Black comes from:
Red/black concept https://en.wikipedia.org/wiki/Red/black_concept
The red/black concept, sometimes called the red–black architecture[1] or red/black engineering, [2][3] refers to the careful segregation in cryptographic systems of signals that contain sensitive or classified plaintext information (red signals) from those that carry encrypted information, or ciphertext (black signals). Therefore the red side is usually considered the internal side, and the black side the more public side, with often some sort of guard, firewall or data-diode between the two.
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
- 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 2020-08-02 21:04, Samuel Sieb wrote:
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
- 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.
Exactly. And this all I want to know at this point.
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@lists.fedoraproject.org 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
if gateway is up or not
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 2020-08-03 03:40, Tom H wrote:
On Mon, Aug 3, 2020 at 3:53 AM ToddAndMargo via users users@lists.fedoraproject.org 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
if gateway is up or not
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".
I think I misunderstand.
$ resolvectl query _gateway _gateway: resolve call failed: Could not activate remote peer.
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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.
On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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 2020-08-05 17:39, Tom H wrote:
On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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
On Wed, Aug 5, 2020 at 11:48 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:39, Tom H wrote:
On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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 Wed, Aug 5, 2020 at 1:12 PM Tom H tomh0665@gmail.com wrote:
On Wed, Aug 5, 2020 at 11:48 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:39, Tom H wrote:
On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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.
I'm being hyper-stupid today/this week.
Hopefully Todd, the OP, realized that you were implying that he might not have "systemd-resolved" running...
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 Wed, Aug 5, 2020 at 3:49 PM Ed Greshko ed.greshko@greshko.com 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.
On 2020-08-07 18:44, Tom H wrote:
On Wed, Aug 5, 2020 at 3:49 PM Ed Greshko ed.greshko@greshko.com 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.
I still prefer the "ip route" command because you know at a glance all devices being used, their associated IP address, and the routes along with their metric.
Anyway, at the risk of offending some family members, all of this comes under the heading of "There is more than one way to skin a cat".
:-)
On Fri, Aug 7, 2020 at 1:34 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-07 18:44, Tom H wrote:
On Wed, Aug 5, 2020 at 3:49 PM Ed Greshko ed.greshko@greshko.com 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.
I remember that someone proposed "ip a" and/or "ip r", but the Todd said it was too verbose; "nmcli" too.
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.
If a system's using NM, I definitely use "nmcli" to find out what's going on, whether I've set it up or not. But, unless I'm setting up a bridge or a bond, I write out the config under "/etc/NetworkManager/system-connections".
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.
This is abusing "resolvectl"! LOL
It's not meant for displaying routing tables. But a bug report with the output above might convince the systemd developers to add "metric" in the case of a gateway, or, simply, in the case of "_gateway".
[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"
But you're grepping for "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.
I've never seen "valid". It's "usable" in BSD-land. But "man route" says that it's "up" in Linux-land.
Like "ip r", "route -n"/"netstat -nr" only show one family at a time, "inet" by default. Could it be a Linux limitation, one family at a time?! On OpenBSD, the inet and inet6 families are displayed by default.
Apologies, I've been kind of following this thread and haven't saved any of it except the latest.
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}'"
Then fake command "gateways" will give all defined gateways in order of definition with all listed parameters.
Mike Wright
On 8/10/20 3:36 PM, Garry T. Williams wrote:
On Monday, August 10, 2020 5:46:54 PM EDT Mike Wright wrote:
alias gateways="ip route list | awk '/^default/ {print}'"
That is the same as
ip route list | grep ^defaultIn general,
... | awk '/foo/ {print}'is equivalent to
... | grep foo
True. But grep is almost double the size and mawk is a byte code interpreter for awk (fast). Either will work (plus I've just been learning about awk and HAD to share )
:m
On Mon, Aug 10, 2020 at 11:47 PM Mike Wright nobody@nospam.hostisimo.com wrote:
For me, Tom H has the right idea.
:) although there are many "right" answers.
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}'"
One nitpick:
"list" must now be an undocumented alias for "show", because it hasn't been mentioned in "man ip-route" for 3 or 4 years; and was only mentioned previously in the synopsis. If you scrolled down the body of the man page, the documented command was "ip route show". IIRC, "man ip-rule" (still?) has "list" in the synopsis and "show" in the body.
So, for short, "ip r s"; or, given that "show" is the default, "ip r".
PS1: I assume that "list" will be an alias forever, but who knows...
PS2: You have to be careful with short forms. "ip r s" is understood, but "ip l s" isn't because it means "ip l set", not "ip l show". So you need "ip l sh" if you don't want simply to use "ip l".
On 2020-08-05 17:39, Tom H wrote:
On Wed, Aug 5, 2020 at 11:28 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-08-05 17:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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.
Oh, a big clue is in the man page.
resolvectl may be used to resolve domain names, IPv4 and IPv6 addresses, DNS resource records and services with the systemd-resolved.service(8)
:-)
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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
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@lists.fedoraproject.org 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:
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@lists.fedoraproject.org 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.
What would it give me?
On 2020-08-07 11:19, ToddAndMargo via users wrote:
On 2020-08-06 16:54, Ed Greshko wrote:
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@lists.fedoraproject.org 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.
What would it give me?
The ability to run the "resolvectl" command and not get the error message you cite.
man resolvectl
tells you about the command. And, if you read the discussion I had with Tom H you'd know my opinion on what it brings to the table and my understanding of what you wanted to know.
On Fri, Aug 7, 2020 at 5:19 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
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?
It's a caching dns resolver, like dnsmasq, but it runs on 127.0.0.53.
You can't simply enable and start "systemd-resolved.service". If you're using NM, as I seem to remember that you are, you have to set NM to use "systemd-resolved". You *_MIGHT_* also need to change the "/etc/resolv.conf" symlink the first time that you run with this setup.
On Fri, Aug 7, 2020 at 1:05 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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 18:48, Tom H wrote:
On Fri, Aug 7, 2020 at 1:05 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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". :-)
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@lists.fedoraproject.org wrote:
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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"
On 2020-08-08 05:42, ToddAndMargo via users wrote:
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@lists.fedoraproject.org wrote:
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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"
OK. I've got plenty of experience in producing non-functioning configurations. :-) :-)
On 2020-08-07 16:28, Ed Greshko wrote:
On 2020-08-08 05:42, ToddAndMargo via users wrote:
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@lists.fedoraproject.org wrote:
On 2020-08-05 02:09, Tom H wrote:
On Tue, Aug 4, 2020 at 1:32 AM ToddAndMargo via users users@lists.fedoraproject.org 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"
OK. I've got plenty of experience in producing non-functioning configurations. :-) :-)
This stuff goes into my iptables firewall script. It is "presumed" that the networking is done correctly, although I print out instructions on how to correct things when I find them missing/mis-configured.
Ya, I am pretty good at those "non-functioning configurations" too.
:'(
On Fri, 2020-08-07 at 14:42 -0700, ToddAndMargo via users wrote:
I am after "configured" not "functioning"
Just wondering, do you work for Microsoft? ;-)
On 2020-08-07 21:05, Tim via users wrote:
On Fri, 2020-08-07 at 14:42 -0700, ToddAndMargo via users wrote:
I am after "configured" not "functioning"
Just wondering, do you work for Microsoft? ;-)
Chuckle.
Check out my signature block!
-
Ed Greshko -
Garry T. Williams -
George N. White III -
Mike Wright -
Samuel Sieb -
Tim -
ToddAndMargo -
Tom H