I have a divert socket. I am trying to change the port on packets as I see them. When I do this - do I need to recalculate the TCP checksum, and the IP checksum?
I am trying to do this, but I am seeing reset packets in tcpdump. I dont know if this is because I am calculating the tcp checksum wrong, or if its something else going on.
I used the cksum methods from this site:
http://www.enderunix.org/docs/en/rawipspoof/
I thought with using a divert socket, if I change one thing, it should be fairly straightforward, but doesnt seem to be. is there a TCP checksum calculator out there I can use to verify I am getting the right value?
You do need to recompute the checksum. Here is a description of the calculation: TCP/IP Checksum calculation
See Section 3.3 of RFC 1631 for the checksum adjustments that a NAT/PAT must make. You don't have to go through the entire packet, you just need to adjust the checksum based on the bytes that you modify.
Related
I'm working on a Win32 application and have noticed I am getting checksum issues in Wireshark (checking is not enabled by default). The IP header checksum is being set to 0 (this is not a massive issue but it would be preferable to sort it) and the UDP checksum is being set to the value that is expected for the IP header checksum.
I am not doing anything to set the IP header checksum since it is out of scope for my project, but I have tried the steps here (also for the UDP checksum) to disable checksum offloading but that has not made a difference. No idea how to get it to set a value for the IP header checksum.
Regarding the UDP checksum, something I think I can affect, I have been experimenting with setsockopt, mainly setsockopt(UdpSocket, SOL_SOCKET, UDP_CHECKSUM_COVERAGE, (const char*)&t, sizeof(t)), where t is a bool/DWORD set to true, and the setsockopts line is after socket() and bind(), before sendTo(). I have also tried changing SOL_SOCKET to IPPROTO_UDP. I know the socket is set up correctly since it has all been working fine before looking at the checksums. Does anyone know any other things I can try? I feel like I am out of options.
Thanks for any help you can give!
I am sorry if the question is too naive, but I am confused. I want to send IPv6 jumbograms (to be able to multicast packets of size > 64 KB). I have been able to multicast normal IPv6 UDP packets successfully.
For sending jumbograms, from RFC 2675, I get that I have to make the following changes :
set payload length to 0
set next header to hop-by-hop
But, I don't get how to implement these in c socket programming (which function calls to make etc.). Do I have to create a custom header or are there functions like sendto available to send jumbograms?
You could use raw sockets if you are making your own headers. For more information, type man -s7 raw or look here. Note you will effectively need to implement your own IP stack that way.
However, my understanding is that linux itself supports IPv6 jumbograms natively so you don't need to bother. Try ifconfig lo mtu 100000 and do some tests over the loopback device to check.
I suspect the issue might be that your network adaptor and everything on the path (end to end) needs to support the jumbograms too.
I want to do my own very simple implementation of VPN in C on Linux. For that purpose I'm going to capture IP packets, modify them and send forward. The modification consists of encryption, authentication and other stuff like in IPSec. My question is should I process somehow the size of packets or this will be handled automatically? I know it's maximum size is 65535 - 20 (for header) but accoring to MTU it is lesser. I think its because encrypted payload "incapsulated into UDP" for NAT-T is much bigger then just "normal payload" of the IP packet.
Well, I found that there actually 2 ways to handle that problem:
1) We can send big packets by settings DF flag to tell we want fragment out packets. But in this case packet can be lost, because not all the devices/etc support packet fragmentation
2) We can automatically calculate our maximum MTU between hosts, split them and send. On another side we put all this packets together and restore them. This can be done by implementing our own "system" for this purpose.
More about IP packets fragmentation and reassembly you can read here
When receiving a UDP packet, where I do not know neither content nor structure, how can I find out what the content is? Is that possible somehow? Wireshark tells me the data is:
12:03:01:00:00:00:00:00:1f:44:fe:a2:07:e2:4c:28:00:15:e1:e0:00:80:12:61
The question is just about the data itself, not header of lower layers.
Thanks in advance for your help.
Wireshark shows UDP header. There is 2 port numbers. Usually another port number is reserved for the used protocol (not always).
You may look from the port reservation table which is the used protocol.
And if you are lucky, you find the protocol specification from Web and you can open the content of the packet.
I'm writing a windows driver (of course in c and I'm in kernel mode) and I'd like to open a tcp socket from the outside specifying the sequence number the first SYN packet should have.
I tried modifying the packet filtering it with Windows Filtering Platform, but of course it doesn't work because the stack think that the correct number is the original one and the recipient's stack think that the correct one is modified one.
I'm looking somethink like:
OpenSocket(..., UINT32 seqNum, UINT16 winSize)
or anything equivalent.
There is a way to do that?
Thanks,
Marco
Seems like a strange thing to be doing, but if your filter can modify both incoming and outgoing packets then it can fix the sequence number in both directions.
Just figure out the offset from the orignal sequence number. Then you can add it to the sequence number for outgoing packets and subtract it from the acknowledgment numbers for incoming packets.
Each side of the conversation gets exactly what they expect, even though they disagree on what is expected.