没有合适的资源?快使用搜索试试~ 我知道了~
首页《Linux network driver development Training lab book》
《Linux network driver development Training lab book》
2星 需积分: 44 68 下载量 157 浏览量
更新于2023-03-16
评论 8
收藏 926KB PDF 举报
个人认为最经典的学习资料,从无到有地讲述了网卡驱动的编写过程,基于Atmel的MPU的Ethernet Controller。
资源详情
资源评论
资源推荐
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
497
Chapter 17
CHAPTER 17
Network Drivers
Having discussed char and block drivers, we are now ready to move on to the world
of networking. Network interfaces are the third standard class of Linux devices, and
this chapter describes how they interact with the rest of the kernel.
The role of a network interface within the system is similar to that of a mounted
block device. A block device registers its disks and methods with the kernel, and
then “transmits” and “receives” blocks on request, by means of its request function.
Similarly, a network interface must register itself within specific kernel data struc-
tures in order to be invoked when packets are exchanged with the outside world.
There are a few important differences between mounted disks and packet-delivery
interfaces. To begin with, a disk exists as a special file in the /dev directory, whereas a
network interface has no such entry point. The normal file operations (read, write,
and so on) do not make sense when applied to network interfaces, so it is not possi-
ble to apply the Unix “everything is a file” approach to them. Thus, network inter-
faces exist in their own namespace and export a different set of operations.
Although you may object that applications use the read and write system calls when
using sockets, those calls act on a software object that is distinct from the interface.
Several hundred sockets can be multiplexed on the same physical interface.
But the most important difference between the two is that block drivers operate only
in response to requests from the kernel, whereas network drivers receive packets
asynchronously from the outside. Thus, while a block driver is asked to send a buffer
toward the kernel, the network device asks to push incoming packets toward the ker-
nel. The kernel interface for network drivers is designed for this different mode of
operation.
Network drivers also have to be prepared to support a number of administrative
tasks, such as setting addresses, modifying transmission parameters, and maintain-
ing traffic and error statistics. The API for network drivers reflects this need and,
therefore, looks somewhat different from the interfaces we have seen so far.
,ch17.13860 Page 497 Friday, January 21, 2005 11:10 AM
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
498
|
Chapter 17: Network Drivers
The network subsystem of the Linux kernel is designed to be completely protocol-
independent. This applies to both networking protocols (Internet protocol [IP] versus
IPX or other protocols) and hardware protocols (Ethernet versus token ring, etc.).
Interaction between a network driver and the kernel properly deals with one network
packet at a time; this allows protocol issues to be hidden neatly from the driver and
the physical transmission to be hidden from the protocol.
This chapter describes how the network interfaces fit in with the rest of the Linux
kernel and provides examples in the form of a memory-based modularized network
interface, which is called (you guessed it) snull. To simplify the discussion, the inter-
face uses the Ethernet hardware protocol and transmits IP packets. The knowledge
you acquire from examining snull can be readily applied to protocols other than IP,
and writing a non-Ethernet driver is different only in tiny details related to the actual
network protocol.
This chapter doesn’t talk about IP numbering schemes, network protocols, or other
general networking concepts. Such topics are not (usually) of concern to the driver
writer, and it’s impossible to offer a satisfactory overview of networking technology
in less than a few hundred pages. The interested reader is urged to refer to other
books describing networking issues.
One note on terminology is called for before getting into network devices. The net-
working world uses the term octet to refer to a group of eight bits, which is generally
the smallest unit understood by networking devices and protocols. The term byte is
almost never encountered in this context. In keeping with standard usage, we will
use octet when talking about networking devices.
The term “header” also merits a quick mention. A header is a set of bytes (err, octets)
prepended to a packet as it is passed through the various layers of the networking
subsystem. When an application sends a block of data through a TCP socket, the
networking subsystem breaks that data up into packets and puts a TCP header,
describing where each packet fits within the stream, at the beginning. The lower lev-
els then put an IP header, used to route the packet to its destination, in front of the
TCP header. If the packet moves over an Ethernet-like medium, an Ethernet header,
interpreted by the hardware, goes in front of the rest. Network drivers need not con-
cern themselves with higher-level headers (usually), but they often must be involved
in the creation of the hardware-level header.
How snull Is Designed
This section discusses the design concepts that led to the snull network interface.
Although this information might appear to be of marginal use, failing to understand
it might lead to problems when you play with the sample code.
The first, and most important, design decision was that the sample interfaces should
remain independent of real hardware, just like most of the sample code used in this
,ch17.13860 Page 498 Friday, January 21, 2005 11:10 AM
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
How snull Is Designed
|
499
book. This constraint led to something that resembles the loopback interface. snull is
not a loopback interface; however, it simulates conversations with real remote hosts
in order to better demonstrate the task of writing a network driver. The Linux loop-
back driver is actually quite simple; it can be found in drivers/net/loopback.c.
Another feature of snull is that it supports only IP traffic. This is a consequence of the
internal workings of the interface—snull has to look inside and interpret the packets
to properly emulate a pair of hardware interfaces. Real interfaces don’t depend on
the protocol being transmitted, and this limitation of snull doesn’t affect the frag-
ments of code shown in this chapter.
Assigning IP Numbers
The snull module creates two interfaces. These interfaces are different from a simple
loopback, in that whatever you transmit through one of the interfaces loops back to
the other one, not to itself. It looks like you have two external links, but actually
your computer is replying to itself.
Unfortunately, this effect can’t be accomplished through IP number assignments
alone, because the kernel wouldn’t send out a packet through interface A that was
directed to its own interface B. Instead, it would use the loopback channel without
passing through snull. To be able to establish a communication through the snull
interfaces, the source and destination addresses need to be modified during data
transmission. In other words, packets sent through one of the interfaces should be
received by the other, but the receiver of the outgoing packet shouldn’t be recog-
nized as the local host. The same applies to the source address of received packets.
To achieve this kind of “hidden loopback,” the snull interface toggles the least signif-
icant bit of the third octet of both the source and destination addresses; that is, it
changes both the network number and the host number of class C IP numbers. The
net effect is that packets sent to network A (connected to
sn0, the first interface)
appear on the
sn1 interface as packets belonging to network B.
To avoid dealing with too many numbers, let’s assign symbolic names to the IP num-
bers involved:
•
snullnet0 is the network that is connected to the sn0 interface. Similarly,
snullnet1 is the network connected to sn1. The addresses of these networks
should differ only in the least significant bit of the third octet. These networks
must have 24-bit netmasks.
•
local0 is the IP address assigned to the sn0 interface; it belongs to snullnet0.
The address associated with
sn1 is local1. local0 and local1 must differ in the
least significant bit of their third octet and in the fourth octet.
•
remote0 is a host in snullnet0, and its fourth octet is the same as that of local1.
Any packet sent to
remote0 reaches local1 after its network address has been
,ch17.13860 Page 499 Friday, January 21, 2005 11:10 AM
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
500
|
Chapter 17: Network Drivers
modified by the interface code. The host remote1 belongs to snullnet1, and its
fourth octet is the same as that of
local0.
The operation of the snull interfaces is depicted in Figure 17-1, in which the host-
name associated with each interface is printed near the interface name.
Here are possible values for the network numbers. Once you put these lines in /etc/
networks, you can call your networks by name. The values were chosen from the
range of numbers reserved for private use.
snullnet0 192.168.0.0
snullnet1 192.168.1.0
The following are possible host numbers to put into /etc/hosts:
192.168.0.1 local0
192.168.0.2 remote0
192.168.1.2 local1
192.168.1.1 remote1
The important feature of these numbers is that the host portion of local0 is the same
as that of
remote1, and the host portion of local1 is the same as that of remote0. You
can use completely different numbers as long as this relationship applies.
Be careful, however, if your computer is already connected to a network. The num-
bers you choose might be real Internet or intranet numbers, and assigning them to
your interfaces prevents communication with the real hosts. For example, although
Figure 17-1. How a host sees its interfaces
localnet
lo
localhost
eth0
morgana
sn0
local0
sn1
local1
snullnet0
remote0
snullnet1
remote1
,ch17.13860 Page 500 Friday, January 21, 2005 11:10 AM
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
How snull Is Designed
|
501
the numbers just shown are not routable Internet numbers, they could already be
used by your private network.
Whatever numbers you choose, you can correctly set up the interfaces for operation
by issuing the following commands:
ifconfig sn0 local0
ifconfig sn1 local1
You may need to add the netmask 255.255.255.0 parameter if the address range cho-
sen is not a class C range.
At this point, the “remote” end of the interface can be reached. The following screen-
dump shows how a host reaches
remote0 and remote1 through the snull interface:
morgana% ping -c 2 remote0
64 bytes from 192.168.0.99: icmp_seq=0 ttl=64 time=1.6 ms
64 bytes from 192.168.0.99: icmp_seq=1 ttl=64 time=0.9 ms
2 packets transmitted, 2 packets received, 0% packet loss
morgana% ping -c 2 remote1
64 bytes from 192.168.1.88: icmp_seq=0 ttl=64 time=1.8 ms
64 bytes from 192.168.1.88: icmp_seq=1 ttl=64 time=0.9 ms
2 packets transmitted, 2 packets received, 0% packet loss
Note that you won’t be able to reach any other “host” belonging to the two net-
works, because the packets are discarded by your computer after the address has
been modified and the packet has been received. For example, a packet aimed at
192.168.0.32 will leave through
sn0 and reappear at sn1 with a destination address of
192.168.1.32, which is not a local address for the host computer.
The Physical Transport of Packets
As far as data transport is concerned, the snull interfaces belong to the Ethernet class.
snull emulates Ethernet because the vast majority of existing networks—at least the
segments that a workstation connects to—are based on Ethernet technology, be it
10base-T, 100base-T, or Gigabit. Additionally, the kernel offers some generalized
support for Ethernet devices, and there’s no reason not to use it. The advantage of
being an Ethernet device is so strong that even the plip interface (the interface that
uses the printer ports) declares itself as an Ethernet device.
The last advantage of using the Ethernet setup for snull is that you can run tcpdump
on the interface to see the packets go by. Watching the interfaces with tcpdump can
be a useful way to see how the two interfaces work.
As was mentioned previously, snull works only with IP packets. This limitation is a
result of the fact that snull snoops in the packets and even modifies them, in order for
the code to work. The code modifies the source, destination, and checksum in the IP
header of each packet without checking whether it actually conveys IP information.
,ch17.13860 Page 501 Friday, January 21, 2005 11:10 AM
剩余48页未读,继续阅读
杨柳_
- 粉丝: 4098
- 资源: 77
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- RTL8188FU-Linux-v5.7.4.2-36687.20200602.tar(20765).gz
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
- SPC统计方法基础知识.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论2