i am using raw sockets to create my own socket. i need to set the tcp_checksum.
i have tried a lot of references but all are not working (i am using wireshark for testing).
could you help me please.
by the way, i read somewhere that if you set tcp_checksum=0. then the hardware will calculate the checksum automatically for you. is this true? i tried it, but in wireshark the tcp_checksum gives a value of 0X000 and says tcp offload. i also read about tcp offloading, and didn't understand, is it only that wireshark cannot check an offloaded tcp checksum, but there is a correct one??
EDIT: i realized that if you set tcpChecksum to 0, then the network card will set it and not the operating system. i was testing using wireshark and a virtual machine, so this explains why the checksum is 0x000 (since the packet is not even passing to the network card.)
but i am still curious about calculating the tcp_checksum manually... any help or links?
This article tries to explain how it's done.
Another place worth taking a look at is for Linux kernel sources, start from the file net/ipv4/tcp__ipv4.c
Related
What purpose is UDP for..if it delivers packets without any order (and given the fact that packets may get lost on the way or sent to other network).
UDP as many very usefull use cases.
Just a few off the top of my head:
1/ Your payloads are small (will hold in a single "packet") and you want to go fast. That's why DNS uses UDP when the data size does exceeds 512 bytes (99% of the cases?):
https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
And you do hundreds of DNS requests every day. How many TCP 3-way handshakes and connection tear-down saved by this? How may petabytes or network load saved on "the internet"? I'd say that's quite useful!
2/ You do not know who you are talking too, or even if someone is listening or wishing to reply. In other words, you cannot or do not want for sure to establish an actual connection, like TCP would do. There may not be a TCP service listening for you. For example, the SSDP protocol from UPnP uses UDP to discover devices/services:
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
With UDP tough, you can send your data "in the wild" even if nobody is listening to you. Which leads me to point 3...
3/ You want to talk to multiple hosts, or even "everyone". That's multicasting and broadcasting, and it's very easy to do in UDP. The SSDP mentioned above is an example of such case. On the other hand, if you want to do multicast or broadcast on TCP, that becomes very tricky from the start. You'll have to subscribe to multicast group and blablabla. A multicast daemon may help (ex: https://github.com/troglobit/smcroute), but it's really way more difficult in TCP than with UDP.
4/ Your data is realtime, if the target is missing it there's no point for it to ask for a "please send it again, I did not get it and/or not in the correct order". That's too late, sorry. The receiver better forget it, go on and try to catch-up. A typical use case here can be live audio/video (telephony conversations, real time video streaming). There's no point for the receiver to try to get old, expired data again and again in case of TCP missed segment(s). You can only accumulate network data debt doing this. Better forget it and move on to the new, real-time data that keep coming in. You cannot "pause" real-time incoming data. If you want actual real-time, not pseudo real-time like you get in your web browser.
And I'm sure other posters will find many use-cases for UDP.
So UDP is very, VERY useful. You use it daily without noticing it. The networking world would be a pitiful place without it. You would really miss it. The "TCP/IP" should really be renamed "TCP-UDP/IP".
This was my advocacy for the unfairly despised but Oh-so-useful UDP. :-)
Typically, use UDP in applications where speed is more critical than reliability. For example, it may be better to use UDP in an application sending data from a fast acquisition where it is acceptable to lose some data points. You can also use UDP to broadcast/multicast to any/many machine(s) listening to the server.
Applications may want finer control over the performance characteristics or the reliability of their communications. For this, the operating system exposes IP’s “best-effort datagrams” to the application for it to do whatever it wants with them.
To do this, the OS provides UDP — the “user” datagram protocol. It’s just like IP, in that the service is best-effort datagrams, but instead of delivering those datagrams “to a computer,” there’s an added layer of addressing that says which application is interested in them (and like TCP, UDP does this with a port number).
Applications can run whatever they want on top of UDP — anything that runs on best-effort datagrams. There are lots of protocols you can run on top of that abstraction.
In general:
TCP is for high-reliability data transmissions
UDP is for low-overhead transmissions
Wireshark doesn't seem to be able to change the content of filtered packets in real time.
Does anyone know a symilar software which can change packet content that is filtered.
Finding something like this will really be a life saver
Thanks.
At least on Unices and -like where raw sockets are used, this is not possible, since the packet is copied to userspace and you only work on that copy. Furthermore, sending a packet back through the raw socket may be considered an "outgoing" packet so that it is, in fact, not reinjected to the input path where it should be. Raw sockets were — according to the Linux manpage — designed to implement new protocols, IOW, raw sockets are an "endpoint", not a "passthrough station".
For packet modification in the input path (passthrough-like), each OS has its own set of interfaces. In Linux (you were sort of unspecific as to which you target), that would be the nfqueue mechanism, usable through libnetfilter_queue. And of course, that is how wireshark, if it wanted to (I don't see it doing packet alteration last time I checked), would go about doing this.
Please give Burp Suite a try. It includes a repeater that let's you modify HTTP requests.
No wireshark won't let you change the contents of the packets and place them back on the line. However there are ways to change packets as they pass through the machine. Typically the host is setup with two nics bridged together. One nic is connected to one network and the other nic to the other network. Then as packets pass through this point the host can see them. Now you can use iptables/netfilter and write a module that changes data in the packet. For example you can write something that can remap source ip addresses. It's been a while since I've used netfilter/iptables, so I can't provide anymore details, but I have used it in a previous job to do some neat things with packets while they were inflight. It does mean you need a host machine sitting at network junction points though.
The documentation suggests that node.get("nextSibling") and node.get("previousSibling") are what you need.
Yes, it can.
You need to pass this option to the configure script before you build it:
--enable-packet-editor
I try to send data using UDP protocol. Is it possible to understand when UDP dont send data?
Thanks a lot.
I try to a servis which run into client. And they send their IP an port number in one second. Server listen them and if they dont send this message it understand that client is not connected. I do this but I cant understand when they dont send? Do you have any suggestion
You can check the result of writeDatagram
Sends the datagram at data of size size to the host address address at port port. Returns the number of bytes sent on success; otherwise returns -1.
Then just check the return number to make sure the number of bytes sent was what you expected
Of course it's possible, but it might be hard.
I would recommend:
Verify that you don't get errors from your calls to send data (perhaps you're specifying a bad address, or the socket is in a bad state or something).
Try sending more seldom, perhaps your packets are getting dropped by your local network stack.
Make sure you really listen properly at the receiving end, perhaps the packets make it but you fail to read them properly.
Consider firewall/NAT issues, as usual with UDP. Protocol-wise, never include connection information as application data in packets, since then it's invisible to NAT-machines.
The next step might be digging down and trying to get some feedback from the local network stack, or maybe sniffing the network to see if the packets make it some way at least.
when I type wget http://yahoo.com:80 on unix shell. Can some one explain me what exactly happens from entering the command to reaching the yahoo server. Thank you very much in advance.
RFC provide you with all the details you need and are not tied to a tool or OS.
Wget uses in your case HTTP, which bases on TCP, which in turn uses IP, then it depends on what you use, most of the time you will encounter Ethernet frames.
In order to understand what happens, I urge you to install Wireshark and have a look at the dissected frames, you will get an overview of what data belongs to which network layer. That is the most easy way to visualize and learn what happens. Beside this if you really like (irony) funny documents (/irony) have a look at the corresponding RFCs HTTP: 2616 for example, for the others have a look at the external links at the bottom of the wikipedia articles.
The program uses DNS to resolve the host name to an IP. The classic API call is gethostbyname although newer programs should use getaddrinfo to be IPv6 compatible.
Since you specify the port, the program can skip looking up the default port for http. But if you hadn't, it would try a getservbyname to look up the default port (then again, wget may just embed port 80).
The program uses the network API to connect to the remote host. This is done with socket and connect
The program writes an http request to the connection with a call to write
The program reads the http response with one or more calls to read.
Is there any field/option/anything that I can put in a TCP packet (be it a syn or an ack or just plain data) that I can be sure will be returned by the other end intact?
For eg. I want to "tag" a particular connection (src, srcport, dst, dstport) with a number that I can always read from a packet belonging to that connection. That means I can identify the connection without using the 4-tuple (as given above).
Yes: it is called a Client protocol encapsulated in the TCP server protocol.
In other words: define the Client protocol to meet your needs. Don't try to "shove" extra bits in the TCP overhead.
There are of course the 'options' overhead in TCP but I doubt you'll find an easy way to access these... and in any case, you shouldn't.
You could possibly abuse the TCP Timestamp option for this. It does not seem like a great idea, though.
You can have a lookup table in your application where you associate your tag with the socket.
No, there isn't any facility for what you describe.
Typically what you would do if you're writing a socket application with multiple connections to other systems, is keep track of the socket handle that belongs to each remote system. When receiving data, you are using the socket handle (in some form, don't know which OS or language you're using) so you can take appropriate action based on whichever socket handle that is.
I've never seen a server application that keeps track of connections based on the 4-tuple of address/ports. That seems like way too much work.
On rereading your question, it seems like you may be asking this from the point of view of the TCP driver level. What sort of software are you writing here?
In UDP, destination IP and destination port number are used to demultiplex the packets, but in TCP destination IP, source IP, destination port number and source port numbers (4-tuple) all needed to distinguish between the connections why reasoning for this usage.