[etherlab-dev] [Patch] Fix for FoE busy response during read and error handling

[Gavin Lambert]

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.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foe_busy_1.patch
Type: application/octet-stream
Size: 1808 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20130826/64fa4096/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foe_busy_2.patch
Type: application/octet-stream
Size: 2278 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20130826/64fa4096/attachment-0001.obj>