I'm trying to implement vlans on a target programmatically.
But first I wanted to set up vlans manually to help get a better understanding of vlan setup. So I setup a vlan manually on my development system (ubuntu) using the vconfig/ifconfig command combination, but using the same command combination on the intended target doesn't work.
Both systems use the same 8021q driver so the method of informing the lower level Ethernet driver of the vlan info should be the same (I would think). After looking at the vlan driver source it appears that it collects the vlan info and adds the info the sk_buff structure which is eventually passed to the ethernet driver, but it's not obvious where the vlan magic is suppose to happen (ethernet driver or 8021q driver).
I looked at the source for the target system’s ethernet driver and it supports an ioctl method of setting up a vlan. But this does not seem like the conventional way that Linux sets up a vlan in the ethernet driver.
By what mechanism does the vlan driver (8021q.ko) tell the Ethernet hardware about a vlan?
Is it a special api call to the ethernet driver to set up a vlan in hardware, or should the vlan driver be adding the vlan tags to the packet?
Any info on vlan implementation would also be helpful too.
Related
My embedded linux board has usb-net gadget functionality. From my host computer I am able to establish ethernet over usb connectivity. I am trying to understand how the different layers of the usb gadget subsystem layers work together.
In the device tree, I can see the platform specific udc driver and in the kernel configuration I can see the USB Gadget and Ethernet Gadget support being enabled in the kernel drivers. So as I understand the g_ether driver gets built-in part of the kernel.
What configuration creates the usb gadget interface and endpoint and links it to the upper layer driver (g_ether) and creates the usb-net gadget ethernet interface ?
Where to define the usb class function of the gadget and load a different upper layer driver ?
I am running version 5.10.36 kernel on my system. After some research and study, this is what I know so far.
So during linux kernel build, I have following option setup in menuconfig.
Symbol: USB_ETH [=m]
Prompt: Ethernet Gadget (with CDC Ethernet support)
Defined at drivers/usb/gadget/Kconfig:628
Depends on: <choice> && NET
Location:
-> Kernel configuration
-> Device Drivers
-> USB support (USB_SUPPORT [=y])
-> USB Gadget Support (USB_GADGET [=y])
-> USB Gadget Drivers (<choice> [=y])
This configuration gives a predefined USB net gadget interface with CDC ethernet support and required end-point configuration. This driver is g_ether.
The end point configuration is predefined in the file
drivers->usb->gadget->function->f_ecm.c
configFS can be used to configure a custom usb gadget interface from the user-space level.
In Linux, when the wifi interface (wlan0) is in "Managed" mode, we can run the following command to scan available WiFi access points:
$iwlist wlan0 scan
But this command stops to work when the interface is in "Master" mode:
$iwlist wlan0 scan
wlan0 No scan results
Is this a hard constraint of WiFi chip, or a limit in Linux software?
Is there a way to scan for available WiFi access points while the current interface itself is in "Master" mode, i.e. itself is an Access Point.
Very good question. Results of some minor research on the matter are as follows.
https://elixir.bootlin.com/linux/latest/source/net/mac80211/cfg.c#L2439
In ieee80211_scan() one can notice that the function tests NL80211_FEATURE_AP_SCAN flag in the set of features advertised by the underlying wireless device driver. That effectively means that, indeed, it's a constraint, but it's likely imposed by the specific vendor / driver / device rather than by Linux generic code.
https://elixir.bootlin.com/linux/latest/C/ident/NL80211_FEATURE_AP_SCAN
One may try to search for the said feature flag among the available wireless drivers. For example, my Wi-Fi card needs ath9k driver, and I don't see the latter in the list of drivers that advertise the said feature. Hence, my Wi-Fi card can't scan while in AP/master mode. Indeed, when I run (as root) iwlist dev_name scan or iw dev dev_name scan, I observe very similar output (Interface doesn't support scanning : Operation not supported and command failed: Operation not supported (-95) respectively).
ovs-vsctl add-port hostInterface hostveth tag=9. This command adds hostveth to bridge and also the packets coming out of hostveth are tagged with vlan id 9. I'm looking for similar commands for linux bridge
My setup is
hostInterface(bridge) -> hostvethpair -> ns1vethpair(another namespace)
hostinterface and hostvethpair are is same default namespace but ns1vethpair in different namespace.
I want packets coming out of hostvethpair to be tagged with vlan id and these tagged packets should be sent to bridge. Im able to achieve this with ovs bridge using above command. Is there any command that can do the same in Linux bridge. If so, can you share an example?
Thanks in advance
I think I got the solution for what i'm looking for. It can be done via bridge vlan filtering rules. (bridge vlan add).
I'm trying to create a usb based ethernet device on my computer, basically I want to tell my computer (linux based) that one of its usb ports is actually an ethernet port. I have done extensive research and while it's supposed to be possible, I can't find any examples of code / commands to run.
According to wikipedia:
The USB-eth module in Linux makes the computer running it a variation of an Ethernet device that uses USB as the physical medium. It creates a Linux network interface, which can be assigned an IP address and otherwise treated the same as a true Ethernet interface. Any applications that work over real Ethernet interfaces will work over a USB-eth interface without modification, because they can't tell that they aren't using real Ethernet hardware.
So in theory, this should be possible, I just need some help or a gentle nudge in the right direction to get this thing rolling. What I'm NOT trying to do is plug a usb to ethernet dongle/adapter into my computer, I have several of those lying around and that doesn't help me out at all.
this is ethernet-over-usb
https://en.wikipedia.org/wiki/Ethernet_over_USB
without external hardware you can try the CDCether kernel module and ethtool ( then you can only connect to a usb device that operates in usb device mode )
( https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_device_networking , http://tldp.org/HOWTO/Motorola-Surfboard-Modem/usb.html, http://www.linux-usb.org/usbnet/ )
else you need a physical adapter for this. the adapter translates between the protocols and the different hardware interfaces.
in usb protocol can only be one host in a network, therefore you need at least a host-to-host cable ( http://www.linux-usb.org/usbnet/ ) if you want to connect two usb host devices, i.e. two pcs
required kernel module ( driver ) when using a physical adapter is either usbnet ( with its minidrivers ) or usb-eth
Wanted to know how a device is detected in Linux? What exactly is the workflow of the device driver in device detection?
It is the Kernel's job to detect devices as it has the lowest level access to the available hardware. When the Kernel scans through all available addresses it maintains a list of Vendor and Device IDs.
To use PCI bus devices as an example, there is a Vendor ID and a Device ID associated with all PCI devices.
Device drivers are written in such a way as to identify to the Kernel what kinds of devices the driver is able to control. Drivers may advertise that they can handle more than one vendor and device type combination.
The Kernel will allocate a driver to each device based on these IDs. A similar process is in place for USB devices. Older technologies like legacy devices (serial ports, parallel, ps2 mice/keyboards) will have explicitly hardcoded methods of associating particular drivers with devices.
You can use the Linux commands lsusb and lspci to see the available devices and IDs on your system.
So in direct answer to your question - the device driver usually does nothing to detect the device, at least in the first instance. Once the driver is associated with a device (by the Kernel) the driver will likely do further interrogation of the device to ensure it contains the right firmware or is the right hardware revision, etc.