Develop Reference

sniff the data on a selected port - C#

I have one application running on specific port. I dont have access to this application but i know what it does. Now this application is listening on one specific port and process the data coming on that port
Now i have been assigned the task on logging all the packets received on that port with all the data details. I have used the wireshark and can apply the filter to check the data coming on that specific port. So i assume here that i have been stuck in creating this kind of snipping program so i can get all the data packet details. I have search the stack overflow and come up with
Code project
Stack overflow
Now i have evalute the sample and can see that it gives me packets but it listens on all port of the system. Not on the specific port. Can someone help me to achieve my solution? Basically if i will listen to all port then there are lots of app/program running on server so it may get bottleneck. Thank you all.

In MJsniffer.MJsnifferForm class you have ParseData method - at first step it converts received bytes to IPHeader object, an then there a huge SWITCH-CASE on ProtocolType field. Inside that SWITCH there are TCPHeader or UDPHeader is created and added to TreeView on form - there you can filter packages by SourcePort/DestinationPort fields tcpHeader/udpHeader.
Also if you are already familiar with WireShark, then you can easly switch to Pcap.NET wrapper(they use same packet capturing library - WinPcap)

How to see what port was opened by router

If I do the following:
UdpClient c = new UdpClient();
c.Connect(new System.Net.IPEndPoint(IPAddress.Parse("69.65.85.125"), 9900));
c.Send(new byte[] { 1,2,3,4,5 }, 5);
then I will be sending a packet to my router then my router will send that packet to the ip "69.65.85.125".
If I where to capture that packet on the computer that has the ip "69.65.85.125" I will be able to see the port that was oppened by the router (client.RemoteEndpoint). How will it be possible to see that information without capturing the packet at the other enpoint? Is there a way to query the router?

If your router supports it you can query it via UPnP. Here is a wrapper library for UPnP I found for .NET, I have never used it so I cant give you any advice if it is good or not.
Look at the ComponetsTest program for example code in the zip for the library. You will need to reference the UPnP documentation to find out what calls you will need to make to the service.
From the message board of the library of someone asking a how to find port mappings.
The WANPPPConnection and WANIPConnection services have actions called
GetSpecificPortMappingEntry, simply call this iterating through the
indexes from 0 until an error is returned, each call will return
another UPnP port mapping, you can also get the static mappings with a
different service.

In order to get the public IP, the remote device should respond by sending a UDP packet back to you that contains the IP address and port it saw. This is one of the most fundamental concepts behind a STUN server, commonly used in UDP hole-punching algorithms.
There are several free STUN servers available that do exactly this. Send one of them a "binding" request, and you will get back a response with your public IP address and port.
stun.l.google.com:19302
stun1.l.google.com:19302
stun2.l.google.com:19302
stun3.l.google.com:19302
stun4.l.google.com:19302
stun01.sipphone.com
stun.ekiga.net
stun.fwdnet.net
stun.ideasip.com
stun.iptel.org
stun.rixtelecom.se
stun.schlund.de
stunserver.org
stun.softjoys.com
stun.voiparound.com
stun.voipbuster.com
stun.voipstunt.com
stun.voxgratia.org
stun.xten.com
If you are truly interested in doing proper UDP hole-punching, check out ICE (Interactive Connectivity Establishment). It's a brilliant algorithm that uses STUN and another protocol called TURN to guarantee a successful connection between peers. (Apple uses it for Facetime video calls, among others.)
If you're interested, the company I work for has developed a product called IceLink that uses ICE/STUN/TURN to establish direct data streams between peers. SDKs are available for .NET, Mac, iOS, Android, Java, Windows Phone, Windows 8, Unity, Xamarin, and more, and it even includes full support for WebRTC audio/video streams.

How do you get raw TCP packet in C#?

I want to received raw TCP packet and then send it back with same workload.
It should look something like this:
void OnPacketReceived(TcpPacket p)
{
byte [] body = p.GetBody();
}
NOTE : I need the TCP packet and not the Ethernet frame.

