Sponsored Content
Special Forums IP Networking Network interface layer in Linux kernel Post 302967185 by nick_kd on Saturday 20th of February 2016 04:40:41 PM
Old 02-20-2016
Network interface layer in Linux kernel

Dear all,

lets say a linux based computer(debian) with ethernet,wifi, usb modem connected to the, linux kernel version is 3.3

Question:
  1. for each network device the network driver builds its own net_device struct and register itself with the network interface layer of the kernel.

    Code:
    struct net_device net_dev[3] = {
        {init: ethernet_init,},
        {init: wifi_init,},
        {init: usbnet_init,},
    };
    
    register_netdev(net_dev[0]);
    register_netdev(net_dev[1]);
    register_netdev(net_dev[2]);

    so in total there are 3 network devices as seen by the kernel
    now how does the kernel decide to which network interface. to use while forwarding IP packet.

    can some one please specify any link or document which answers the above question ?

Last edited by Scrutinizer; 02-20-2016 at 05:45 PM.. Reason: code tags
 

9 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Network Interface

Hi ! Does anyone know how can i get information about my network interface ... if it works in half or full duplex mode !! Thx in adivance ! Witt (4 Replies)
Discussion started by: witt
4 Replies

2. UNIX for Advanced & Expert Users

Network interface in Linux kernel

Hi, I wrote some network modules to 2.6.x Linux kernel. Im useing sock_recvmsg / sock_sendmsg (linuxsrc/include/linux/net.h ) interface to receiving and sending data in TCP mode. Im cooperating with HTTP protocol and I have a question. Supose that I have buffer I have connection client -... (2 Replies)
Discussion started by: marcintom
2 Replies

3. Solaris

What are the kernel parameter of network interface in Solaris?

Hi gurus Could anybody tell me that what are the kernal parameter of network interface in solaris Regards (3 Replies)
Discussion started by: girish.batra
3 Replies

4. Solaris

configure zones to have different network interface and network

i need to configure a zone to use different interface (bge2) than global and have connected to completely different network switch & to use its own defaultrouter and hosts file .. is it possible ..if so ..how ? Thanks (9 Replies)
Discussion started by: skamal4u
9 Replies

5. UNIX and Linux Applications

Access to network interface (Mac-network)

Hi, I'm a italian student. For my thesis I develop a gateway with protocol 6lowpan. For that I must access to network interface to develope my personal stack based on standard 802.15.4. Can you help me? I need an explanation for that. (0 Replies)
Discussion started by: berny88
0 Replies

6. IP Networking

Network interface-

Hello, Please what's the difference between: AND Thank you so much (3 Replies)
Discussion started by: chercheur857
3 Replies

7. IP Networking

network interface -

Hello, Please, how can i create a network interface with a routable IP address on linux (ubuntu) ? AND How can i desactivate an interface? Thank you so much for help. (1 Reply)
Discussion started by: chercheur857
1 Replies

8. Solaris

No network cable But Network interface is UP and Running

I've one Netra 240 After changing main board and system configuration card reader, Network is not accessible any more, Network interfaces are always UP and Running even when there is no cable connected to Network interfaces. I tried to restart and plumb/unplumb with no luck. ifconfig -a... (7 Replies)
Discussion started by: samer.odeh
7 Replies

9. UNIX for Dummies Questions & Answers

Adding a network interface to a bonded interface

