Home › Forums › Discussions › Support › Packet Length
- This topic has 9 replies, 2 voices, and was last updated 17 years, 5 months ago by Vadim Smirnov.
-
AuthorPosts
-
June 8, 2007 at 8:16 am #5104
Hi,
Is the PacketBuffer.m_Length property supposed to hold the length of the entire packet or does it contain the total length of the headers (ETH,IP,TCP)?
I am filtering for only ETH_P_IP packets and the m_Length is always 54 which appears to be the header sizes (14,20,20). I am not able to get the payload data but I can get the IP and TCP header data successfully. What is the correct way to get the length of the entire packet (ETH, IP, TCP,PAYLOAD,CHECKSUM) using the VB PassThru example?
Thanks,
KDUB
June 8, 2007 at 10:05 am #6261@kdub wrote:
Hi,
Is the PacketBuffer.m_Length property supposed to hold the length of the entire packet or does it contain the total length of the headers (ETH,IP,TCP)?Yes, this is entire packet length (headers and payload).
@kdub wrote:
I am filtering for only ETH_P_IP packets and the m_Length is always 54 which appears to be the header sizes (14,20,20). I am not able to get the payload data but I can get the IP and TCP header data successfully.
Believe or not, not all packets on the network are 54 bytes length and not all packets are TCP. In order to check if packet is TCP you have to check protocol field on the IP header which specifies next protocol.
@kdub wrote:
What is the correct way to get the length of the entire packet (ETH, IP, TCP,PAYLOAD,CHECKSUM) using the VB PassThru example?
Read Ethernet header, check if next protocol is IP. Read IP header, check if next protocol is TCP. If it is then read TCP header and follow up data if there is any.
June 11, 2007 at 5:40 am #6262@SerpentFly wrote:
@kdub wrote:
Read Ethernet header, check if next protocol is IP. Read IP header, check if next protocol is TCP. If it is then read TCP header and follow up data if there is any.
I am checking for TCP packets and trying to read the data but I am still unsuccessful. How can I get the original Hex dump of the entire packet using the NDISAPI.dll?
June 11, 2007 at 6:31 pm #6263
'Dump packet size
sOut = sOut & vbTab & "Packet size = " & PacketBuffer.m_Length & vbCrLf
CopyMemory EthHeader, PacketBuffer.m_IBuffer(0), Len(EthHeader)
The code above is taken from VB passthru sample. Here PacketBuffer.m_IBuffer array contains the entire packet, you can dump it if necessary.
June 13, 2007 at 5:41 am #6264Hi,
I got the packet data finally!! Thank you for your help.
I am now successfully intercepting the packets between two applications that communicate using TCP. Using my intercepting application, can I send a tcp request to one of the two applications by filling the Request.EthPacket.Buffer with a new packet that I create and then send it using SendPacketToMstcp or SendPacketToAdapter? Would either application be able to tell that the packet didn’t originate from the application it is connected to?
KDUB
June 13, 2007 at 6:45 am #6265Using my intercepting application, can I send a tcp request to one of the two applications by filling the Request.EthPacket.Buffer with a new packet that I create and then send it using SendPacketToMstcp or SendPacketToAdapter?
Yes, you can. However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.
Would either application be able to tell that the packet didn’t originate from the application it is connected to?
If packet is injected properly then it won’t.
June 13, 2007 at 6:14 pm #6266@SerpentFly wrote:
However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.
Can you direct me to any websites that document the shifting of the SEQ and ACK fields. Also is shifting a set incremental value or is it based on the content of the packet?
Thanks,
KDUB
June 14, 2007 at 7:29 am #6267Can you direct me to any websites that document the shifting of the SEQ and ACK fields. Also is shifting a set incremental value or is it based on the content of the packet?
I don’t think you will be able to find this sort of information anywhere. The only thing I can suggest is reading some good description of TCP protocol (by R. Stevens http://www.kohala.com/start/ an example).
June 14, 2007 at 11:31 pm #6268@kdub wrote:
@SerpentFly wrote:
However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.
Before I try to inject a packet into the TCP stream I thought I would check with you to see if there is another way to do what I need at the winsock level. If application 1 and application 2 are communicating via TCP using windows sockets on a set port, is there a way from my intercepting application to send a message to application 1 using Winsock so that is appears it came from application 2? I can’t figure out how to send messages using winsock using a port that is already open.
(e.g. App1 is connected to App2 on local port 9999, I want App3 to be able to send messages to App1 using local local port 9999 as well).KDUB
June 16, 2007 at 10:10 am #6269You could use LSP for this. Probably this is the most suitable solution in this case.
-
AuthorPosts
- You must be logged in to reply to this topic.