| 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!