I have a RHEL 5 system with a bonded interface configure using only one network port (eth0). So I have config file for ifcfg-bond0 and ifcfg-eth. I'd like to configure eth5 to be the second SLAVE in the bond. My question is, after I modify ifcfg-eth5, can I add eth5 to the bond0 interface without... (1 Reply)
Discussion started by: westmoreland
1 Replies
STRUCT 
WIMAX_DEV(9) Linux Networking STRUCT WIMAX_DEV(9) NAME
struct_wimax_dev - Generic WiMAX device SYNOPSIS
struct wimax_dev { struct net_device * net_dev; struct list_head id_table_node; struct mutex mutex; struct mutex mutex_reset; enum wimax_st state; int (* op_msg_from_user) (struct wimax_dev *wimax_dev,const char *,const void *, size_t,const struct genl_info *info); int (* op_rfkill_sw_toggle) (struct wimax_dev *wimax_dev,enum wimax_rf_state); int (* op_reset) (struct wimax_dev *wimax_dev); struct rfkill * rfkill; unsigned rf_hw; unsigned rf_sw; char name[32]; struct dentry * debugfs_dentry; }; MEMBERS
net_dev [fill] Pointer to the struct net_device this WiMAX device implements. id_table_node [private] link to the list of wimax devices kept by id-table.c. Protected by it's own spinlock. mutex [private] Serializes all concurrent access and execution of operations. mutex_reset [private] Serializes reset operations. Needs to be a different mutex because as part of the reset operation, the driver has to call back into the stack to do things such as state change, that require wimax_dev->mutex. state [private] Current state of the WiMAX device. op_msg_from_user [fill] Driver-specific operation to handle a raw message from user space to the driver. The driver can send messages to user space using with wimax_msg_to_user. op_rfkill_sw_toggle [fill] Driver-specific operation to act on userspace (or any other agent) requesting the WiMAX device to change the RF Kill software switch (WIMAX_RF_ON or WIMAX_RF_OFF). If such hardware support is not present, it is assumed the radio cannot be switched off and it is always on (and the stack will error out when trying to switch it off). In such case, this function pointer can be left as NULL. op_reset [fill] Driver specific operation to reset the device. This operation should always attempt first a warm reset that does not disconnect the device from the bus and return 0. If that fails, it should resort to some sort of cold or bus reset (even if it implies a bus disconnection and device dissapearance). In that case, -ENODEV should be returned to indicate the device is gone. This operation has to be synchronous, and return only when the reset is complete. In case of having had to resort to bus/cold reset implying a device disconnection, the call is allowed to return inmediately. rfkill [private] integration into the RF-Kill infrastructure. rf_hw [private] State of the hardware radio switch (OFF/ON) rf_sw [private] State of the software radio switch (OFF/ON) name[32] [fill] A way to identify this device. We need to register a name with many subsystems (rfkill, workqueue creation, etc). We can't use the network device name as that might change and in some instances we don't know it yet (until we don't call register_netdev). So we generate an unique one using the driver name and device bus id, place it here and use it across the board. Recommended naming: DRIVERNAME-BUSNAME:BUSID (dev->bus->name, dev->bus_id). debugfs_dentry [private] Used to hook up a debugfs entry. This shows up in the debugfs root as wimax:DEVICENAME. NOTE
wimax_dev->mutex is NOT locked when this op is being called; however, wimax_dev->mutex_reset IS locked to ensure serialization of calls to wimax_reset. See wimax_reset's documentation. DESCRIPTION
This structure defines a common interface to access all WiMAX devices from different vendors and provides a common API as well as a free-form device-specific messaging channel. USAGE
1. Embed a struct wimax_dev at *the beginning* the network device structure so that netdev_priv points to it. 2. memset it to zero 3. Initialize with wimax_dev_init. This will leave the WiMAX device in the __WIMAX_ST_NULL state. 4. Fill all the fields marked with [fill]; once called wimax_dev_add, those fields CANNOT be modified. 5. Call wimax_dev_add *after* registering the network device. This will leave the WiMAX device in the WIMAX_ST_DOWN state. Protect the driver's net_device->open against succeeding if the wimax device state is lower than WIMAX_ST_DOWN. 6. Select when the device is going to be turned on/initialized; for example, it could be initialized on 'ifconfig up' (when the netdev op 'open' is called on the driver). When the device is initialized (at `ifconfig up` time, or right after calling wimax_dev_add from _probe, make sure the following steps are taken a. Move the device to WIMAX_ST_UNINITIALIZED. This is needed so some API calls that shouldn't work until the device is ready can be blocked. b. Initialize the device. Make sure to turn the SW radio switch off and move the device to state WIMAX_ST_RADIO_OFF when done. When just initialized, a device should be left in RADIO OFF state until user space devices to turn it on. c. Query the device for the state of the hardware rfkill switch and call wimax_rfkill_report_hw and wimax_rfkill_report_sw as needed. See below. wimax_dev_rm undoes before unregistering the network device. Once wimax_dev_add is called, the driver can get called on the wimax_dev->op_* function pointers CONCURRENCY
The stack provides a mutex for each device that will disallow API calls happening concurrently; thus, op calls into the driver through the wimax_dev->op*() function pointers will always be serialized and *never* concurrent. For locking, take wimax_dev->mutex is taken; (most) operations in the API have to check for wimax_dev_is_ready to return 0 before continuing (this is done internally). REFERENCE COUNTING
The WiMAX device is reference counted by the associated network device. The only operation that can be used to reference the device is wimax_dev_get_by_genl_info, and the reference it acquires has to be released with dev_put(wimax_dev->net_dev). RFKILL
At startup, both HW and SW radio switchess are assumed to be off. At initialization time [after calling wimax_dev_add], have the driver query the device for the status of the software and hardware RF kill switches and call wimax_report_rfkill_hw and wimax_rfkill_report_sw to indicate their state. If any is missing, just call it to indicate it is ON (radio always on). Whenever the driver detects a change in the state of the RF kill switches, it should call wimax_report_rfkill_hw or wimax_report_rfkill_sw to report it to the stack. COPYRIGHT
Kernel Hackers Manual 2.6. July 2010 STRUCT WIMAX_DEV(9)
All times are GMT -4. The time now is 10:21 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy