<scrts>
I should take ones_compl(0xAD68)=0x5297 and ones_compl(0x298B)=0xD674 then 0x5297+0xD674.. then all the bytes added in such way..?
<kristianpaul>
morning :-)
<Fallenou>
scrts: UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.
<Fallenou>
I quote from wikipedia
<Fallenou>
I quote the RFC
<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]
<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
<Fallenou>
well it seems you could just set the checksum as 0
<Fallenou>
but computing it in hardware seems feasible
<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)
<Fallenou>
and then eventually you do the NOT logical operation on the result
<Fallenou>
like ~result;
<scrts>
hm, that all 16 bit words are what? source port, dest port, source addr, dest addr,  all the payload, length etc?
<Fallenou>
pseudo header, followed by udp header, followed by udp payload
<Fallenou>
and padded with 0x00 if the number of bytes is not a multiple of two
<Fallenou>
(because you need to be able to sum 16 bits words)
<scrts>
well yes, in my case the payload is 18 bytes, so no padding required
<Fallenou>
anyway the padding is then dropped after checksum computation
<Fallenou>
it's not sent over the wire
<Fallenou>
(or whatever physical medium you use)
<Fallenou>
one other thing, during checksum computation, set the udp checksum as 0
<scrts>
well I am still failing to calculate that checksum from the packet example
<Fallenou>
I had this problem but with tcp a few days ago
<Fallenou>
but I didn't sort everything out yet
<Fallenou>
scrts: I'm not sure about the endianness
<Fallenou>
about the summing of 16 bits words
<Fallenou>
if you have aa bb cc dd , not sure if you have to do aa bb + cc dd or  bb aa + dd cc
<Fallenou>
dunno
<scrts>
I am not sure too, trying all the possible variants :))
<Fallenou>
yep I guess that's the only solution :p
<Fallenou>
but I think you should do aa bb + cc dd
<Fallenou>
but that's what the processor is not doing i think
<Fallenou>
if it's normal x86 processor
<Fallenou>
since it's little endian
<Fallenou>
so you may do htons(ntohs(word[i]) + ntohs(word[i+1]))
<Fallenou>
or something like that
<Fallenou>
well more something like sum += ntohs(word[i])
<Fallenou>
and then ~sum; and then write htons(sum)
<scrts>
what does ntohs()?
<scrts>
I think I understood the calculation
<scrts>
wait a minute, I am checking myself with another packet
<Fallenou>
ntohs = network to host (for short type, i.e 16 bits)
<Fallenou>
network is big endian
<Fallenou>
ntohs implementation depends on your arch endianness for example
<Fallenou>
so I guess it's some kind of a dummy byte swap for x86
<Fallenou>
for example in userspace when you bind a socket to a port, you do port = htons(80)
<Fallenou>
for port 80
<Fallenou>
in order to put 0x0080 in the memory, and not 0x8000
<scrts>
yep, my calculations now are correct
<scrts>
want to know?
<scrts>
:)
<Fallenou>
yep sure :)
<Fallenou>
is it C code ?
<Fallenou>
if you can pastebin
<scrts>
no, I did everything by hand
<scrts>
take a look at the screenshot I gave before
<scrts>
so You sum up the data as it is, but in 16 bit order: 06BA+02E6+E9AA...=3CBD0
<scrts>
then
<scrts>
sum the source address and destination address in the same way: 3CBD0+2E49+385A+C0A8+0031
<Fallenou>
yep that's what I would have done
<Fallenou>
but in C you have to beware of endianness
<scrts>
plus protocol +0011
<Fallenou>
but yes
<scrts>
plus 2X (!!!) length
<scrts>
001A+001A
<scrts>
the everything xor FFFF
<scrts>
= checksum
<scrts>
now the problem is, how many clock cycles that would take..
<Fallenou>
hehe
<Fallenou>
you can easily parallelize the summation
<Fallenou>
using several summers in parallel
<Fallenou>
using like "pyramids" of summers
<scrts>
it is
<scrts>
however one clock cycle will be eaten by carry transfer :\
<scrts>
hm, I wonder if it is possible to solve this..
<Fallenou>
well to add two 16 bits words, you need more than 1 clock cycle ?
<Fallenou>
oh and btw, why 2 times the length ? :o :o
<Fallenou>
I've read that nowhere
<scrts>
the udp header includes UDP length
<scrts>
and the pseudo ip header includes the length
<scrts>
somehow those two "merged" into one in my brain lol
<scrts>
:)
<Fallenou>
oh yes
<Fallenou>
I took that into account
<Fallenou>
but not like this :p
<Fallenou>
ok ok
<scrts>
ok now o
<scrts>
modelsim
<scrts>
:)
<Fallenou>
huhu
<Fallenou>
good luck
<Fallenou>
and thanks for asking the question
<Fallenou>
it made the problem more clear to me too :)