If you implement the socket as a raw socket, you have access to the whole packet (and in fact must handle everything about the packet yourself).
Use SocketType.Raw and ProtocolType.Raw when creating the socket.
Just be aware that you're going to have to handle the details of TCP if you implement your socket this way.
For reference, here is the MSDN documentation about the Socket class:
http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx

You can use the pcapDotNet library.
https://pcapdotnet.codeplex.com/

you need to use Packet sniffer where you can put filters of your choice and on the basis of that can respond also.
.Net wrapper around WinPcap can prove to be helpful for you.

UDP and port randomisation

I'm currently programming a UDP application which allows clients to login. After that, their endpoint gets stored in a list.
private void socket_Callback(IAsyncResult result_)
{
EndPoint remote = new IPEndPoint(IPAddress.Any, 0);
socket.EndReceiveFrom(result_, ref remote);
if (!listOfEndPoints.Contains(remote))
{
// registration process
// add it to list
listOfEndPoints.Add(remote)
}
else
{
// process packet
}
}
However, sometimes a client's NAT will assign every packet a different external end point. If the registration packet's source end point is 12.34.56.78:1000, that end point gets added to the list. If the same client then however sends another packet, the NAT will assign it a different port, so its source end point will be 12.34.56.78:1001.
This results in the server assuming the client is not registered and try to process the packet as a registration one. Needless to say this won't work.
A way of fixing this would be to send an ID (which could however be faked easily, if it's not super-cryptic) to the client. However, the client would have to add it to each packet it sends to the server.
So it wouldn't be very effective to do it like that.
Is there any other way of telling that the packet has come from the same client as the registration packet?

You should definitely not use the source IP address and port of a UDP packet to associate it with a logical connection. You should include the ID of the connection in each packet and update the IP and port you respond to if you receive a new IP and port for the same logical connection. If connection hi-jacking is an issue, you may need to implement some form of security, such as a secure checksum in the datagram.
TCP handles associating packets with connections for you. With UDP, you must associate datagrams with logical sessions yourself. I don't know why you think it "wouldn't be very effective to do it like that".
One of the tradeoffs of UDP is that if you need anything TCP provides, you have to code it yourself.
By the way, I've never seen ports shift in this way. Are you sure the client code isn't broken, perhaps opening a new socket for each datagram it sends.

How to safely stream data through a server socket to another socket?

I'm writing a server application for an iPhone application im designing. iPhone app is written in C# (MonoTouch) and the server is written in C# too (.NET 4.0)
I'm using asynchronous sockets for the network layer. The server allows two or more iPhones ("devices") to connect to each other and be able to send data bi-directionally.
Depending on the incoming message, the server either processes the message itself , or relays the data through to the other device(s) in the same group as the sending device. It can make this decision by decoding the header of the packet first, and deciding what type of packet it is.
This is done by framing the stream in a way that the first 8 bytes are two integers, the length of the header and the length of the payload (which can be much larger than the header).
The server reads (asynchronously) from the socket the first 8 bytes so it has the lengths of the two sections. It then reads again, up to the total length of the header section.
It then deserializes the header, and based on the information within, can see if the remaining data (payload) should be forwarded onto another device, or is something that the server itself needs to work with.
If it needs to be forwarded onto another device, then the next step is to read data coming into the socket in chunks of say, 1024 bytes, and write these directly using an async send via another socket that is connected to the recipient device.
This reduces the memory requirements of the server, as i'm not loading in the entire packet into a buffer, then re-sending it down the wire to the recipient.
However, because of the nature of async sockets, I am not guaranteed to receive the entire payload in one read, so have to keep reading until I receive all the bytes. In the case of relaying onto its final destination, this means that i'm calling BeginSend() for each chunk of bytes I receive from the sender, and forwarding that chunk onto the recipient, one chunk at a time.
The issue with this is that because I am using async sockets, this leaves the possibility of another thread doing a similar operation with the same recipient (and therefore same final destination socket), and so it is likely that the chunks coming from both threads will get mixed up and corrupt all the data going to that recipient.
For example: If the first thread sends a chunk, and is waiting for the next chunk from the sender (so it can relay it onwards), the second thread could send one of its chunks of data, and corrupt the first thread's (and the second thread's for that matter) data.
As I write this, i'm just wondering is it as simple as just locking the socket object?! Would this be the correct option, or could this cause other issues (e.g.: issues with receiving data through the locked socket that's being sent BACK from the remote device?)
Thanks in advance!

