I want to send SYN packet to a remote host, now the problem is that if I use any of the classes of .NET framework then I cannot to do this; e.g. TCP Client takes Host ip and port number and establishes connection, same is the case with ClientSocket class in java.
I want to control the connection establishment my self; I mean I want to send the connection request (SYN packet) then wait for the connection reply and then send the packet. I know that it might not be easy without external libraries, so if any one can guide me how to do it in either C# or Java. .
Rather than commenting to both answers so far ... raw sockets have been restricted in Windows since XP (countermeasure to malware attacks). Read the following:
http://msdn.microsoft.com/en-us/library/ms740548(v=vs.85).aspx
Once that's done you can certainly build a raw socket following their rules based on Mat's answer for Java or Ritch's for C#.
It will be heavily restricted access, and very system dependent either way. I'm unaware of a method to complete the 3 way handshake and transmit data across TCP/UDP (though I'd be interested in hearing one).
I thought I should make one quick amendment to this answer. If you don't use winsock and instead use a different TCP stack, you can probably get what you want (but this is still not directly availalbe within the OS). Look at this as an example offering: http://www.komodia.com/tcpip-library-v5-1/ or this previous SO thread What is a popular, multi-platform, free and open source socket library
What you're looking for is called raw sockets. I don't know about C#, but there are libraries in Java that let you do that, e.g. RockSaw. You cannot do it using pure Java as far as I know.
Be warned that on some operating systems (Linux at least), you need administrator privileges to be able to open raw sockets. And there are a bunch of restrictions on Windows. (See that page I linked.)
Use the Socket class with a SocketType of raw, and the correct protocol type. I think you want TCP.
var sock = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Tcp);
Related
I have a working system that receives data via UDP packets sent to a fixed IP:Port and I want to use a program (some kind of proxy?) to send a copy of those packets to a new IP:Port (or a list of IP:Ports, but all inside the same LAN as the program).
Not as easy as it seems, because I need the copied packets to have the same Source IP address as the original ones.
In my research, I have found PCap.Net (WinPCap .NET wrapper) to be useful, because it can build a Packet from scratch and it supports modifying all the address fields. I have managed to capture the packets and build them. But somewhat they are not arriving at the desired destination (!?). Should I use a different PacketCommunicator to receive and send them?
Anyway, the question is not fully related to PCap.Net but to know alternative ways to achieve my desired goal. Via a free application? commercial application? Open source sample? Any other library to use?
My systems are Windows based (no Linux available here). And I have C# (.NET) experience (I can not use a C++ library, if NET bindings are not available).
Many thanks for your help
I know it's an old question, but this is the answer:
http://code.google.com/p/samplicator/
Listens for UDP and forwards it to one or more other IP addresses, optionally spoofing (the original) source IP address.
Used for forwarding netflow/sflow/syslog etc. packets.
you should think about network first. it may not be possible if traffic needs to go through router.
the original packet came through:
source->router->your server
if you are trying to sent it back out like so:
your server->router->another computer
then the router may not even accept this traffic, since it can not originate from your computer, according to routers configuration. just think about it - i could send traffic as anybody, if that was allowed.
however, in LAN that's very doable (unless you have some sort of MAC spoofing protection on your switches)
What you are trying to do is called "UDP Forwarding". You receive a UDP packet and then forward it to another host
Here is an application that does that (seems to be free)
in addition to keeping the source ip address and changing the destination ip address
you MUST swap the source and destination mac addresses.
if you send a raw packet out to your router/switch/modem, but the mac address is not addresses to it.
it will be dropped.
basicly, you have to revise every network layer your dealing with, and handle addressing approperately.
Sorry for my spelling
If you try to spoof the destination address to do things like netflow relaying you often will get blocked by anti-spoofing routers inbetween. I encountered this with AWS for example.
The solution is to take the RAW udp packet and then just send that along to your new destination inside another udp packet. When it reaches the destination you have to "unwrap" the packet and then send it to itself on the loopback interface (essentially "unwrapping").
You can do this with python code with the sockets module.
Recently I have started working on a program that will monitor the packets of one of my open-source programs in an attempt to learn more about programming and networking. Also, I want to add additional functionality to the program without editing the source, like an external control panel.
(I used WPE Pro to filter packets in case you'r wondering, WireShark is too much hassle for such a simple task.) One thing bothers me though, the Socket ID.
I know what it is, and I've asked a question about it before, but I cant figure out how to use it/assign one/intercept one.
Without the right socket ID, my program wont be able to do anything, so my question is if it's possible to find out what Socket ID a socket is using, once you capture the packet?
If not, are there any other ways of doing? -or possible other languages like Visual Basic?
Thank you for your time.
If, by socket ID, you mean the return value of a successful call to socket() function, I don't think there's a way.
The closest thing you can obtain is the process ID because, as you may already know, each IP packet has a destination that's described by the tuple (IP address, port) and inside a system only one socket can be successfully bound to that tuple. Utilities like TCPView are able to map an IP tuple to a process, so a way does exist if that information is enough for you.
If that's not the case, I'm not aware of any method to retrieve the socket ID you need if the target application is not collaborative.
This library: SharpPcap promises doing capturing, injecting, analyzing and building packets using any .NET language such as C# and VB.NET (more info).
It is the library used by Wireshark and it is for sure that it can capture and analyze.
socket() returns a file descriptor if this is what you are referring to as a socket ID then the ways to get this without the process's collaboration on windows are limited. FWIW on linux open FDs are enumerated in the proc filesystem.
That being said, the only thing you would be able to do with the fd is send additional information from the socket. You could also read from the fd, but any data read in this way would not be sent to the application that owns the socket. Without some coordination, that would probably not be what you desire as you would just get bits and pieces of data.
If just want to be able to listen in on the traffic in your program, then something like packet filtering should be sufficient so I assume you actually want to be able to be like a man in the middle for it.
If this is the case, then the best thing to do would actually be to set your application up as a proxy for your other service.
By this I mean, write a program that opens a listening port and accepts connections when a connection is initiated, it should immediately open its own connection to a pre-configured IP:port combination and begin forwarding traffic. Once this is written it's a simple matter to inspect the traffic before forwarding and possibly modify it.
If your program is a server, run it on a non-standard port, configure this application to open the server's normal port and then forward connections to the non-standard port you set up on localhost.
If your program is a client, simply point the interceptor application at the server and choose a random listen port on your box. Then configure the client to connect to this listen port as though it were the server.
This should work for pretty much anything. The only caveat is if the traffic is encrypted you will (obviously) not be able to inspect/modify it. This is effectively the same as placing your application behind a NAT.
I need to develop a client server system where I can have multiple clients communicating with one server at the same time. I want to communicate xml serialized objects and also need to send and receive other commands to invoke methods. Now, I am just starting with socket programming in C# and .Net and found that the asynchronous I/O is the way to go so that the methods dont block the execution of code. Also there are many examples of how to
make a simple client server system. So I have a basic understanding of how that works.
Anyway, what still is not clear to me is how I can set up a server which can manage connections to multiple clients?
Can I just create a new socket per connection and then store those in some kind of list?
Do I need some kind of multiplexing to achieve this?
Do I have to listen at multiple ports?
What`s the best way here?
And the other thing is if I need to develop my own protocol to differentiate between what I am actually sending over the network --> xml serialized object or a command which might be just a string encoded in ascII or something. Or would I develop my own protocol just to send these commands?
Any kind of help is apreciated! If someone knows a good book which covers this sort of stuff, let me know. Cheers
I forgot to mention that some of my clients which are supposed to communicate with my server will be pda and I therefore use the compact framework... So this might bring in some restrictions...
You may find several of my TCP/IP .NET FAQ entries helpful, particularly using a socket as a server socket, which explains how listening servers create new client connections, and XML over TCP/IP, which discusses the decisions you have to make for an XML-over-TCP/IP protocol.
I would abandon your plan to use Sockets and switch to WCF Windows Communication Foundation. It's far more elegant and is designed to do all the things you wanted, in a considerably easier and simpler way than .NET sockets.
If you want a guide of how to use it, there are a set of amazing Microsoft webcasts by Michele Leroux Bustamante that will have you up and running in no time.
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here
Lets say I have my C# app installed on 2 laptops connected to a WiFi Wireless Local Area Network.
How can these apps send messages to each other? What method or library can I use? I heard of using sockets but I have no idea how to work with these.
You could use WCF to build a communication pipe between the 2 applications. WCF encapsulates the sockets into a more manageable interface. You can start here.
Basically, you'll want to do it the same way you would in any other language. You'll open a network connection of one flavor or another (raw TCP or UDP, or a higher level protocol like HTTP) with one side acting as a server and the other acting as a client. Then each side can write data through or read data sent by the other side. It's can get pretty complicated from there. If you Google "C# Sockets" or "C# HTTP", etc, you'll find quite a few tutorials on the subject.
This is a very good article on sending C# objects (which could include whatever messages that you want to send) over a Socket connection using the Binary Formatter. Although it is not the most efficient, it is quite easy to grasp and get working.