How does Linux find/configure something like 'wlan0' when it is not a device that appears in /dev?
(On raspberry pi zero w, kernel 4.14y) It seems the wireless adapter chip isn't a device in the /dev fs, but is the name of something that 'ifconfig' knows about. I understand that this is an artifact from Berkley Sockets.
It is hardware, I assume it must be mentioned in the device tree -- to cause some driver to be loaded, but it must not create an entry in /dev (devfs).
Where/how does Sockets find this device that is not a device?
wifi configuration device-tree
asked Nov 24 at 21:33
Ribo
1106
add a comment |
(On raspberry pi zero w, kernel 4.14y) It seems the wireless adapter chip isn't a device in the /dev fs, but is the name of something that 'ifconfig' knows about. I understand that this is an artifact from Berkley Sockets.
It is hardware, I assume it must be mentioned in the device tree -- to cause some driver to be loaded, but it must not create an entry in /dev (devfs).
Where/how does Sockets find this device that is not a device?
wifi configuration device-tree
asked Nov 24 at 21:33
Ribo
1106
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49
add a comment |
(On raspberry pi zero w, kernel 4.14y) It seems the wireless adapter chip isn't a device in the /dev fs, but is the name of something that 'ifconfig' knows about. I understand that this is an artifact from Berkley Sockets.
It is hardware, I assume it must be mentioned in the device tree -- to cause some driver to be loaded, but it must not create an entry in /dev (devfs).
Where/how does Sockets find this device that is not a device?
wifi configuration device-tree
asked Nov 24 at 21:33
Ribo
1106
(On raspberry pi zero w, kernel 4.14y) It seems the wireless adapter chip isn't a device in the /dev fs, but is the name of something that 'ifconfig' knows about. I understand that this is an artifact from Berkley Sockets.
It is hardware, I assume it must be mentioned in the device tree -- to cause some driver to be loaded, but it must not create an entry in /dev (devfs).
Where/how does Sockets find this device that is not a device?
wifi configuration device-tree
wifi configuration device-tree
asked Nov 24 at 21:33
Ribo
1106
asked Nov 24 at 21:33
Ribo
1106
edited Nov 25 at 21:31
asked Nov 24 at 21:33
Ribo
1106
asked Nov 24 at 21:33
Ribo
1106
asked Nov 24 at 21:33
Ribo
1106
1106
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49
add a comment |
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49
add a comment |
3 Answers
3
active
oldest
votes
In Linux, network interfaces don't have a device node in /dev at all.
If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.
Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.
Also, note that /dev is the device filesystem.
The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.
The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.
In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.
The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.
So, the answer to your original question is like this:
- the Berkeley Sockets API gets the network interface from the kernel
- the kernel gets the essential hardware information from the device tree file
- the device tree file is loaded by the GPU with
/boot/start.elfaccording to configuration in/boot/config.txt
- the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.
The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.
The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.
The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.
The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.
answered Nov 24 at 22:25
telcoM
15.7k12143
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
add a comment |
wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.
O and ifup and ifdown are basicly the on off switches HeHehe...
See:
https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html
answered Nov 24 at 21:50
Michael Prokopec
1,028116
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
add a comment |
-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...
edited Nov 25 at 17:21
GAD3R
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483929%2fhow-does-linux-find-configure-something-like-wlan0-when-it-is-not-a-device-tha%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Linux, network interfaces don't have a device node in /dev at all.
If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.
Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.
Also, note that /dev is the device filesystem.
The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.
The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.
In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.
The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.
So, the answer to your original question is like this:
- the Berkeley Sockets API gets the network interface from the kernel
- the kernel gets the essential hardware information from the device tree file
- the device tree file is loaded by the GPU with
/boot/start.elfaccording to configuration in/boot/config.txt
- the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.
The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.
The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.
The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.
The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.
answered Nov 24 at 22:25
telcoM
15.7k12143
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
add a comment |
In Linux, network interfaces don't have a device node in /dev at all.
If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.
Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.
Also, note that /dev is the device filesystem.
The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.
The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.
In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.
The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.
So, the answer to your original question is like this:
- the Berkeley Sockets API gets the network interface from the kernel
- the kernel gets the essential hardware information from the device tree file
- the device tree file is loaded by the GPU with
/boot/start.elfaccording to configuration in/boot/config.txt
- the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.
The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.
The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.
The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.
The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.
answered Nov 24 at 22:25
telcoM
15.7k12143
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
add a comment |
In Linux, network interfaces don't have a device node in /dev at all.
If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.
Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.
Also, note that /dev is the device filesystem.
The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.
The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.
In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.
The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.
So, the answer to your original question is like this:
- the Berkeley Sockets API gets the network interface from the kernel
- the kernel gets the essential hardware information from the device tree file
- the device tree file is loaded by the GPU with
/boot/start.elfaccording to configuration in/boot/config.txt
- the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.
The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.
The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.
The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.
The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.
answered Nov 24 at 22:25
telcoM
15.7k12143
In Linux, network interfaces don't have a device node in /dev at all.
If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed.
Programmatically, you can use the if_nameindex() syscall: see this answer on Stack Overflow.
Also, note that /dev is the device filesystem.
The device-tree has a specific different meaning: it is a machine-readable description of a system's hardware composition. It is used on systems that don't have Plug-and-Play capable hardware buses, or otherwise have hardware that cannot be automatically discovered. As an example, Linux on ARM SoCs like Raspberry Pi uses a device tree.
The boot sequence of a RasPi is quite interesting: see this question on RasPi.SE.
In short, at boot time, under control of the /boot/start.elf file, the GPU loads the appropriate /boot/*.dtb and /boot/overlay/*.dtbo files before the main ARM CPU is started. The *.dtb file is the compiled device tree in binary format. It describes the hardware that can be found on each specific RasPi model, and is produced from a device tree source file (.dts`) which is just text, formatted in a specific way.
The kernel's live image of the device-tree can be seen in: /sys/firmware/devicetree/base Per Ciro Santilli, it can be displayed in .dts format by:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
You can find the specification of the device tree file format here. The specification is intended to be OS-independent. You may also need the Device Tree Reference as clarification to some details.
So, the answer to your original question is like this:
- the Berkeley Sockets API gets the network interface from the kernel
- the kernel gets the essential hardware information from the device tree file
- the device tree file is loaded by the GPU with
/boot/start.elfaccording to configuration in/boot/config.txt
- the device tree file was originally created according to the hardware specifications of each RasPi model and compiled to the appropriate binary format.
The device tree scanning code is mostly concerned about finding a valid driver for each piece of hardware. It won't much care about each device's purpose: that's the driver's job.
The driver uses the appropriate *_register_driver() kernel function to document its own existence, takes the appropriate part of the device tree information to find the actual hardware, and then uses other functions to register that hardware as being under its control. Once the driver has initialized the hardware, it uses the kernel's register_netdev() function to register itself as a new network interface, which, among other things, will make the Sockets API (which is just another interface of the kernel, not an independent entity as such) aware that the network interface exists.
The driver is likely to register itself for other things too: it will list a number of ethtool operations it supports for link status monitoring, traffic statistics and other low-level functions, and a driver for a wireless NIC will also use register_wiphy() to declare itself as a wireless network interface with specific Wi-Fi capabilities.
The Linux TCP/IP stack has many interfaces: the Berkeley Sockets API is the side of it that will be the most familiar to application programmers. The netdev API is essentially the other, driver-facing side of the same coin.
answered Nov 24 at 22:25
telcoM
15.7k12143
edited yesterday
answered Nov 24 at 22:25
telcoM
15.7k12143
answered Nov 24 at 22:25
telcoM
15.7k12143
answered Nov 24 at 22:25
telcoM
15.7k12143
15.7k12143
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
add a comment |
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
Ah good, 'ls -l /sys/class/net; (on a system with a working wlan0) shows the sym link: wlan0 -> ../../devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0 which tells me the device is connected through the SDIO (mmc) controller on the SOC.
– Ribo
Nov 25 at 0:21
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
So how does Sockets find out about network interfaces from the kernel? Does something scan the device-tree for devices with some 'net' property or label? And I need to find out how start.elf selects the appropriate .dtb file from those on /boot
– Ribo
Nov 25 at 15:01
add a comment |
wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.
O and ifup and ifdown are basicly the on off switches HeHehe...
See:
https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html
answered Nov 24 at 21:50
Michael Prokopec
1,028116
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
add a comment |
wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.
O and ifup and ifdown are basicly the on off switches HeHehe...
See:
https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html
answered Nov 24 at 21:50
Michael Prokopec
1,028116
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
add a comment |
wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.
O and ifup and ifdown are basicly the on off switches HeHehe...
See:
https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html
answered Nov 24 at 21:50
Michael Prokopec
1,028116
wlan0 is an interface created by interfaces, in /etc/network/. The device itself is a contruct of the firmware that is loaded, for said interface. I say this because wlan0 is not the location of the actual hardware. It is a software constructed interface, to provide a way for the OS to talk to the hardware through the firmware definition of the actual device. Because you can change the firmware in order to modify the way the actual hardware behaves, add/remove functions change frequencies and such.
O and ifup and ifdown are basicly the on off switches HeHehe...
See:
https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html
answered Nov 24 at 21:50
Michael Prokopec
1,028116
edited Nov 24 at 23:04
answered Nov 24 at 21:50
Michael Prokopec
1,028116
answered Nov 24 at 21:50
Michael Prokopec
1,028116
answered Nov 24 at 21:50
Michael Prokopec
1,028116
1,028116
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
add a comment |
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
This sounds like a good lead. /etc/network/interfaces contains config files that I write to say how it should setup the devices, named eth0 or wlan0 or something. How does the system know that there is an eth0 and that there is not a wlan2? --- What code knows that there is a device out there to be wlan0?
– Ribo
Nov 25 at 0:28
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
@Ribo The library of the controler where the device is attached, reports to the kernal that, hay a device with this id is presant. The kernal then looks for a firmware file that fits that device's description. Then the devices drivers are loaded. Then the device is brought up, and is seen as a interface. Say, wlan0 or whatever.
– Michael Prokopec
Nov 25 at 0:38
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
In this case the wifi chip is connected by an SDIO interface -- meaning it is a device connected to an SDcard host (I didn't know before that SDcard hosts could connect to things other than SD memory cards, but they can.) So something must be going wrong there.
– Ribo
Nov 25 at 1:31
1
1
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
What do you mean by a 'firmware file'? I think of firmware in the original sense of read-only memory with microcode. Do you mean the device table files? .dtb and overlay/.dtbo?
– Ribo
Nov 25 at 1:34
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
I updated my answer to hopefully clarify this.
– telcoM
Nov 25 at 11:20
add a comment |
-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...
edited Nov 25 at 17:21
GAD3R
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
add a comment |
-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...
edited Nov 25 at 17:21
GAD3R
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
add a comment |
-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...
edited Nov 25 at 17:21
GAD3R
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
-Yeah! is a device, the wireless card device, like the normal network device eth0, only this points / refers to the wireless device ...
edited Nov 25 at 17:21
GAD3R
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
edited Nov 25 at 17:21
GAD3R
25.2k1749106
edited Nov 25 at 17:21
GAD3R
25.2k1749106
edited Nov 25 at 17:21
GAD3R
25.2k1749106
25.2k1749106
answered Nov 24 at 21:54
Joke Sr. OK
611159
answered Nov 24 at 21:54
Joke Sr. OK
611159
answered Nov 24 at 21:54
Joke Sr. OK
611159
611159
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
add a comment |
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
I meant the question more precisely, is it a device in the sense of the /dev device tree. There is hardware, but Linux may not create a device structure for it.
– Ribo
Nov 24 at 23:50
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483929%2fhow-does-linux-find-configure-something-like-wlan0-when-it-is-not-a-device-tha%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please unclose this question. As edited it is pretty clear
– Ribo
Dec 16 at 20:49