I was facing a similar scenario a while back, I don't have the complete solution anymore, but here's pretty much what I did :
I didn't use sync sockets, decided to explore the async sockets in C# - fun ride
I don't allow multiple threads to share a single resource unless I really have to
My "packets" were containing information about size, index and total packet count for a message
My packet's 1st byte was unique to signify that it's a start of a message, I used 0xAA
My packets's last 2 bytes were a result of a CRC-CCITT checksum (ushort)
The objects that did the receiving bit contained a buffer with all received bytes. From that buffer I was extracting "complete" messages once the size was ok, and the checksum matched
The only "locking" I needed to do was in the temp buffer so I could safely analyze it's contents between write/read operations
Hope that helps a bit

Not sure where the problem is. Since you mentioned servers, I assume TCP, yes?
A phone needs to communicate some of your PDU to another phone. It connects as a client to the server on the other phone. A socket-pair is established. It sends the data off to the server socket. The socket-pair is unique - no other streams that might be happening between the two phones should interrupt this, (will slow it up, of course).
I don't see how async/sync sockets, assuming implemented correctly, should affect this, either should work OK.
Is there something I cannot see here?
BTW, Maciek's plan to bolster up the protocol by adding an 'AA' start byte is an excellent idea - protocols depending on sending just a length as the first element always seem to screw up eventually and result in a node trying to dequeue more bytes that there are atoms in the universe.
Rgds,
Martin
OK, now I understand the problem, (I completely misunderstood the topology of the OP network - I thought each phone was running a TCP server as well as client/s, but there is just one server on PC/whatever a-la-chatrooms). I don't see why you could not lock the socket class with a mutex, so serializing the messages. You could queue the messages to the socket, but this has the memory implications that you are trying to avoid.
You could dedicate a connection to supplying only instructions to the phone, eg 'open another socket connection to me and return this GUID - a message will then be streamed on the socket'. This uses up a socket-pair just for control and halves the capacity of your server :(
Are you stuck with the protocol you have described, or can you break your messages up into chunks with some ID in each chunk? You could then multiplex the messages onto one socket pair.
Another alternative, that again would require chunking the messages, is introduce a 'control message', (maybee a chunk with 55 at start instead of AA), that contains a message ID, (GUID?), that the phone uses to establish a second socket connection to the server, passes up the ID and is then sent the second message on the new socket connection.
Another, (getting bored yet?), way of persuading the phone to recognise that a new message might be waiting would be to close the server socket that the phone is receiving a message over. The phone could then connect up again, tell the server that it only got xxxx bytes of message ID yyyy. The server could then reply with an instruction to open another socket for new message zzzz and then resume sending message yyyy. This might require some buffering on the server to ensure no data gets lost during the 'break'. You might want to implement this kind of 'restart streaming after break' functionality anyway since phones tend to go under bridges/tunnels just as the last KB of a 360MB video file is being streamed :( I know that TCP should take care of dropped packets, but if the phone wireless layer decides to close the socket for whatever reason...
None of these solutions is particularly satisfying. Interested to see whay other ideas crop up..
Rgds,
Martin

Thanks for the help everyone, i've realised the simpliest approach is to use synchronous send commands on the client, or at least a send command that must complete before the next item is sent. Im handling this with my own send queue on the client, rather than various parts of the app just calling send() when they need to send something.