It may be a stupid question. I'm confused.
Regarding the radio on a Radio Interface Layer (RIL) context.
By "radio", one means the GSM radio or the wi-fi radio?
The Android Open Source Project provides a Radio Interface Layer (RIL) between Android telephony services (android.telephony) and the radio hardware.
It consists of a stack of two components: a RIL Daemon and a Vendor RIL. The RIL Daemon talks to the telephony services and dispatches "solicited commands" to the Vendor RIL. The Vendor RIL is specific to a particular radio implementation, and dispatches "unsolicited commands" up to the RIL Daemon
So from this point of view it points to GSM
Related
I am currently working on some preliminaries for the integration of Apple CarPlay on an infotainment unit (IU) based on Linux. One requirement of Apple is a USB role reversal, where the IU starts as USB host and becomes a USB device. The Apple device is in the end the USB Host.
The Apple specification requires, that the IU must present a configuration with three different interfaces, an iAP2 interface, a USB NCM control interface and a USB NCM data interface. An example configuration is given in the specification. It defines things like Class, Subclass, Protocol, Attributes, Endpoints, etc. This required configuration seems to be covered by the Device descriptor, configuration descriptor, interface descriptor and endpoint descriptor which is supplied by the device upon connection to a host.
For the NCM support, I activated the USB Gadget support and set Network Control Model (NCM) Support under USB Gadget precomposed configurations. For the USB interface, we use the DWC3 driver. As soon as I set the driver into the device mode, this NCM gadget driver is loaded and a new NIC appears.
How can I configure the USB descriptors of the USB device (the linux based IU) which are sent to the USB host (the Apple device)? As said above, two NCM interfaces and one iAP2 interface must be offered.
I have found some hints that this might be done with libcomposite through /sys/kernel/config/usb_gadget/ once the configfs is enabled (e.g. https://unix.stackexchange.com/questions/631138/unable-to-set-usb-gadget-device-class-and-protocol). Is this somewhere documented? Shall different endpoints have subfolders like they have under /sys/bus/usb/devices?
Afaik each interface can have a separate driver. Does this apply for both sides, Host and devicen side?
How are the driver and the defined interfaces in the descriptors linked? I assume the USB device driver must have some sort of configuration of the descriptors as well as the associated drivers for each interface?
The two NCM interfaces shall be handled by the NCM driver and the iAP2 interface by the iAP2 driver.
As I figured it out now, I would like to answer my own questions and provide some details to this topic.
USB Descriptors of the USB device can be configured through the configfs. Therefore CONFIG_USB_CONFIGFS needs to be enabled in buildroot and the corresponding gadget (Network Control Model (CDC NCM) in my case) needs to be selected (<*>).
You then need to mount the configfs, create a new folder for the gadget and will find several files in place, where you can customize some of the USB descriptors. This procedure is described in detail in the kernel configuration docu for the Linux USB gadget configurable through configfs. They list an example directory structure which tells you what descriptors are modifyable
./strings/0x409/serialnumber
./strings/0x409/product
./strings/0x409/manufacturer
./configs/c.1/bmAttributes
./configs/c.1/MaxPower
./bcdUSB
./bcdDevice
./idProduct
./idVendor
./bMaxPacketSize0
./bDeviceProtocol
./bDeviceSubClass
./bDeviceClass
The Gadget function itself can also offer configuration through the configfs, however this depends on the used gadget. In case of the NCM, the MAC Addresses, the interface name and queue length multiplier for high and super speed can be configured
./functions/ncm.usb0/ifname
./functions/ncm.usb0/qmult
./functions/ncm.usb0/host_addr
./functions/ncm.usb0/dev_addr
What is called interface on the USB host side is a function on the USB device side. When you create/associate a new function (like NCM) to the gadget, this will appear as interface on the USB host side (Some functions like NCM will create multiple interfaces). You can assign multiple functions to the gadget (mass storage, MIDI, NCM, ...) and the host will see multiple interfaces. The configuration of those functions/interfaces e.g. regarding endpoints is limited to the files available in the configfs. Endpoints, Packet size, etc regarding NCM is not configurable as this is more or less hardcoded in the source code which also defines the remaining descriptors, not configurable through the configfs and the behavior of the function itself.
If a configuration beyond the offered files in the configfs is required, the source code of the function needs to be changed. But one then needs to take care, that this still reflects the capabilities of the interface!
In Wikipedia of Netfilter article， there is a figure Packet flow in Netfilter and General Networking.
the hop of "routing decision" and "reroute check" have multi next-hop, and the next-hops are very similer:
Who can tell me why and how to choose the next hop, with example is better.
Thank you.
After my learning about Linux networking，I think the key point is the “bridge device”， it worked on the Link Layer，and used for Virtual machain，Container，tunnel and so on.
If the Host machain communicate with outer network, Only "Network Layer" route will pass though;
IF the Virtual machain communicate with the outer network, Only "Link Layer" route will pass though;
IF Host machain communicate with the Virtual machains、Containers， it will use the route from Link Layer to "Network Layer" or vice versa.
The "Link Layer" stand for data that will use virtual bridge device.
I am writing an app that is suppose to work without a connection to mobile carrier and without local WiFi. Each device will act as transmitter, receiver and router.
My main challenge so far is that I cannot figure out how exactly MultipeerConnectivity works as documentation on MC is really limited. Apple denied revealing technical specification of MC claiming it's a proprietary network stack, so I have to rely on network sniffers and reverse-engineering which is not the quickest way to figure out how MC works.
Suppose I have 100 devices forming a mesh network in such way that each device is within the range of at least one other device and at maximum three other devices.
Is there any way to send a message from node A to node B that is not within the range of node A without the need to broadcast the message to all other nodes? I mean that message should be properly routed through all other nodes.
Does MC include a routing layer too or I have to write it myself?
From what I can see ad hoc delay tolerant wireless networks is still a hot subject in research.
These slides on ad hoc delay tolerant wireless network shed more light on the subject as it was a few years ago. And also this paper. Has Apple progressed it much with MC?
I cannot really see any way to send a message between nodes not directly connected to each other without flooding.
Correct?
The MCSession Reference states that
Sessions currently support up to 8 peers, including the local peer.
Also, the overview you cited says
In the discovery phase, your app uses a browser object […] to browse for nearby peers[.]
Moreover, the documentation on managing peers manually suggests that all peers in a session must be connected with each other to have them in a session.
This is suggesting that the framework only covers the communication between nearby devices, as in 'reachable by bluetooth or WiFi'. Naturally, those devices do not need complex routing, as they do communicate with each other and the benefit of the framework is simple multicasting between nearby devices, from a programmers' point of view.
As far as your question goes, this is about it - trivially, since all peers an a MCSession have links to each other - there is no routing needed.
This does however, allow you to construct a routing layer pretty easy.
Given your scenario, there will be multiple MCSessions with devices being part of at least one. All devices that are part of more than one MCSession do become routers and interconnect the MCSessions with each other.
The rest of the task should be straight forward; defining a namespace for addressing devices and implementing a routing protocol of your choice.
The old days of the internet, with unstable dialup connections, might be a plus factor for you as the routing protocols in place are rather stable in regards of link loss.
Here are two good starting points for you to make your choice of better fit:
Link state routing
Distance vector routing
We're attempting to enable a number of mDNS advertised services on our campus
wide wireless network, most notably airplay. In our case, the airServers would
sit on our wired network, so we need to advertise the services manually either
with DNS-SD or mDNS on the wireless side. We've gotten that working using
static service advertisements in avahi and it's pretty slick, but we have a
scaling problem.
We have potentially 150 AirServer hosts in a variety of classrooms around the
campus. If we were to enable all of them, the list to choose from on iPads
would be outrageously large (to say nothing of students thoroughly enjoying
taking over an AirServer from across campus when a faculty member forgets to
change the password).
What we would like to do is segregate our wireless network on a single vlan per
building basis to form 27 mDNS segments and then run avahi to advertise the
services in each segment, preferably on a single, multi homed host with access
to all of the segments.
I was hoping that avahi-daemon would take a parameter in the avahi-daemon.conf
that points to a unique services directory, so that I could have multiple
config files, each with a different allow-interfaces clause and a pointer to a
different services directory, but that doesn't appear to be a configurable
option.
I was thinking of chroot jailing multiple copies of avahi, but that seems
really kludgy.
Am I missing some more obvious strategy to handle this without creating 27
separate hosts?
Thanks much!
JD
It is possible to achieve what you want if you build your own application for publishing the services in the interfaces you want. This method call is from GNUStep "base" framework, class GSAvahiNetServices (can be used on Linux) and the method is based on the Avahi API.
- (id) initWithDomain: (NSString*)domain
type: (NSString*)type
name: (NSString*)name
port: (NSInteger)port
avahiIfIndex: (AvahiIfIndex)anIfIndex
avahiProtocol: (AvahiProtocol)aProtocol
As you can see it is possible to specify the network interface index you want the service to be published on. You can also limit the protocol (IPv4 or IPv6). If you want one service to be available in more then one interface, just publish it in each interface.
I am willing to build a prototype of network appliance.
This appliance is suppose to transparently manipulate Ethernet packets. It suppose to have two network interface cards having one card connected to the outside leg (i.e. eth0) and the other to the inside leg (i.e. eth1).
In a typical network layout as in the attached image, it will be placed between the router and the LAN's switch.
My plans are to write a software that hooks at the kernel driver level and do whatever I need to do to incoming and outgoing packets.
For instance, an "outgoing" packet (at eth1) would be manipulated and passed over to the other NIC (eth0) which then should be transported over to the next hope
My questions are:
Is this doable?
Those NIC's will have no IP address, is that should be a problem?
Thanks in advance for your answers.
(And no, there is no such device yet in the market, so please, "why reinvent the wheel" style of answers are irrelevant)
typical network diagram http://img163.imageshack.us/img163/1249/stackpost.png
I'd suggest libipq, which seems to do just what you want:
Netfilter provides a mechanism for passing packets out of the stack for queueing to userspace, then receiving these packets back into the kernel with a verdict specifying what to do with the packets (such as ACCEPT or DROP). These packets may also be modified in userspace prior to reinjection back into the kernel.
Apparently, it can be done.
I am actually trying to build a prototype of it using scapy
as long as the NICs are set to promiscous mode, they catch packets on the network without the need of an IP address set on them. I know it can be done as there are a lot of companies that produce the same type of equipment (I.E: Juniper Networks, Cisco, F5, Fortinet ect.)