I'm confused about what parts of a linux system do what when it comes to networking. I'm looking for a good reference about more than just the network layers. Starting with network layers though, using the OSI 7 Layer model:
7-Application
6-Presentation
5-Session
4-Transport
3-Network
2-Data Link
1-Physical
At what point do networking go from hardware to kernel to application software? I suspect at (1) it's all hardware and just signals on wires or over wifi At (2) it reaches some network interface, but do they make frames, or do the interface drivers? (3) network, IP, I'm guessing handled by the OS? (4) still kernel or at least sockets provided by low-level libraries in C/C++? (5) Not entirely sure, but thinking this is still low level, where SYN, SYN/ACK, ACK take place. And then finally (6) user-space, or application space of actual data, but in raw form. And then (7) all application, and the application can determine the intents and behavior of network communication.
Related
We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
Recently I encountered several questions on SO regarding working with sockets on a very low level. Here's an example. While looking for an answer, I realised that sockets have relatively low capabilities on OSI Level 2. On Linux, we can specify a protocol when creating a socket, but obviously not all Level 2 protocols are present in the list.
While it is possible to assemble and send an ethernet frame, it's (presumably) not possible to send a 802.11 packet - though it looks like wifi device drivers do convert ethernet frames to wifi packets and vice versa.
This made me wonder, if there are more possibilities in reading and writing directly to device files like eht0, ath0? Is it a socket implementation who usually writes to these files, or a device driver? And who's on receiving side - a NIC driver, a peripheral bus controller?
I want to scan the signal strength received from 3 AP.
I would be happy if that could happen every 300ms (max.500ms). I flashed OpenWRT on the routers.
I was seeking for a good tool to do that.
First I found iwconfig which worked, but only with networks that I was connected to. So I used iwlist (iw didn't work- maybe I need to update it?). Do you know how accurate is the output of it? Can I trust it?
After that, I came across the IOCTL. It looks really powerful* and professional. But is the output from getting the signal stregnth from a WIFI more reliable than the simple method like iwlist/iw?
*even too much powerful as I failed to compile any program I wrote using it
If you want to determine the signal strength of WLAN access points to which you are not connected, scanning is the right way.
The scanning is performed by the wireless network card with much or little "help" from the driver, depending on the design of the wireless card. There are cards (chipsets, to be more specific) that have their own processor and run their own firmware code independently from the host computer. On the other end, there are "stupid" cards where the driver on the host computer does most of the work.
Between the driver and the rest of the operating system, there is an interface (API) for sending commands to the driver and reading back information in a standardized way. With Linux, there are at least two different APIs. The older one is named Wireless Extensions, and the newer one is named cfg80211. Normally, a driver supports only one of the APIs. Most current drivers use cfg80211, but there may be older drivers that still use Wireless Extensions.
For each of the two APIs, there's a user-space tool (or family of tools) to use it. For Wireless Extensions, there is iwconfig (and iwlist, iwpriv etc.) For cfg80211, there is just iw.
So, the questions about the right tool depends on what API the wireless driver uses. To add confusion ;-), cfg80211 does some emulation which allows you to perform some Wireless Extension calls to drivers that use the newer cfg80211 API.
Regarding your questions about ioctl(): This is a generic method for communication between user-space and kernel-space in Unix operating systems. The old Wireless Extensions API uses ioctl(). The newer cfg80211 API does not use an ioctl()-based interface, but uses nl80211 instead.
To sum it up: whether to use iw/cfg80211/nl80211 or iwconfig/Wireless Extensions/ioctl depends on the driver or your wireless card.
Regarding your desired scanning interval, I would say that 300ms is rather short. This is because for a useful scan, the client needs to leave its current channel for a short time, switch to another channel and listen to signals from other access points on this channel. Since leaving its channel interrupts communication, these off-channel times are usually kept short and are carried out infrequently.
Calling iw <dev> scan or iwlist <dev> scan, respectively, will not necessarily cause a new scan, but may return an old (cached) list of access points. Depending on your wireless card/driver it may be (im)possible to enforce a new scan.
I want to implement a driver in Linux, that has a Ethernet stack but the data going out on hardware will be a serial port. Basically, I want to register my serial port as a Ethernet driver. Does anyone have any idea if this is possible?
I want to be able to push IPv6 and/or UDP packets out of the serial port and in a similar way receive the packets via a serial port and pass it up the Ethernet stack.
I do not want to use the solution of serial-to-ethernet convertors(external hardware that convert a serial port to a ethernet port) but have that in my PC itself.
I tried PPP over the serial port and it works well. I am also told that I can do FTP, HTTP etc using the PPP. Reference to this - http://www.faqs.org/docs/Linux-HOWTO/Serial-Laplink-HOWTO.html
I have tried to hack the code from a RealTek Ethernet driver with a serial driver but not able to gain much success. Rather I do not know the stack of either to actually do anything meaningful. Any advice, guidance or tutorials would be helpful.
Thanks
Aditya
You need to get back to de basics on networking, the way I understand you question is: "I have a serial port and I want to use is an Ethernet link". Sorry to crush your dreams but you don't have the real hardware to do so, I'll elaborate on it.
A serial connection is a physical connection that requires 3 wires (at least) tx, rx and ground. On the logical side you have an IC that coverts binary data into signals that are represented by discrete voltage ranges.
Ethernet is a layer 2 protocol, the layer 1 is provided by the technology used to transmit the signals (coax, up, fiber etc.) As you might see by now, you need a different set of hardware to convert the logical Ethernet frames into a stream of digital numbers, in fact this is call framing.
Since Ethernet has been an easy to use protocol it has been implemented as e preferred protocol for many network operators, of course one of the biggest is PPPoE where you have a PPP session over an Ethernet link. Of course this won't work with your example neither since you're trying the opposite.
If you're just learning and have all the time in the world you can attempt to write your own Ethernet framer over serial lines. This means you need to implement IEEE802.3 into the driver and then you need to serialize the data to push it as a stream of bits over the serial line. Of course note the following drawbacks:
Your driver won't be able to fully support Ethernet, you need some support at hardware level to implement some signaling (example, auto negotiation, CSMA/CD, etc)
You driver will be pretty much useless unless you back in time where 115.2kbps is top speed in data transfers
IMHO there are more exciting projects that you can pick up in the networking field for device drivers. You can for example attempt to buy a NIC and develop the device driver for it from scratch and you can optimize certain areas. Finally, remember that most of the Ethernet implementations are now done in hardware so you don't have to do anything but filling a few registers on the MAC and voila!
SLIP and PPP do already what you want.
My colleague and I are mining the GPRS MODEM market for a module suitable for use with embedded Linux. During the market scan, we see that several vendors highlight that their MODEMs include an embedded TCP/IP stack.
This makes me wonder: when we are using embedded Linux which already contains a TCP/IP stack and connects using PPP, will it make use of the stack included in the GPRS MODEM at all?
My current assumption is that the stack is included for use with tiny microcontroller OS that do not supply their own stack. Also some of the MODEMs allow for running small applications IN the MODEM baseband processor which could explain the embedded stack...
So: is the TCP/IP stack supplied by the GPRS MODEM superfluous when using it with an HL OS or did I overlook something?
It is almost certainly superfluous in your use case.
Most cellular modem products are cut-down versions of products designed for use in mobile phones. Obviously, in a phone application, the TCP/IP stack is required, along with a whole pile of other functionality.
A typical GPRS modem probably contains an ARM9 processor, and this is not greatly taxted running just the modem software. For many smaller applications it certainly provides sufficient performance to run the entire application (think of something like a vending machine indicating that it is nearly empty, for example), and a TCP/IP stack might be helpful here.
There is a slightly cynical possible explanation, too. Many mobile phone stacks have a bit more software coupling than their manufacturers would like to admit to, and it may turn out that it is simply not worth the effort to remove the TCP/IP stack.
In your application, it is almost certainly the best option to use the AT command interface (this is an extension of old-fashioned dial-up modem command set to allow you to fetch information such as signal strength, network status etc.
This is the EXACTLY same question I been asking myself these two days. ^^
After some study and asking around, I found this:
In the case of a smart phone such iPhone/android, TCP/IP are running on Application Processors(AP) as part of the OS. Baseband Processors(BP) are simply network modems (think of the 56k dial-up modem and PC setup in ancient time). Of course BP will be running mobile network stack(GSM, CDMA, LTE...) to hop on cellular network, but to AP, it's transparent and simply does modulation/demodulation work for the wireless network. Modems receives AT commands and can switch between command mode and data mode in operations. In data mode, the protocol between AP and BP is normally PPP over serial (! correct me if i am wrong here). So TCP/IP/PPP/serial.
Embedded TCP/IP stack found in some BP are meant to provide an entire abstraction for certain applications whereby network stack is not available due to system constraints or simply made to be simple. A TCP/IP stack is then very useful in BP. As you mentioned, some BP (e.g infenion) does have extra processing power for user application and/or network stack. AP, in this case, is even not needed. This is a typical setup of a function phone(such as Nokia brick). Extension of AT command sets are then provided by BP to create a socket or even a FTP connection.