Mixing
Naming convention standard for Ethernet and Wi-Fi interfaces on Linux machines
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
What is the naming convention standard for Ethernet and Wi-Fi interfaces on a Linux machine?
We are developing a tool that should show only the Ethernet and Wi-Fi interfaces of the Linux machine and its current status.
For example, below are the list of network interfaces (both physical and virtual) on my Linux (Ubuntu) machine.
docker0, enp0s25, lo, wlp3s0
When I run the tool, below is the result I will be getting.
enp0s25, wlp3s0
We have written the code with the logic that all the Ethernet interfaces always start with word e and Wi-Fi interfaces always start with word w.
Is the logic right? If not, how can we address this?
networking wifi network-interface ethernet
edited 18 mins ago
Peter Mortensen
85358
asked 14 hours ago
Mohan Raj
211
add a comment |Â
up vote
4
down vote
favorite
What is the naming convention standard for Ethernet and Wi-Fi interfaces on a Linux machine?
We are developing a tool that should show only the Ethernet and Wi-Fi interfaces of the Linux machine and its current status.
For example, below are the list of network interfaces (both physical and virtual) on my Linux (Ubuntu) machine.
docker0, enp0s25, lo, wlp3s0
When I run the tool, below is the result I will be getting.
enp0s25, wlp3s0
We have written the code with the logic that all the Ethernet interfaces always start with word e and Wi-Fi interfaces always start with word w.
Is the logic right? If not, how can we address this?
networking wifi network-interface ethernet
edited 18 mins ago
Peter Mortensen
85358
asked 14 hours ago
Mohan Raj
211
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
I would look at howiwconfigdoes filter WiFi interfaces from other ones.
– Patrick Mevzek
2 hours ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents oflshw -class networkmaybe? Look for everything that iscapabilities: ethernet physical? Possibly look for some of the other capabilities also?
– Zoredache
1 hour ago
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
What is the naming convention standard for Ethernet and Wi-Fi interfaces on a Linux machine?
We are developing a tool that should show only the Ethernet and Wi-Fi interfaces of the Linux machine and its current status.
For example, below are the list of network interfaces (both physical and virtual) on my Linux (Ubuntu) machine.
docker0, enp0s25, lo, wlp3s0
When I run the tool, below is the result I will be getting.
enp0s25, wlp3s0
We have written the code with the logic that all the Ethernet interfaces always start with word e and Wi-Fi interfaces always start with word w.
Is the logic right? If not, how can we address this?
networking wifi network-interface ethernet
edited 18 mins ago
Peter Mortensen
85358
asked 14 hours ago
Mohan Raj
211
What is the naming convention standard for Ethernet and Wi-Fi interfaces on a Linux machine?
We are developing a tool that should show only the Ethernet and Wi-Fi interfaces of the Linux machine and its current status.
For example, below are the list of network interfaces (both physical and virtual) on my Linux (Ubuntu) machine.
docker0, enp0s25, lo, wlp3s0
When I run the tool, below is the result I will be getting.
enp0s25, wlp3s0
We have written the code with the logic that all the Ethernet interfaces always start with word e and Wi-Fi interfaces always start with word w.
Is the logic right? If not, how can we address this?
networking wifi network-interface ethernet
networking wifi network-interface ethernet
edited 18 mins ago
Peter Mortensen
85358
asked 14 hours ago
Mohan Raj
211
edited 18 mins ago
Peter Mortensen
85358
asked 14 hours ago
Mohan Raj
211
edited 18 mins ago
Peter Mortensen
85358
edited 18 mins ago
Peter Mortensen
85358
edited 18 mins ago
Peter Mortensen
85358
85358
asked 14 hours ago
Mohan Raj
211
asked 14 hours ago
Mohan Raj
211
asked 14 hours ago
Mohan Raj
211
211
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
I would look at howiwconfigdoes filter WiFi interfaces from other ones.
– Patrick Mevzek
2 hours ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents oflshw -class networkmaybe? Look for everything that iscapabilities: ethernet physical? Possibly look for some of the other capabilities also?
– Zoredache
1 hour ago
add a comment |Â
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
I would look at howiwconfigdoes filter WiFi interfaces from other ones.
– Patrick Mevzek
2 hours ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents oflshw -class networkmaybe? Look for everything that iscapabilities: ethernet physical? Possibly look for some of the other capabilities also?
– Zoredache
1 hour ago
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
I would look at how
iwconfig does filter WiFi interfaces from other ones.– Patrick Mevzek
2 hours ago
I would look at how
iwconfig does filter WiFi interfaces from other ones.– Patrick Mevzek
2 hours ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents of
lshw -class network maybe? Look for everything that is capabilities: ethernet physical? Possibly look for some of the other capabilities also?– Zoredache
1 hour ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents of
lshw -class network maybe? Look for everything that is capabilities: ethernet physical? Possibly look for some of the other capabilities also?– Zoredache
1 hour ago
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
15
down vote
Network interfaces can be named anything, so no matter what you do, you'll run into situations where (1) there is a "physical" network interface with a name that didn't match your pattern, or (2) there is a "physical" network interface that will match your pattern.
On top of that, if I was a user of your tool, the moment your tool wouldn't allow me to do something I want, because I have a network interface which is "virtual", though for practical purposes it should be considered "physical" in my setup, I'd start cursing loudly and forcefully at your app, and won't ever use it again.
Physical and virtual network interfaces all share a common API are one thing which makes Linux really flexible. Please don't try to babysit your user, and take that away from him or her. Your users will thank you.
answered 12 hours ago
dirkt
15.6k21133
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simpleip link set ... name ...can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.
– dirkt
6 hours ago
add a comment |Â
up vote
12
down vote
For systemd predictable interface names, the prefixes can be seen in udev-builtin-net_id.c :
* Two character prefixes based on the type of interface:
* en — Ethernet
* ib — InfiniBand
* sl — serial line IP (slip)
* wl — wlan
* ww — wwan
so for both the traditional ethX style of naming and the newer systemd naming, an initial letter e should be an ethernet interface for any automatically generated interface names. All wifi interfaces should begin with a w in both schemes, although not all interfaces beginning with w will be wifi.
If this tool has to work in an arbitrary environment (rather than just on internal environments which you control), note that users may rename interfaces on linux systems with arbitrary names, such as [wan0, lan0, lan1, dmz0] which will break any assumptions about initial letters.
answered 13 hours ago
user4556274
5,17811124
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
add a comment |Â
up vote
8
down vote
The naming convention is that LAN interfaces are named eth0, eth1, ... and that WLAN interfaces are named wlan0, wlan1, ...
What you see are the so called "predictable names" that systemd introduced. In practice, they are anything but predictable, and they can even change when the hardware is changed, which is exactly the problem they are supposed to avoid.
For a guess the start letter may be good enough. Some interfaces, in particular WLAN, have hints in /sys/class/net/*/uevent:
DEVTYPE=wlan
Unfortunately, there is no such DEVTYPE for LAN interfaces.
answered 14 hours ago
RalfFriedl
4,6761725
add a comment |Â
up vote
0
down vote
One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers
answered 2 hours ago
Kevin Keane
268110
add a comment |Â
up vote
0
down vote
Are you explicitly excluding bonded or teamed interfaces? Our default here is to use bond0 or team0 for the primary interface for our servers.
I think you need to re-think your logic. Maybe try iterating though all the defined network interfaces on a given system, divide them up between ethernet, wifi, infiband, serial, etc., and then do your magic.
answered 2 hours ago
Doug O'Neal
2,8021817
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
Network interfaces can be named anything, so no matter what you do, you'll run into situations where (1) there is a "physical" network interface with a name that didn't match your pattern, or (2) there is a "physical" network interface that will match your pattern.
On top of that, if I was a user of your tool, the moment your tool wouldn't allow me to do something I want, because I have a network interface which is "virtual", though for practical purposes it should be considered "physical" in my setup, I'd start cursing loudly and forcefully at your app, and won't ever use it again.
Physical and virtual network interfaces all share a common API are one thing which makes Linux really flexible. Please don't try to babysit your user, and take that away from him or her. Your users will thank you.
answered 12 hours ago
dirkt
15.6k21133
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simpleip link set ... name ...can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.
– dirkt
6 hours ago
add a comment |Â
up vote
15
down vote
Network interfaces can be named anything, so no matter what you do, you'll run into situations where (1) there is a "physical" network interface with a name that didn't match your pattern, or (2) there is a "physical" network interface that will match your pattern.
On top of that, if I was a user of your tool, the moment your tool wouldn't allow me to do something I want, because I have a network interface which is "virtual", though for practical purposes it should be considered "physical" in my setup, I'd start cursing loudly and forcefully at your app, and won't ever use it again.
Physical and virtual network interfaces all share a common API are one thing which makes Linux really flexible. Please don't try to babysit your user, and take that away from him or her. Your users will thank you.
answered 12 hours ago
dirkt
15.6k21133
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simpleip link set ... name ...can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.
– dirkt
6 hours ago
add a comment |Â
up vote
15
down vote
up vote
15
down vote
Network interfaces can be named anything, so no matter what you do, you'll run into situations where (1) there is a "physical" network interface with a name that didn't match your pattern, or (2) there is a "physical" network interface that will match your pattern.
On top of that, if I was a user of your tool, the moment your tool wouldn't allow me to do something I want, because I have a network interface which is "virtual", though for practical purposes it should be considered "physical" in my setup, I'd start cursing loudly and forcefully at your app, and won't ever use it again.
Physical and virtual network interfaces all share a common API are one thing which makes Linux really flexible. Please don't try to babysit your user, and take that away from him or her. Your users will thank you.
answered 12 hours ago
dirkt
15.6k21133
Network interfaces can be named anything, so no matter what you do, you'll run into situations where (1) there is a "physical" network interface with a name that didn't match your pattern, or (2) there is a "physical" network interface that will match your pattern.
On top of that, if I was a user of your tool, the moment your tool wouldn't allow me to do something I want, because I have a network interface which is "virtual", though for practical purposes it should be considered "physical" in my setup, I'd start cursing loudly and forcefully at your app, and won't ever use it again.
Physical and virtual network interfaces all share a common API are one thing which makes Linux really flexible. Please don't try to babysit your user, and take that away from him or her. Your users will thank you.
answered 12 hours ago
dirkt
15.6k21133
answered 12 hours ago
dirkt
15.6k21133
answered 12 hours ago
dirkt
15.6k21133
answered 12 hours ago
dirkt
15.6k21133
15.6k21133
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simpleip link set ... name ...can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.
– dirkt
6 hours ago
add a comment |Â
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simpleip link set ... name ...can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.
– dirkt
6 hours ago
1
1
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
You haven't actually answered the question; you've spent 3 paragraphs challenging the background context of the question. While I'm aware that frame challenge answers are a thing, this doesn't feel like one of those cases ... especially since user4556274 gave a succinct answer to the question as asked.
– Mike Ounsworth
7 hours ago
4
4
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simple
ip link set ... name ... can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.– dirkt
6 hours ago
@MikeOunsworth: The problem is that the answer of user4556274 doesn't work in the general case, it only works if the interface names are indeed predicatable interface names. Which a simple
ip link set ... name ... can change. And yes, I could have listed the predictable interface names myself. The answer to the original question is "please don't do it that way". Because no matter how you go about it, it won't work.– dirkt
6 hours ago
add a comment |Â
up vote
12
down vote
For systemd predictable interface names, the prefixes can be seen in udev-builtin-net_id.c :
* Two character prefixes based on the type of interface:
* en — Ethernet
* ib — InfiniBand
* sl — serial line IP (slip)
* wl — wlan
* ww — wwan
so for both the traditional ethX style of naming and the newer systemd naming, an initial letter e should be an ethernet interface for any automatically generated interface names. All wifi interfaces should begin with a w in both schemes, although not all interfaces beginning with w will be wifi.
If this tool has to work in an arbitrary environment (rather than just on internal environments which you control), note that users may rename interfaces on linux systems with arbitrary names, such as [wan0, lan0, lan1, dmz0] which will break any assumptions about initial letters.
answered 13 hours ago
user4556274
5,17811124
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
add a comment |Â
up vote
12
down vote
For systemd predictable interface names, the prefixes can be seen in udev-builtin-net_id.c :
* Two character prefixes based on the type of interface:
* en — Ethernet
* ib — InfiniBand
* sl — serial line IP (slip)
* wl — wlan
* ww — wwan
so for both the traditional ethX style of naming and the newer systemd naming, an initial letter e should be an ethernet interface for any automatically generated interface names. All wifi interfaces should begin with a w in both schemes, although not all interfaces beginning with w will be wifi.
If this tool has to work in an arbitrary environment (rather than just on internal environments which you control), note that users may rename interfaces on linux systems with arbitrary names, such as [wan0, lan0, lan1, dmz0] which will break any assumptions about initial letters.
answered 13 hours ago
user4556274
5,17811124
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
add a comment |Â
up vote
12
down vote
up vote
12
down vote
For systemd predictable interface names, the prefixes can be seen in udev-builtin-net_id.c :
* Two character prefixes based on the type of interface:
* en — Ethernet
* ib — InfiniBand
* sl — serial line IP (slip)
* wl — wlan
* ww — wwan
so for both the traditional ethX style of naming and the newer systemd naming, an initial letter e should be an ethernet interface for any automatically generated interface names. All wifi interfaces should begin with a w in both schemes, although not all interfaces beginning with w will be wifi.
If this tool has to work in an arbitrary environment (rather than just on internal environments which you control), note that users may rename interfaces on linux systems with arbitrary names, such as [wan0, lan0, lan1, dmz0] which will break any assumptions about initial letters.
answered 13 hours ago
user4556274
5,17811124
For systemd predictable interface names, the prefixes can be seen in udev-builtin-net_id.c :
* Two character prefixes based on the type of interface:
* en — Ethernet
* ib — InfiniBand
* sl — serial line IP (slip)
* wl — wlan
* ww — wwan
so for both the traditional ethX style of naming and the newer systemd naming, an initial letter e should be an ethernet interface for any automatically generated interface names. All wifi interfaces should begin with a w in both schemes, although not all interfaces beginning with w will be wifi.
If this tool has to work in an arbitrary environment (rather than just on internal environments which you control), note that users may rename interfaces on linux systems with arbitrary names, such as [wan0, lan0, lan1, dmz0] which will break any assumptions about initial letters.
answered 13 hours ago
user4556274
5,17811124
edited 12 hours ago
answered 13 hours ago
user4556274
5,17811124
answered 13 hours ago
user4556274
5,17811124
answered 13 hours ago
user4556274
5,17811124
5,17811124
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
add a comment |Â
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
1
1
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
And some of us are staunch systemd refuseniks.
– chrylis
6 hours ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
On a router they cuold be ge1, ge2, ge3, ...
– immibis
1 hour ago
add a comment |Â
up vote
8
down vote
The naming convention is that LAN interfaces are named eth0, eth1, ... and that WLAN interfaces are named wlan0, wlan1, ...
What you see are the so called "predictable names" that systemd introduced. In practice, they are anything but predictable, and they can even change when the hardware is changed, which is exactly the problem they are supposed to avoid.
For a guess the start letter may be good enough. Some interfaces, in particular WLAN, have hints in /sys/class/net/*/uevent:
DEVTYPE=wlan
Unfortunately, there is no such DEVTYPE for LAN interfaces.
answered 14 hours ago
RalfFriedl
4,6761725
add a comment |Â
up vote
8
down vote
The naming convention is that LAN interfaces are named eth0, eth1, ... and that WLAN interfaces are named wlan0, wlan1, ...
What you see are the so called "predictable names" that systemd introduced. In practice, they are anything but predictable, and they can even change when the hardware is changed, which is exactly the problem they are supposed to avoid.
For a guess the start letter may be good enough. Some interfaces, in particular WLAN, have hints in /sys/class/net/*/uevent:
DEVTYPE=wlan
Unfortunately, there is no such DEVTYPE for LAN interfaces.
answered 14 hours ago
RalfFriedl
4,6761725
add a comment |Â
up vote
8
down vote
up vote
8
down vote
The naming convention is that LAN interfaces are named eth0, eth1, ... and that WLAN interfaces are named wlan0, wlan1, ...
What you see are the so called "predictable names" that systemd introduced. In practice, they are anything but predictable, and they can even change when the hardware is changed, which is exactly the problem they are supposed to avoid.
For a guess the start letter may be good enough. Some interfaces, in particular WLAN, have hints in /sys/class/net/*/uevent:
DEVTYPE=wlan
Unfortunately, there is no such DEVTYPE for LAN interfaces.
answered 14 hours ago
RalfFriedl
4,6761725
The naming convention is that LAN interfaces are named eth0, eth1, ... and that WLAN interfaces are named wlan0, wlan1, ...
What you see are the so called "predictable names" that systemd introduced. In practice, they are anything but predictable, and they can even change when the hardware is changed, which is exactly the problem they are supposed to avoid.
For a guess the start letter may be good enough. Some interfaces, in particular WLAN, have hints in /sys/class/net/*/uevent:
DEVTYPE=wlan
Unfortunately, there is no such DEVTYPE for LAN interfaces.
answered 14 hours ago
RalfFriedl
4,6761725
answered 14 hours ago
RalfFriedl
4,6761725
answered 14 hours ago
RalfFriedl
4,6761725
answered 14 hours ago
RalfFriedl
4,6761725
4,6761725
add a comment |Â
add a comment |Â
up vote
0
down vote
One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers
answered 2 hours ago
Kevin Keane
268110
add a comment |Â
up vote
0
down vote
One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers
answered 2 hours ago
Kevin Keane
268110
add a comment |Â
up vote
0
down vote
up vote
0
down vote
One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers
answered 2 hours ago
Kevin Keane
268110
One caveat with my answer (applies to most of the others, too): I don't know the purpose of your application. If it is a throwaway application to troubleshoot one particular problem, or to understand networking better, never to be used again, then relying on the first letter of the interface may be a great quick-and-dirty option. If you are planning to write the next competitor to Wireshark or tcpdump, you need to be sure you get it right for all kinds of edge cases.
And if the application you are writing falls somewhere between those extremes, only you (and your customers) can know how carefully you need to implement your logic.
Others have already pointed out that the names are never reliable, for any number of reasons. The ultimate problem is a very common one in software: hard-coding assumptions instead of relying on known/documented facts.
The second issue that hasn't been mentioned is also based on an assumption about your requirements: that the list of interfaces you want to list is always exactly "hardware ethernet interfaces" and "wifi interfaces".
The third issue is yet another assumption: that all interface will fall into the categories you can think of right now. How about Infiniband, as mentioned by @user4556274? How about tunnel interfaces for a VPN? How about bridged interfaces? How about bridged interfaces that combine physical and logical interfaces?
But there may be options to accomplish what you are looking for. First, define exactly what characterizes an interface you want to list, vs one that you don't.
In most cases, one characteristic you can rely on is the routing table (however, this will only work as long as the interface is up, so it may not be what you are actually looking for).
Any interface that has a default route (i.e., a route to 0.0.0.0) is likely to be one you are looking for.
Note that even this is still based on an assumption, just a more reliable one: it is conceivable that a system is configured to route all outbound traffic through a virtual machine or a docker container (for instance, if there is a container running a firewall). And the reverse is also true: a sysadmin could potentially lock down outside traffic by deleting the default route.
Another option is to go by the actual hardware and see which driver it uses. You can then exclude certain well-known drivers
answered 2 hours ago
Kevin Keane
268110
answered 2 hours ago
Kevin Keane
268110
answered 2 hours ago
Kevin Keane
268110
answered 2 hours ago
Kevin Keane
268110
268110
add a comment |Â
add a comment |Â
up vote
0
down vote
Are you explicitly excluding bonded or teamed interfaces? Our default here is to use bond0 or team0 for the primary interface for our servers.
I think you need to re-think your logic. Maybe try iterating though all the defined network interfaces on a given system, divide them up between ethernet, wifi, infiband, serial, etc., and then do your magic.
answered 2 hours ago
Doug O'Neal
2,8021817
add a comment |Â
up vote
0
down vote
Are you explicitly excluding bonded or teamed interfaces? Our default here is to use bond0 or team0 for the primary interface for our servers.
I think you need to re-think your logic. Maybe try iterating though all the defined network interfaces on a given system, divide them up between ethernet, wifi, infiband, serial, etc., and then do your magic.
answered 2 hours ago
Doug O'Neal
2,8021817
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Are you explicitly excluding bonded or teamed interfaces? Our default here is to use bond0 or team0 for the primary interface for our servers.
I think you need to re-think your logic. Maybe try iterating though all the defined network interfaces on a given system, divide them up between ethernet, wifi, infiband, serial, etc., and then do your magic.
answered 2 hours ago
Doug O'Neal
2,8021817
Are you explicitly excluding bonded or teamed interfaces? Our default here is to use bond0 or team0 for the primary interface for our servers.
I think you need to re-think your logic. Maybe try iterating though all the defined network interfaces on a given system, divide them up between ethernet, wifi, infiband, serial, etc., and then do your magic.
answered 2 hours ago
Doug O'Neal
2,8021817
answered 2 hours ago
Doug O'Neal
2,8021817
answered 2 hours ago
Doug O'Neal
2,8021817
answered 2 hours ago
Doug O'Neal
2,8021817
2,8021817
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f479094%2fnaming-convention-standard-for-ethernet-and-wi-fi-interfaces-on-linux-machines%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
related: unix.stackexchange.com/a/179931/117549
– Jeff Schaller
9 hours ago
I would look at how
iwconfigdoes filter WiFi interfaces from other ones.– Patrick Mevzek
2 hours ago
Is there a reason why you wouldn't look at something like lshw? Specifically inspect the contents of
lshw -class networkmaybe? Look for everything that iscapabilities: ethernet physical? Possibly look for some of the other capabilities also?– Zoredache
1 hour ago