sr*() 方法不剖析 scapy 中的应答数据包 [英] sr*() method not dissecting the answered packets in scapy
问题描述
我扩展了 Scapy 以支持用于我的测试的新协议.我看到 sniff() 命令能够在我使用 bind_layers() 将 2 层缝合在一起后自动剖析数据包.我期待这应该足以进行解剖.每当我使用 sniff() 时，我都会看到解剖正在起作用.
但是当我使用 sr() 或 sr1() 函数时，我看到应答的数据包没有被解析，Scapy 将其报告为 Raw.我还看到它有一些额外的数据包作为回答的一部分.
有关正在添加的协议的更多详细信息:
我添加的协议是基于 tcp 并在端口 4189 上运行的 PCEP 协议.我创建了一个 python 套接字并使用 StreamSocket() 将其转换为 scapy 超级套接字.我们在 scapy 的超级套接字上发送这些 PCEP 消息.
数据包将像这样分层:IP()/TCP()/PCEP()
connection, pcc_address = pce.accept() <---- 这接受来自客户端的 TCP 连接pcc_client=StreamSocket(connection) <---- 这里我把python socket转换成scapy super socket.示例数据包:
如果我想发送 keepalive，这就是我制作消息的方式.pcc_client 对象是发送数据包.
<预><代码>>>>>>>pkt.show2()###[PCEP 通用头]###版本= 1L标志= 0L类型= PCEPKeepaliveMsg长度= 4>>>pcc_client.send(pkt)>>>pcc_client<scapy.supersocket.StreamSocket 对象在 0x115b890>问题:
与我创建一条名为 PCInitiate 的消息并使用
发送的方式相同>>>pcc_client.sr1(pccinit)a[0][0]下面是我发送的数据包，接收到的数据包存储为Raw.我期待它被解剖.出于某种原因，我认为它没有被解剖.我还注意到一堆字符串 ' \x02\x00\x04' 附加到来自 UUT 的响应.我可以识别这些字符串，它们是 Keepalive 消息.这些不是对我发送的数据包的响应，但它以某种方式显示在此输出中.如何使 sr() 函数剖析来自 UUT 的响应.我看到了 sndrcv() 中使用的 hashret() 和 answers() 方法.那些方法有什么用.有人可以帮我查询吗?
您必须告诉 StreamSocket 它将接收的数据包类型(Raw 是默认设置).您可以通过使用 basecls= 可选参数来做到这一点:
连接，pcc_address = pce.accept()pcc_client = StreamSocket(连接，basecls=PCEPCommonHeader)然后您需要实现hashret() 和answers.他们来自 Packet 的文档字符串很好地解释了这一点:
hashret()是一种哈希函数，它返回一个字符串，该字符串对于请求及其答案具有相同的值".answers()是如果 self 是其他人的答案，则为真".
hashret() 不是强制性的，但如果正确实施它会提高性能.
I extended Scapy to support a new protocol for my testing. I see that the sniff() command is able to dissect the packets automatically after I stitched 2 layers together using bind_layers(). I was expecting that should be good enough for dissections. Whenever I use sniff() I see dissections are working.
But when I use the sr() or sr1() functions I see that the answered packet is not dissected and Scapy reports it as Raw. I also see that it has some extra packets as part of answered.
More details about the protocol being added:
The protocol that I added is a PCEP protocol which is tcp based and runs on port 4189. I create a python socket and convert it into scapy supersocket using StreamSocket(). We send these PCEP messages on top of the scapy's supersocket.
The Packet will be layered like this: IP()/TCP()/PCEP()
connection, pcc_address = pce.accept() <---- This accepts a TCP connection from the client
pcc_client=StreamSocket(connection) <---- Here I convert the python socket into scapy super socket.
Example packet :
If I want to send a keepalive this is how I craft the message. pcc_client object is to send the packet.
>>>>>> pkt.show2()
###[ PCEP common header ]###
Version= 1L
Flags= 0L
Type= PCEPKeepaliveMsg
Length= 4
>>> pcc_client.send(pkt)
>>> pcc_client
<scapy.supersocket.StreamSocket object at 0x115b890>
Issue:
The same way I create a message called PCInitiate and I am sending using
>>>pcc_client.sr1(pccinit)
Below a[0][0] is the packet that I sent and the received packet is stored as Raw. I was expecting it to be dissected. For some reason I see its not getting dissected. I also notice a bunch of strings ' \x02\x00\x04' appended to the response from UUT. I can recognize these strings which are Keepalive messages. These are not responses to the packet I sent but somehow it shows up in this output. How do I make sr() function dissect the response from the UUT. I see hashret() and answers() methods used in sndrcv(). What is the use of those methods. Can someone help me with my query?
>>> a[0][0]
<PCEPCommonHeader Type=PCInitiate |<PCInitiate srp_object=<SRP_Object srpIdNumber=0x10 path_setup_type=<path_setup_type_tlv |> |> lsp_object=<LSP_Object plspid=0x0 symbolic_path_name= <symbolic_path_name_tlv tlvValue='SERVICE-1418979625354-9F1166-10.126.147.23-10.126.147.1' |> |> end_points_object=<End_Points_Object SourceIPv4Address=10.0.0.1 DestinationIPv4Address=10.0.0.6 |> ero_object=<ERO_Object sr_eros=[<SR_ERO_SubObject Fflag=F Mflag=M SID=2260992 |>, <SR_ERO_SubObject Fflag=F Mflag=M SID=2674688 |>, <SR_ERO_SubObject Fflag=F Mflag=M SID=3096576 |>] |> |>>
>>> a[0][1]
<Raw load=' \n\x00x!\x10\x00\x14\x00\x00\x00\x00\x00\x00\x00\x10\x00\x1b\x00\x04\x00\x00\x00\x01 \x10\x00DT\x00`\x91\x00\x11\x007SERVICE-1418979625354-9F1166-10.126.147.23-10.126.147.1\x00\x07\x10\x00\x1c\x05\x08\x10\t\x00"\x80\x00\x05\x08\x10\t\x00(\xd0\x00\x05\x08\x10\t\x00/@\x00 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04 \x02\x00\x04' |>
You must tell StreamSocket the type of packets it will receive (Raw is the default). You can do that by using basecls= optional argument:
connection, pcc_address = pce.accept()
pcc_client = StreamSocket(connection, basecls=PCEPCommonHeader)
You will then need to implement hashret() and answers. Their docstrings from Packet explains it well:
hashret()is a kind of hash function that "returns a string that has the same value for a request and its answer".answers()is "true if self is an answer to other".
hashret() is not mandatory, but if properly implemented it will improve the performances.
这篇关于sr*() 方法不剖析 scapy 中的应答数据包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
