精华内容
下载资源
问答
  • UDP checksum

    2019-09-27 20:34:04
    今天在驱动里面改了UDP packet的payload,发出这个UDP包之后,对方在驱动里面能收到这个包。 但是indicate给OS之后,APP却收不到这...UDP字段占用8个字节,checksum就是最后的两个字节,如果checksum==0,那么Receiv...

    今天在驱动里面改了UDP packet的payload,发出这个UDP包之后,对方在驱动里面能收到这个包。

    但是indicate给OS之后,APP却收不到这个包。Debug了一段时间之后,我怀疑应该是checksum之类的问题,果然...

    简单讲下UDP的checksum:

    UDP字段占用8个字节,checksum就是最后的两个字节,如果checksum==0,那么Receiver这边就不会检查Payload的checksum。否则,OS检查checksum,发现不对的时候会drop这个包。

    有函数可以配置socket,enable/disable checksum。如下disable checksum:

    char nochecksum=0;
    setsockopt(sock,IPPROTO_UDP,UDP_NOCHECKSUM,&nochecksum,sizeof(nochecksum));

    这段代码的作用其实就是把UDP的checksum那两个Byte设成0。

    我是直接在驱动里面把这两个Byte强制设成了0,发现ok,对方APP能正常收包了。

     

     

    转载于:https://www.cnblogs.com/zzSoftware/archive/2013/02/20/2919334.html

    展开全文
  • udp tcp checksum

    2014-11-29 21:08:11
    udp tcp checksum
  • ) has the udp checksum bit set but not the other checksum bits. For a tcp packet with a valid checksum I would expect the tcp checksum bit to be set, not the udp one. <p>Unless I am missing something ...
  • UDPchecksum

    万次阅读 2010-03-09 22:40:00
    简单说,UDPchecksum计算,就是伪首部+UDP首部+UDP数据。伪首部并不是IP首部的一部分,而是由IP首部中的源IP(32 bit)、目的IP(32 bit)、协议号(8 bit),和UDP首部中的UDP长度(16 bit)共同拼凑起来的。  ...
    只讨论IPv4
    1. 概念
    简单说,UDP的checksum计算,就是伪首部+UDP首部+UDP数据。伪首部并不是IP首部的一部分,而是由IP首部中的源IP(32 bit)、目的IP(32 bit)、协议号(8 bit),和UDP首部中的UDP长度(16 bit)共同拼凑起来的。
     
    2. 实现
    《TCP/IP详解》卷1第11章第3节中指出:UDP检验和的基本计算方法与IP首部检验和计算方法相类似(16 bit字的二进制反码和),但是它们之间存在不同的地方。
    首先,UDP数据报的长度可以为奇数字节,但是检验和算法是把若干个16 bit字相加。解决方法是必要时在最后增加填充字节0,这只是为了检验和的计算(也就是说,可能增加的填充字节不被传送)。
    其次,UDP数据报和TCP段都包含一个12字节长的伪首部,它是为了计算检验和而设置的。伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地(例如,IP没有接受地址不是本主机的数据报,以及IP没有把应传给另一高层的数据报传给UDP)。
     
    《TCP/IP详解》卷2第23章第6节第2小节中说明:
    在计算UDP检验和时使用以下三个事实:(1)在伪首部中的第三个32 bit字看起来与IP首部中的第三个32bit字类似:两个8 bit值和一个16 bit值。(2)伪首部中三个32 bit值的顺序是无关的。事实上,Internet检验和的计算不依赖于所使用的16 bit值的顺序。(3)在检验和计算中另外再加上一个全0的32 bit字没有任何影响。
     
    需要注意的是,并不是所有的UDP都一定包含checksum,这是一个可选填的区域。《RFC 768》中说:假如checksum的运算结果为0,那么传输的checksum将全为1(即用0xFFFF代替0x0000),因为这在补码运算中是等效的。而如果传输的checksum为全0(0x0000),就说明发送方并没有计算checksum (for debugging or for higher level protocols that don't care)。所以实现代码需要在验证checksum之前,先判断checksum是否存在。
     
    BSD 4.4中的实现代码如下:
    /* udpcksum.c - udpcksum */
    #include 
    #include 
    #include
    /*------------------------------------------------------------------------
     *  udpcksum -  compute a UDP pseudo-header checksum
     *------------------------------------------------------------------------
     */
    unsigned short
    udpcksum(struct ep *pep, int len)
    {
         struct ip *pip = (struct ip *)pep->ep_data;
         struct udp *pudp = (struct udp *)pip->ip_data;
         unsigned short *sptr;
         unsigned long ucksum;
         int  i;
         ucksum = 0;
         sptr = (unsigned short *) &pip->ip_src;
         /* 2*IP_ALEN octets = IP_ALEN shorts... */
         /* they are in net order.  */
         for (i=0; i<IP_ALEN; ++i)
             ucksum += *sptr++;
         sptr = (unsigned short *)pudp;
         ucksum += hs2net(IPT_UDP + len);
         if (len % 2) {
             ((char *)pudp)[len] = 0; /* pad */
             len += 1; /* for the following division */
         }
         len >>= 1; /* convert to length in shorts */
         for (i=0; i<len; ++i)
             ucksum += *sptr++;
         ucksum = (ucksum >> 16) + (ucksum & 0xffff);
         ucksum += (ucksum >> 16);
         return (short)(~ucksum & 0xffff);
    }
    

    struct ep 为Ethernet Packet

    struct ip 为IP
    struct udp 为UDP

     

    IP_ALEN  IPv4中一个IP的长度为4字节,所以这里为4

    IPT_UDP UDP协议号,0x11 (17)

     


    3. 特殊情况
     
    在我的vista机器上使用winpcap抓取数据包,通过nslookup查询www.baidu.com时,发送的UDP包的checksum只计算了伪首部,并未计算UDP首部和数据。经过google,了解到,之所以会有这样的现象,是因为操作系统为了提高效率,将大部分checksum的计算交给了硬件,即网卡(NIC)。本文提供了两种方案来解决这个问题。
     
    方案A
    事先保存网络字节序的本机IP地址,在处理UDP数据包前先比较源IP和本机IP,相等说明是这是发送的数据包,可以跳过checksum校验,否则说明是收到的数据包,进行checksum校验。IPv4中只是4字节的IP地址比较,代价相当小,可以忽略不计。
    优点:实现非常简单,代价小。
    缺点:未对发送数据包的checksum验证,若开启混杂模式,且内网有伪装IP攻击,则不能检查。
     
    方案B
    同时进行伪首部和完整UDP包的checksum校验,其中一项通过则认为该UDP包正确。因多了一次校验,效率会降低,优化算法后,代价也可以忽略不计。
    优点:实现较简单,代价小。能够弥补方案A的缺点。
    缺点:同时校验两项,存在误码UDP的数据包的checksum有可能与该数据包的伪首部checksum相同。
     
     
    4. 参考
    《TCP/IP详解》
    《RFC 768》
     
     
     
     
    ============================================================================================================= 

    == 下为附文 

    RFC 768                                                        J. Postel
                                                                         ISI
                                                              28 August 1980
     
                             User Datagram Protocol
                             ----------------------
    Introduction
    ------------
    This User Datagram  Protocol  (UDP)  is  defined  to  make  available  a
    datagram   mode  of  packet-switched   computer   communication  in  the
    environment  of  an  interconnected  set  of  computer  networks.   This
    protocol  assumes  that the Internet  Protocol  (IP)  [1] is used as the
    underlying protocol.
    This protocol  provides  a procedure  for application  programs  to send
    messages  to other programs  with a minimum  of protocol mechanism.  The
    protocol  is transaction oriented, and delivery and duplicate protection
    are not guaranteed.  Applications requiring ordered reliable delivery of
    streams of data should use the Transmission Control Protocol (TCP) [2].
    Format
    ------
                                        
                      0      7 8     15 16    23 24    31  
                     +--------+--------+--------+--------+ 
                     |     Source      |   Destination   | 
                     |      Port       |      Port       | 
                     +--------+--------+--------+--------+ 
                     |                 |                 | 
                     |     Length      |    Checksum     | 
                     +--------+--------+--------+--------+ 
                     |                                     
                     |          data octets ...            
                     +---------------- ...                
                          User Datagram Header Format
    Fields
    ------
    Source Port is an optional field, when meaningful, it indicates the port
    of the sending  process,  and may be assumed  to be the port  to which a
    reply should  be addressed  in the absence of any other information.  If
    not used, a value of zero is inserted.
     
     
    Postel                                                          [page 1]
                                                                 28 Aug 1980
    User Datagram Protocol                                           RFC 768
    Fields
     
    Destination  Port has a meaning  within  the  context  of  a  particular
    internet destination address.
    Length  is the length  in octets  of this user datagram  including  this
    header  and the data.   (This  means  the minimum value of the length is
    eight.)
    Checksum is the 16-bit one's complement of the one's complement sum of a
    pseudo header of information from the IP header, the UDP header, and the
    data,  padded  with zero octets  at the end (if  necessary)  to  make  a
    multiple of two octets.
    The pseudo  header  conceptually prefixed to the UDP header contains the
    source  address,  the destination  address,  the protocol,  and the  UDP
    length.   This information gives protection against misrouted datagrams.
    This checksum procedure is the same as is used in TCP.
                      0      7 8     15 16    23 24    31 
                     +--------+--------+--------+--------+
                     |          source address           |
                     +--------+--------+--------+--------+
                     |        destination address        |
                     +--------+--------+--------+--------+
                     |  zero  |protocol|   UDP length    |
                     +--------+--------+--------+--------+
    If the computed  checksum  is zero,  it is transmitted  as all ones (the
    equivalent  in one's complement  arithmetic).   An all zero  transmitted
    checksum  value means that the transmitter  generated  no checksum  (for
    debugging or for higher level protocols that don't care).
    User Interface
    --------------
    A user interface should allow
      the creation of new receive ports,
      receive  operations  on the receive  ports that return the data octets
      and an indication of source port and source address,
      and an operation  that allows  a datagram  to be sent,  specifying the
      data, source and destination ports and addresses to be sent.
     
     
    
    [page 2]                                                          Postel
    28 Aug 1980
    RFC 768                                           User Datagram Protocol
                                                                IP Interface
     
    IP Interface
    -------------
    The UDP module  must be able to determine  the  source  and  destination
    internet addresses and the protocol field from the internet header.  One
    possible  UDP/IP  interface  would return  the whole  internet  datagram
    including all of the internet header in response to a receive operation.
    Such an interface  would  also allow  the UDP to pass  a  full  internet
    datagram  complete  with header  to the IP to send.  The IP would verify
    certain fields for consistency and compute the internet header checksum.
    Protocol Application
    --------------------
    The major uses of this protocol is the Internet Name Server [3], and the
    Trivial File Transfer [4].
    Protocol Number
    ---------------
    This is protocol  17 (21 octal)  when used  in  the  Internet  Protocol.
    Other protocol numbers are listed in [5].
    References
    ----------
    [1]     Postel,   J.,   "Internet  Protocol,"  RFC 760,  USC/Information
            Sciences Institute, January 1980.
    [2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC 761,
            USC/Information Sciences Institute, January 1980.
    [3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
            Institute, IEN 116, August 1979.
    [4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
            Technology, IEN 133, January 1980.
    [5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
            Institute, RFC 762, January 1980.
     
     
     
     
    Postel                                                          [page 3]



    展开全文
  • <div><p>When using -C on pcap-file containing fragmented UDP packets, the UDP checksum is incorrect. <p>It is possible to reproduce the issue using the file "http://loki.stockton.edu/~olanm/csis...
  • TCP/UDP checksum support

    2020-12-09 12:11:44
    <div><p>I implement two things: ...* UDP checksum calculator In <code>src/udp.c</code> with adding Pseudo Header、Header、Data and Padding </p><p>该提问来源于开源项目:jserv/nstack</p></div>
  • Network | UDP checksum

    2014-03-18 23:27:00
    ICMP,IP,UDP,TCP报头部分都有checksum(检验和)字段。IP 首部里的校验和只校验首部;ICMP、IGMP、TCP和UDP首部中的校验和校验首部和数据。 UDP和TCP的校验和不仅要对整个IP协议负载(包括UDP/TCP协议头和UDP/TCP...

    1. 校验和

    ICMP,IP,UDP,TCP报头部分都有checksum(检验和)字段。IP 首部里的校验和只校验首部;ICMP、IGMP、TCP和UDP首部中的校验和校验首部和数据。

    UDP和TCP的校验和不仅要对整个IP协议负载(包括UDP/TCP协议头和UDP/TCP协议负载)进行计算,还要先对一个伪协议头进行计算:先要填充伪首部各个字段,然后再将UDP/TCP报头及之后的数据附加到伪首部的后面,再对伪首部使用校验和计算,所得到的值才是UDP/TCP报头部分的校验和。

    伪首部结构如下:

    0        7 8      15 16     23 24     31
    +--------+--------+--------+--------+
    |           source address               |
    +--------+--------+--------+--------+
    |        destination address            |
    +--------+--------+--------+--------+
    | zero    | proto  |   udp/tcp len    |
    +--------+--------+--------+--------+

     

    2. 校验和的计算方法

    以IP首部中的校验和为例。

    1)首先把校验和字段清零;

    2)然后对每 16 位(2 字节)进行二进制反码求和;

    反码求和时,最高位的进位要进到最低位,也就是循环进位。先取反后相加与先相加后取反,得到的结果是一样的!

    所以校验的代码如下:

     1 unsigned short checksum(unsigned short* head, int bytes) {
     2     unsigned long sum = 0;
     3     while (bytes >= 0) {
     4         sum += *head++;
     5         bytes -= sizeof(unsigned short);
     6     }
     7     if (bytes) {
     8         sum += *head;
     9     }
    10     while (sum >> 16) { // 高16位不为0,最多循环两次
    11         sum = (sum >> 16) + (sum & 0xffff); //高16位是进位,进位是加到最低位的。
    12     }
    13     return ~((unsigned short)sum);
    14 }

    【一个负二进制数的反码形式为在原数基础上按位取反,即对应正数的补。对两个反码表示形式的数字做加法,首先需要进行常规的二进制加法,但还需要在和的基础上加上进位。Internet协议IPv4,ICMP,UDP以及TCP都使用同样的16位反码检验和算法。虽然大多数计算机缺少“循环进位”硬件,但是这种额外的复杂性是可以接受的,因为“对于所有位(bit)位置上的错误都是同样敏感的”。 在UDP中,全0表示省略了可选的检验和特性。另外一种表示:FFFF,指示了0的检验和。(在IPv4中,TCP和ICMP都强制性地规定了检验和,而在IPv6中可以省略)。 注意负数的反码只需按位求数值的补就可以得到,符号不需要变动。】 

    3. 校验原理
    同样以IP首部中的校验和为例。接收方进行校验时,也是对每16位(2字节)进行二进制反码求和。接收方计算校验和时的首部与发送方计算校验和时的首部相比,多了一个发送方计算出来的校验和的反码。因此,如果首部在传输过程中没有发生差错,那么接收方计算的结果应该为全0。

    实例:

    IP头:

    1 45 00 00 31
    2 89 F5 00 00
    3 6E 06 00 00(校验字段)
    4 DE B7 45 5D -> 222.183.69.93
    5 C0 A8 00 DC -> 192.168.0.220

    计算:

    1 4500 + 0031 +89F5 + 0000 + 6e06+ 0000 + DEB7 + 455D + C0A8 + 00DC =3 22C4
    2 0003 + 22C4 = 22C7
    3 ~22C7 = DD38 ->即为应填充的校验和

    当接受到IP数据包时,要检查IP头是否正确,则对IP头进行检验,方法同上:

    计算:

    1 4500 + 0031 +89F5 + 0000 + 6E06+ DD38 + DEB7 + 455D + C0A8 + 00DC =3 FFFC
    2 0003 + FFFC = FFFF
    3 ~FFFF = 00000 ->正确

    说明:
    由于IP报文在网络中传输时TTL是在变化的(每经过一个路由器减一),因此在路由器中要对 IP 首部重新校验。这也解释了为什么IP首部里的校验和只校验首部而不校验数据,因为如果数据也校验,那将给路由器增加巨大的负担。因此对数据校验的任务交给上层协议(TCP或UDP)。

    转载于:https://www.cnblogs.com/linyx/p/3609043.html

    展开全文
  • <p>I have set <code>udp.dgram_cksum</code> and <code>ip.hdr_checksum</code> both to 0, and have set attribute <code>PKT_TX_IPV4 | PKT_TX_UDP_CKSUM | PKT_TX_IP_CKSUM;</code> for the corresponding ...
  • 目的:检测UDP段在传输中是否发现错误UDP segment format如下(报文段每行长度都是32bits即2字节)source port , dest portlength(UDP段的长度), checksum校验和application data那么校验和checksum是怎样检测传输错误...

    目的:检测UDP段在传输中是否发现错误

    UDP segment format如下(报文段每行长度都是32bits即2字节)

    1. source port , dest port
    2. length(UDP段的长度), checksum校验和
    3. application data

    那么校验和checksum是怎样检测传输错误的呢?

    主要思路如下,主要是从我校ppt和哈工大Mooc中总结的:

    计算机网络_中国大学MOOC(慕课)www.icourse163.org
    0315e856b317e24b322ddec179ecb1f9.png

    首先发送方要计算checksum

    • 将段的内容看作16bits的整数
    • 校验和计算:计算所有整数的和,进位加到和的后面,将得到的值按位取反,得到校验和
    • 发送方把checksum放入header的校验和字段里面

    接着,当接收方收到后,验证的思路是

    • 计算所收到的段的校验和
    • 把它和校验和字段进行对比
    • 不相等即发现了错误,相等并不代表一定没有错误

    相等只代表我们没有检测出错误,但其实可能有错误,比如有2个位发生翻转的情况就检测不出来。

    下面有一个例子:

    64963f1ce428de3a23a7ea39e60aa78c.png
    校验和计算的例子

    很直白了,注意点就只有两个

    • 16bits直接二进制加法,如果有进位就加到最后
    • checksum是和的取反,最后记得取反

    如果想了解更多可以参考下面这个博客

    校验和算法 - Noble_ - 博客园www.cnblogs.com
    c4321b0ded675caa5fcf5f024e870395.png

    然后下面是我的python实现:(用到matplotlib的一些窗体效果)

    95a753b6a52728d2c251f2fd2adbe6a1.png
    运行效果

    因为老师要求用python的matplotlib写......然后下面是代码:

    # author: zhujie 
    # time: 2020/4/2
    import matplotlib.pyplot as plt
    from matplotlib.widgets import TextBox, Button
    
    def btn_clicked(e):
        number1 = int(textbox_1.text, 2)
        number2 = int(textbox_2.text, 2)
        number3 = int(textbox_3.text, 2)
        sum = bin(number1 + number2)
        # 检查溢出
        if len(sum) > 18:
            sum = sum[3:19]
            sum = int(sum, 2)
            sum += 1
        else:
            sum = sum[2: 18]
            sum = int(sum, 2)
        print(bin(sum))
        sum = bin(sum + number3)
        # 检查溢出
        if len(sum) > 18:
            sum = sum[3:19]
            sum = int(sum, 2)
            sum += 1
        else:
            sum = sum[2: 18]
            sum = int(sum, 2)
        sum ^= 0xffff
        sum = bin(sum)
        print(sum)
        sum = sum[2:18]
        textbox_4 = TextBox(plt.axes([0.3,0.1,0.5,0.075]),"checksum:",initial=sum)
    
    # 初始化GUI
    axbox_1 = plt.axes([0.3, 0.9, 0.5, 0.075])
    axbox_2 = plt.axes([0.3, 0.7, 0.5, 0.075])
    axbox_3 = plt.axes([0.3, 0.5, 0.5, 0.075])
    axbtn = plt.axes([0.3, 0.3, 0.3, 0.1])
    textbox_1 = TextBox(axbox_1, 'input1:')
    textbox_2 = TextBox(axbox_2, "input2:")
    textbox_3 = TextBox(axbox_3, "input3:")
    button = Button(axbtn, "Calculate Checksum")
    # 绑定点击事件
    button.on_clicked(btn_clicked)
    plt.show()
    展开全文
  • <div><p>Seeing the recent <a href="https://github.com/p4lang/p4c/issues/2472">issue </a> filed against p4c, I decided to add layer-4 (TCP and UDP) checksum example or test to p4c. The <code>expect...
  • 如何计算UDPTCP校验和checksum

    千次阅读 2019-06-28 13:59:31
    目录 如何计算UDP/TCP检验和checksum 如何计算UDP/TCP检验和checksum 如何计算UDP/TCP检验和checksum 一、下面的图是一个UDP的检验和所需要用到的所有信息,包括三个部分: 1.UDP伪首部 2.UDP首部 3.UDP的数据...
  • TCP UDP checksum by SW.

    2020-12-04 11:43:22
    <p>Although HW does not support TX checksum offloads, I think users expect to send packets with normal checksum when they set to update checksum. <p>And I found that there is a bug in DPDK code. I ...
  • <p>When the checksum in a UDP packet is <code>0, it should be treated as if the checksum check was successful. Currently, verifier and pretty printer checks this more strictly. Note that this is not ...
  • TCPIP: UDP/TCP checksum

    2019-07-03 17:07:00
    UDP/TCP checksum 1Content Table Internet checksum 1’s complement sum UDP/TCP checksum 2Internet checksum (1) Adjacent octets to be checksummed are paired to form 16-bit integers, and th...
  • If flowlatency stats enabled in UDP packets, UDP checksum value is invalid. <p>The reason is If user enable flowlatency stat, 16 bytes of last payload will be replaced into flowlatency header. It'...
  • Is this maybe because smcroute DID change the source address which makes the UDP checksum invalid which was built assuming another source address in it's pseudo header?</li><li>Any ideas how to ...
  • IP TCP UDP checksum计算c代码,包含checdsum原理说明,以及实现c代码,用于验证网络平时收发包checksum问题
  • Fix omission of udp checksum

    2020-11-29 04:05:05
    <div><p>Allow the control flow to continue when the representation is parsed for ipv4 addresses, instead of returning with an error. Additionally adds a test to ensure the correct behaviour. ...
  • <p>When tcpdump reports a UDP frame with a bad checksum, the checksum it does report is not correct either. For example: <p>20:37:27.614831 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: ...
  • <div><p>Hi, <p>I am using a P4 switch for implementing nat between two network ... Is there any way to implement tcp or udp checksum in P4 switch?</p><p>该提问来源于开源项目:p4lang/p4c</p></div>
  • switch off UDP checksum in kernel

    千次阅读 2011-09-02 10:07:39
    Just for my memo In IPv4, the UDP checksum is not a forced definition, if you do not do checksum. it is still ok to talk each other. How ev
  • UDP wrong checksum": <pre><code> DDR version 1.13 20180428 ID:0x805 N In LPDDR3 786MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:...
  • <div><p>This creates infrastructure support for IPv4, UDP or TCP checksum offloading in ethernet. Currently no ethernet driver is converted to offload the checksum calculation.</p><p>该提问来源于开源...
  • <p>STM Nucleo Ethernet driver hardware checksum insertion corrupts fragmented UDP packets that are sent by the driver to ethernet. <p>This can be repeated by running greentea LWIP UDP echo test with ...
  • System.Net.Sockets.Tests.SendReceive.SendToRecvFromAsync_Single_Datagram_UDP_IPv4 [FAIL] 11:27:58 Assert.Equal() Failure 11:27:58 Expected: 0 11:27:58 Actual: 1161193313 11:27:58 Stack Trace: 11:27:58...
  • ip,udpchecksum算法

    千次阅读 热门讨论 2014-03-11 08:40:02
    http://irw.ncut.edu.tw/peterju/internet.html#udp udp checksum IPv4 ip共32個bit, 分成NetID 與 HostID。Network Mask即所謂的網路遮罩。網路遮罩的最主要用途在於子網路(Subnetwork)的切割,並使電腦...
  • s UDP and SCMP checksum functions did not. It's unclear why this didn't cause obvious problems with UDP before, but it completely broke SCMP checksum support in libscion. <p>Also: - Change chk...
  • 应用收包时,网卡会对udp头的checksum进行检查,当udp头的checksum不正确时,该包可能会被应用丢弃。因此在C语言的socket程序中可以加上以下内容禁止对checksum的检查从而正确收包: int getchecksum = 0; socklen...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 476
精华内容 190
关键字:

checksumudp