Click here to Skip to main content
15,617,328 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Dim I As Short
     Dim thisPacket As String
     Dim SourceIP As String
     Dim DestIp As String
     Dim item As New ListViewItem

     thisPacket = ""
     For I = 0 To e.pPacket.DataSize - 4
         thisPacket = thisPacket & Chr(e.pPacket.Data(I))
     If e.pPacket.Data(14) = 69 And e.pPacket.Data(23) = 6 Then
         SourceIP = e.pPacket.Data(26) & "." & _
                    e.pPacket.Data(27) & "." & + _
                    e.pPacket.Data(28) & "." & + _
         DestIp = e.pPacket.Data(30) & "." & _
                  e.pPacket.Data(31) & "." & + _
                  e.pPacket.Data(32) & "." & + _
         item.SubItems(0).Text = SourceIP


Updated 27-Apr-10 5:21am

Not really :-)

What do you want to do? a reverse DNS on the source IP or destination IP?
In that case you query your DNS server with the reversed dotted address, followed by ''.[^]
Share this answer
You'll find your code sample here[^]

Let me give some advice from an old hand:

When you start a major undertaking like this, without a clue, you should have at least a rough design of your system. Once you have that rough design, try identifying what parts look difficult to you (in this case, the hard parts will probably be: getting the packets off the network, filtering those packets, and really analysing the protocol (how many protocols do you know, do you know them in detail? can you get copy of the RFC's?)
Once you know the hard parts, you should at least try prototyping them in the technology of your choice. (Forget about the easy parts, you know that you can do them anyway).
This small prototype is called a proof of concept. It will give you confidence that the job can be done, and that your architecture is sound.
If you find that you cannot do the hard parts, you should revisit your design, maybe change the architecture, or choose other technologies that will allow you to do the hard parts.
Once you've got that sorted, you start implementing for real; You do your user interface, add exception handling and recovery to your prototyped parts, and implement all the use cases. That is the biggest part of the job. The difference is that you only do this big part when you're certain that you can finish it. The way you're getting about this, you'll put a lot of effort in making a user interface, and when that's all polished and shiny, you'll discover that it does not work, because you have no data. You'll be pissed off at computing, and you won't have learned anything.

Now I'll spare you some of the effort: VB.Net is not the appropriate language for writing a protocol analyser. Sure you can do you user interface in VB.Net, or in C#, but to do packet capturing, you'll have to dive down to C or C++, and parts of that development will probably be at the device driver level. Writing code at the device driver level is something that even the best C/C++ experts would not undertake lightly. Not because they don't know C++ or assembler, but because this requires intimate knowledge of the internal workings of the Operating System and the Input/Output subsystem. Your debugger will be a command line debugger which knows nothing about variables, and you'll do your virtual address translation arithmetic on a pocket calculator, all in hex. It's crap job if you don't eat, breathe, sleep and drink computers. (I know I used to be an operating system designer).

Trust me, pick something simpler, you won't be deceived...
Share this answer
i don't know. can you give a code sample. how would you make this work?
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900