raw_socket communication using udp protocol - c

Am just beginner of this socket programming ...
i tried to make a UDP client_server program using SOCK_RAW .I can send message from the server part.But in client part am getting garbage values. And the receiving message packet size also different.Can U help me to do this client server program using SOCK_RAW.
I tried this client -server with eth0 & eht1,i tried to send 1 packet from eth0 to eth1 sending side is showing "OK" message.. but received data is garbage..
before i done normal client server program using UDP protocol.I got correct output from normal udp client server .When i tried with SOCK_ROW its showing error in sending part.

Make your life simpler and use SOCK_DGRAM - Kernel will take care of datagram headers, you only need to provide valid IP address and data. It is user's responsibility to append (before transmitting) and parse (upon reception) UDP headers using SOCK_RAW.

Most likely you are seeing IP and UDP headers and calling them "garbage". That is what SOCK_ROW does. You should parse and skip protocol headers if you want to get to your message content while using SOCK_ROW.

Related

UDP - Multithreaded server is unable to distinguish between an ack msg and a connection msg

I am trying to implement a multithreaded UDP server where each thread services one client.
So far, the clients are being registered correctly and the data is being received by the clients. In order to make it reliable, i tried sending a negative acknowledgement when the message was not received within a particular time interval.
This acknowledgement is being treated as a request from a new client in the server side recvfrom() function. How do i distinguish the two at the server side? Are there any functions related to send and receive that can do the same?
The code is in c and i have used pthreads to implement the threading function.I have used the basic sendto() and recvfrom() socket functions to implement the same.
Code outline:
At the server side:
recvfrom()
when received:
Add to client list
create thread:
send data in the thread function
exit thread
At the client side:
sendto() -> to initiate the request to the server
when time < timeout
recvfrom() -> receive the data from the server
when timeout occurs
sendto() -> send negative acknowledgement.
recvfrom() will fill out a socket address structure of the correct type with the address of the client.
You could maintain a data structure that maps client addresses (including the port number) to threads. You can then use this to pass subsequent messages from the client to the correct thread.

Problems with receiving udp multicast packets on client side

I have strange problem with multicast server/client application. I wrote simple server and client udp multicast application in C and I tested it using two laptops and one wireless router.Server is connected with the ethernet cable to the wrt54gl linksys router with 192.168.1.101 IP address. Client with IP 192.168.1.105 address is connected to the router via wireless interface. They can ping each other. Server is sending UDP packets using sendto function and client is receiving them using recvfrom function. When I run my server I can see sent udp packet in wireshark destined for multicast group with IP address 226.1.1.1 but on client side I don't receive those packets and also I can't see them in wireshark. I'm pretty sure that code is properly written. Do you have experience with multicast to advice me?
Thank you

Forwarding UDP packets in C using the socket API

I am writing a content filter in C using the socket API that will intercept DNS requests, and only return the response if the domain is allowed. The pseudocode to describe this is:
Redirect all DNS queries to the content filter program which is listening on UDP port X.
Content filter program extracts domain being queried and determines if it is allowed or not.
If it is allowed, then the content filter program forwards the original DNS request packet to the original destination DNS server while maintaining the original source and IP+port so that the DNS server can send the reply directly back to the client.
If the domain is not allowed, then no reply is sent.
I currently have the program listening on UDP port X but the problem is that I can't access the IP headers, and therefore can't simply forward the DNS request to the original server while maintaining the original headers.
I have tried using socket(AF_INET, SOCK_RAW, IPPROTO_UDP) but that doesn't bind on port X (understandably), and doesn't receive any traffic.
What is the best way to go about listening on UDP port X, while still being able to access the IP headers of incoming packets?
I think recvfrom on an UDP socket should give you the correct source address. You still probably need a raw socket for forwarding the message.
The functionality for SOCK_RAW based sockets varies depending on the platform you are on. Generally, when you want to get access to the full IP datagram information, then I would recommend using the Berkeley Packet Filter to tap the data-link layer frames addressed to UDP port of interest.

How To Send A File In Winsock (http Way)

I mean, if i have a winsock in window environmentand i set it to listen on port 80 and ip of server.then i have a file abc.txt or abc.xml .i have to send file from client to http server through http link. how can we send it .I don't know how to send text files.
Please..I need this...so badly.
Thanks in advance!
Setting up a server basically requires the following steps:
Open socket with socket()
Bind socket to an address (usually INADDR_ANY) and a specific port with bind()
Listen to the socket with listen()
Accept a connection with accept(). This returns a new socket number (the client socket)
Now you can receive data from the client socket with recv() and send data with send().
To send a file to the client, just read from the file for example line by line and then send it to the socket with send().
Of course you need to communicate the file name and size before you start sending. (Or use EOF character at the end of file).
For more information, see:
msdn: Getting Started with Winsock

Communicate to public IP from a local network (WinSock, C)

I'm new to this forum (at least at asking questions), so please be patient. I'm trying to write simple client-server applications to communicate using datagram (UDP) sockets, with C and Windows.
The scenario is very simple, I want to be able to send/receive data from a machine in some local network (behind a GATEWAY/NAT) to some host having public IP. I can send the data, but it seems impossible to receive any data back, because the remote server can't see the client's local IP.
I don't want the user to perform manual port forwarding on the GATEWAY, and I also don't want to use UPnP because of security issues (though it also should be enabled by the user).
I think it is possible because applications like Skype or Browsers can do it, but how ?
Are there some automatically forwarded ports or things like that ? I'm exhausted of searching the web ... PLEASE HELP !
For UDP connections, most home NAT gateways will automatically create a temporary reverse mapping for each outbound packet.
Consider a scenario where your client is running on the internal machine with IP address 192.168.4.5, sending a UDP packet from port 65000 to the external address 64.34.119.12:6789, via a gateway with external IP address 192.0.43.10. When the gateway sees your internal client send a UDP packet from 192.168.4.5:65000 to the external address, it will NAT it to an external address and port, like 192.0.43.10:5500. Your server will see a packet with a source address of 192.0.43.10:5500 and destination address 64.34.119.12:6789. The router also sets up a reverse mapping, so that if it sees a packet arrive on the external interface with a source of 64.34.119.12:6789 and a destination of 192.0.43.10:5500, it will redirect it back to 192.168.4.5:65000. This mapping typically times out after a short while.
This means that in simple cases, all you need to do is:
On the client, use the same port to send to the server and listen for responses;
On the server, respond to the client at the address and port that the client's packet was receieved from, using the same server port that recieved the packet;
Have the client send the initial packet in the conversation;
Don't leave the "connection" idle for more than a few minutes at a time.

Resources