Ethernet::Receive() returns -3

07 Jul 2010

What does it mean when Ethernet::receive() returns -3? 

I dynamically create an ethernet object, verify link, call Ethernet::receive() to ensure no packet is already waiting for reading (it is not), send an ARP packet, get a valid ARP response, Ethernet::read() the response, test its IP address and then delete the ethernet object.  I then repeat this sequence but when the Ethernet::receive() is called it returns a -3. 

08 Jul 2010

This is due to some internal lower level state not getting re-initialised properly. I'll file it as a bug.

08 Jul 2010

Thanks for the sanity check.  Is there some way to work around this or avoid it because it is one of my last stumbling blocks on this project?  If not, do you have a sense as to when it might be fixed?


08 Jul 2010

Hopefully, the latest version of the library that just went live should fix this. It certainly fixes the re-initialisation problem - could you confirm/deny that it does fix this?

08 Jul 2010

Yes, this seems to have fixed the -3 being returned by Ethernet::receive().  Kudos for an ultra fast fix - if you were local I'd buy you a pint!!!  I had discovered with the state machine clue above that if I inserted a wait(1) before calling "delete p_eth" that it also worked. 

If there are other negative responses that could be returned, the handbook info for the receive() should include a note to test for a data count greater than zero as opposed to a value that is non-zero.  Trying to do a read() when a negative value is returned results in a lockup since the negative value never is cleared.