wpwrak | (albatart) sounds like a very cool squat ;) | 01:53 |
---|---|---|
wpwrak | a bit posh, though | 01:54 |
scrts | morning | 04:58 |
kristianpaul | night.. | 04:58 |
kristianpaul | gn8 :-) | 04:58 |
scrts | :)) | 05:08 |
scrts | is udp checksum is calculated in minimac or it is left all 0 ? | 10:17 |
Fallenou | it's calculated by rtems | 10:17 |
Fallenou | minimac does not compute anything AFAIK | 10:17 |
Fallenou | not even Ethernet Checksum | 10:18 |
scrts | hmm, where can I find a reference how the checksum is calculated? | 10:19 |
Fallenou | you mean in theory ? | 10:22 |
Fallenou | I thing udp checksum is the same as tcp checksum | 10:23 |
Fallenou | it's the 1 complement (on 16 bits) of the sum of the 1 complement of bytes of header + payload | 10:24 |
Fallenou | and you have a pseudo header to add to that | 10:24 |
Fallenou | based upon the IP header (ip addr source, dest etc) | 10:25 |
Fallenou | this may give you an hint http://www.netfor2.com/udpsum.htm not sure if it is correct but that's the idea | 10:25 |
scrts | hm, so I take two bytes, make that ones complement, take another two bytes, make them ones complement and do a sum? | 10:30 |
scrts | e.g. here is a good packet: http://i54.tinypic.com/14o7pzn.jpg | 10:32 |
scrts | I should take ones_compl(0xAD68)=0x5297 and ones_compl(0x298B)=0xD674 then 0x5297+0xD674.. then all the bytes added in such way..? | 10:34 |
kristianpaul | morning :-) | 11:02 |
Fallenou | scrts: UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero. | 11:15 |
Fallenou | I quote from wikipedia | 11:15 |
Fallenou | I quote the RFC | 11:15 |
Fallenou | Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.[4] | 11:15 |
scrts | I know, however UDP checksum is a part of IP header checksum, so if I compute this in hardware, I could do less job in software | 11:16 |
Fallenou | well it seems you could just set the checksum as 0 | 11:16 |
Fallenou | but computing it in hardware seems feasible | 11:17 |
Fallenou | scrts: I guess it just means you add all the 16 bits words together using "normal arithmetic" (what they call one's complement arithmetic) | 12:01 |
Fallenou | and then eventually you do the NOT logical operation on the result | 12:02 |
Fallenou | like ~result; | 12:02 |
scrts | hm, that all 16 bit words are what? source port, dest port, source addr, dest addr, all the payload, length etc? | 12:03 |
Fallenou | pseudo header, followed by udp header, followed by udp payload | 12:03 |
Fallenou | and padded with 0x00 if the number of bytes is not a multiple of two | 12:04 |
Fallenou | (because you need to be able to sum 16 bits words) | 12:04 |
scrts | well yes, in my case the payload is 18 bytes, so no padding required | 12:04 |
Fallenou | anyway the padding is then dropped after checksum computation | 12:04 |
Fallenou | it's not sent over the wire | 12:04 |
Fallenou | (or whatever physical medium you use) | 12:04 |
Fallenou | one other thing, during checksum computation, set the udp checksum as 0 | 12:05 |
scrts | well I am still failing to calculate that checksum from the packet example | 12:05 |
Fallenou | I had this problem but with tcp a few days ago | 12:06 |
Fallenou | but I didn't sort everything out yet | 12:06 |
Fallenou | scrts: I'm not sure about the endianness | 12:07 |
Fallenou | about the summing of 16 bits words | 12:07 |
Fallenou | if you have aa bb cc dd , not sure if you have to do aa bb + cc dd or bb aa + dd cc | 12:07 |
Fallenou | dunno | 12:07 |
scrts | I am not sure too, trying all the possible variants :)) | 12:07 |
Fallenou | yep I guess that's the only solution :p | 12:07 |
Fallenou | but I think you should do aa bb + cc dd | 12:08 |
Fallenou | but that's what the processor is not doing i think | 12:08 |
Fallenou | if it's normal x86 processor | 12:08 |
Fallenou | since it's little endian | 12:08 |
Fallenou | so you may do htons(ntohs(word[i]) + ntohs(word[i+1])) | 12:09 |
Fallenou | or something like that | 12:09 |
Fallenou | well more something like sum += ntohs(word[i]) | 12:10 |
Fallenou | and then ~sum; and then write htons(sum) | 12:11 |
scrts | what does ntohs()? | 12:18 |
scrts | I think I understood the calculation | 12:18 |
scrts | wait a minute, I am checking myself with another packet | 12:19 |
Fallenou | ntohs = network to host (for short type, i.e 16 bits) | 12:19 |
Fallenou | network is big endian | 12:19 |
Fallenou | ntohs implementation depends on your arch endianness for example | 12:20 |
Fallenou | so I guess it's some kind of a dummy byte swap for x86 | 12:20 |
Fallenou | for example in userspace when you bind a socket to a port, you do port = htons(80) | 12:20 |
Fallenou | for port 80 | 12:20 |
Fallenou | in order to put 0x0080 in the memory, and not 0x8000 | 12:21 |
scrts | yep, my calculations now are correct | 12:23 |
scrts | want to know? | 12:23 |
scrts | :) | 12:23 |
Fallenou | yep sure :) | 12:25 |
Fallenou | is it C code ? | 12:25 |
Fallenou | if you can pastebin | 12:25 |
scrts | no, I did everything by hand | 12:25 |
scrts | take a look at the screenshot I gave before | 12:26 |
scrts | so You sum up the data as it is, but in 16 bit order: 06BA+02E6+E9AA...=3CBD0 | 12:26 |
scrts | then | 12:26 |
scrts | sum the source address and destination address in the same way: 3CBD0+2E49+385A+C0A8+0031 | 12:27 |
Fallenou | yep that's what I would have done | 12:27 |
Fallenou | but in C you have to beware of endianness | 12:27 |
scrts | plus protocol +0011 | 12:27 |
Fallenou | but yes | 12:27 |
scrts | plus 2X (!!!) length | 12:27 |
scrts | 001A+001A | 12:28 |
scrts | the everything xor FFFF | 12:28 |
scrts | = checksum | 12:28 |
scrts | now the problem is, how many clock cycles that would take.. | 12:28 |
Fallenou | hehe | 12:28 |
Fallenou | you can easily parallelize the summation | 12:29 |
Fallenou | using several summers in parallel | 12:29 |
Fallenou | using like "pyramids" of summers | 12:29 |
scrts | it is | 12:29 |
scrts | however one clock cycle will be eaten by carry transfer :\ | 12:29 |
scrts | hm, I wonder if it is possible to solve this.. | 12:29 |
Fallenou | well to add two 16 bits words, you need more than 1 clock cycle ? | 12:30 |
Fallenou | oh and btw, why 2 times the length ? :o :o | 12:30 |
Fallenou | I've read that nowhere | 12:30 |
scrts | the udp header includes UDP length | 12:31 |
scrts | and the pseudo ip header includes the length | 12:31 |
scrts | somehow those two "merged" into one in my brain lol | 12:32 |
scrts | :) | 12:32 |
Fallenou | oh yes | 12:32 |
Fallenou | I took that into account | 12:32 |
Fallenou | but not like this :p | 12:32 |
Fallenou | ok ok | 12:32 |
scrts | ok now o | 12:32 |
scrts | modelsim | 12:32 |
scrts | :) | 12:32 |
Fallenou | huhu | 12:35 |
Fallenou | good luck | 12:35 |
Fallenou | and thanks for asking the question | 12:35 |
Fallenou | it made the problem more clear to me too :) | 12:35 |
--- Fri May 27 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!