Attached are two patches to fix issues I encountered while testing FoE. (Incidentally, from prior posts to this list it seems like you've had trouble finding a slave to test FoE on. While I can't get you one of your own, I do presently have access to a slave that I can modify, if that would help with anything else you would like tested.)
Patch 1 is the "main" bugfix patch, and fixes the following issues: - if a slave returns an ERROR response to an FoE write, the error was treated as a generic process error (ACK_ERROR) instead of being reported properly. - if a slave returns a BUSY response to an FoE read, the state machine got hung up and started treating its own transmitted datagram as having been received, causing general confusion all around. - if a slave returns a single null byte as its FoE ERROR text, the master would try to log it using the verbose path, which is undesirable. (The FoE standard is unclear whether a slave that does not want to return error text should omit the field entirely or transmit a null byte. The former is probably the preferred behaviour but the slave implementation example code will do the latter, so it should be handled gracefully.) - if a slave returns an error message longer than 256 bytes, use of strncpy will result in an unterminated buffer and the error log will go astray. (Unusual but not impossible, depending on the size of the slave's mailbox.) Patch 2 is optional and just consists of extra logging information (gated on FOE_DEBUG) that helped me to track down the above issues. It does make transfers quite verbose, but only when FOE_DEBUG is defined. Both patches are generated independently from f8b779c9794edceab56cfd0085bfb99970044745, so they should be able to apply cleanly in either order against the latest version. On a somewhat related note, if you're not looking closely at the users list, I posted a message there last week titled "Mailbox handling of interleaving responses" (2013-08-20), which I would appreciate developer feedback on. (Reposting the whole thing here seems silly/spammy though.)
foe_busy_1.patch
Description: Binary data
foe_busy_2.patch
Description: Binary data
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
