Test Loom_Ethernet - Lucas

[lucasballr]

The SSL Client is reporting an error preventing from publishing.

[lucasballr]

[rcpeene]

I believe I am having the same issue.

[lucasballr]

This is different. Your DHCP server is not giving you an IP address, so the board is not connected to the internet. The write error being set is still a problem, but not your main one.

[prototypicalpro]

@lucasballr that error is generated from this code snippet: https://github.com/OPEnSLab-OSU/SSLClient/blob/1fe48948004a3ad52705ab26db4f65833ecb4e12/src/SSLClient.cpp#L487-L491, also shown below:

// if the arduino client encountered an error
if (get_arduino_client().getWriteError() || !get_arduino_client().connected()) {
    m_error("Error writing to m_client", func_name);
    m_error(get_arduino_client().getWriteError(), func_name);
    setWriteError(SSL_CLIENT_WRTIE_ERROR);
}

get_arduino_client returns the underlying network client instance (in your case probably EthernetClient) and get_arduino_client().getWriteError() checks to see if the network client instance has encountered an error. Since the logs indicate that this error check returned 1, the network interface probably encountered an issue and failed. SSLClient tries to avoid writing to a broken network interface, so the call to setWriteError causes SSLClient to bail out and refuse subsequent attempts to write to the network (generating a lot of log noise in the process). My guess is that if you find/fix the issue with Ethernet this issue will also go away. Does that help?

[lucasballr]

After looking around for a while, I can't seem to find what could be happening. I know there is some issue with the function that writes to the client then sets the write error and the messages that follow are a result of that write error being set, but there is nothing indicating what could be causing the write error. I compared all the code from 2.5 to 3.0 and I haven't found anything that would suggest problematic behavior.

[prototypicalpro]

@lucasballr EthernetClient can only set the write error here, which occurs when a call to Ethernet.socketSend returns zero (indicating an error has occurred). Ethernet.socketSend will only return zero in two places:
https://github.com/OPEnSLab-OSU/EthernetLarge/blob/75b8a8a2df93b72d16d68a555a839166887a903b/src/socket.cpp#L438-L443

...
status = W5100.readSnSR(s);
SPI.endTransaction();
if ((status != SnSR::ESTABLISHED) && (status != SnSR::CLOSE_WAIT)) {
  ret = 0; // this value is later returned
  break;
}
...

https://github.com/OPEnSLab-OSU/EthernetLarge/blob/75b8a8a2df93b72d16d68a555a839166887a903b/src/socket.cpp#L455-L458

...
if ( W5100.readSnSR(s) == SnSR::CLOSED ) {
  SPI.endTransaction();
  return 0;
}
...

In both places the driver calls W5100.readSnSR to read a register on the Ethernet module then checks the value against what the driver expects. Because of this, I think there's only two reasons why EthernetClient would set the write error:

• The Ethernet module moves to a state the driver doesn't expect. I used to see this a lot when the server would close the socket before the Ethernet driver is ready--usually the server would only do this if the request is incorrect/malformed, or if the request is complete and the Ethernet driver is getting ready to close the connection. You may want to check and see that the publish is actually not completing, as this error can occur even if the request to publish succeeds.
• The Ethernet module has a pin conflict/loose connection that is causing the status to read incorrectly during certain times. Since SnSR::CLOSED translates to zero, a pin conflict could definitely cause the status to read incorrectly and trigger a write error.

If double checking the hardware doesn't yield anything (definitely try swapping ethernet modules), I would bet that the HTTP request is getting malformed somehow and the server is rejecting it altogether. You might check that the request being sent is valid HTTP in that case.

Hopefully this saves some troubleshooting time 🙂.

[lucasballr]

So the pin conflict does not seem possible because the 2.5 version successfully sends the request and after comparing every internet file from 3.0 to 2.5, the pin values have not been changed. There are other changes within the files, but none that appear evidently problematic. I can't believe the request being malformed due to the internetplat.cpp being almost exactly the same between versions. I'm going to continue the hunt to find a solution, but I'm leaning towards either some other problem with internet module, or a problem with the way the SSL client was compressed to fit in the flash space of the feather. It's definitely not an ethernet specific thing either because the same error occurs with the WiFi module.

[lucasballr]

SOLVED: The JSON ctor was reading one less value than what was in the config.h causing the URL of the script to not be read correctly. I solved it by removing the '7001' section in the config.h and it publishes successfully. Will be updating all example code to make sure this doesn't happen again.

[udellc]

Glad to see!
We included these '7001' numbers in Loom2 to communicate which interface (WiFi client, WiFi access point, Ethernet, etc) was being used. Getting rid of this number in the config might not be how we want to handle it. Please consult with @lukegoertzen on approach. Thanks!

[lukegoertzen]

Removing those 7000 codes is correct, the publishing platforms do not expect them anymore.