> UDP checksums are now off-by-one, and I don't understand why. IP checksum > code appears to be ok, based on a couple of test cases. UDP checksums are > based on the IP checksum code. Additionally, the inline assembler > optimisation that I did does not work, but that can wait for later. I found the bug. The real bug was (is) in the IP checksum correction, not UDP checksum computation. I think the IP checksum correction is still broken: apparently it now works most of the time but fails with certain corner case values, but I'm not sure. But I was barking the wrong tree for a few days. It also appears that Mac OS X *does* accept zero UDP checksum, i.e. the whole checksum computation code is not needed (yet). But of course it doesn't harm that it is there, if we just manage to find or generate enough of test cases for it so that it becomes robust. That is, apparently there is (may be) also something fishy in the UDP checksum, but that can be fixed later, for now even CoAP works (with Copper) if UDP checksums sent as zeroes. The code is now in github in the feature-coap-temp branch. I will clean it up and merge to feature-coap-wip branch ASAP, then start working towards a merger into the master. Please expect the merge to take some time; it is better to start e.g. IDE integration with the feature-coap-wip branch than wait for the merge. If you want to test, here is how: git clone --branch feature-coap-temp https://github.com/Ell-i/Runtime.git cd Runtime/stm32/library make cd ../examples/CoAP make stm32flash -w hello_world.hex /dev/... sudo ifconfig ... 10.0.0.1 alias ping 10.0.0.2 Then install Mozilla, Copper, and fetch coap://10.0.0.2:5683/hello In any case, now for the first time the new stack works for real. Work still remains to be done, of course, but now we can start to think about things like API, integration of the new Runtime and Arduino IDE, etc. It took some time longer than I thought, for a number of reasons, but the code is now there, it is relatively simple, and most importantly it generates very small binaries. As one of the next steps, I think it would be very good to get some test cases for the code, both test cases running in the emulator with the pcap interfaces, but also test cases that run against the real hardware. With such test cases in place, I would feel much more confident in fiddling with the code in an attempt to make the binaries even smaller. There are now known inefficiencies and inelegant things. The inelegant things I'm planning to fix before merging to master, but the inefficiencies will most probably remain there until we have some kind of a test suite. --Pekka