CC3235MODSF: Web protocol issue

Hi Mike,

It is not clear how they are trying to enable this on CC3235.

There is no support for websocket in the CC3235 SDK today.

They will need to port the webserver library from the CC3200 SDK to the gen2 (CC3235) SDK.

If the binding for port 80 fails, they should check whether the internal HTTP server is enabled and disable it:

sl_NetAppStop(SL_NETAPP_HTTP_SERVER_ID);

Br,

Kobi

Hi Kobi,

Thank you for your suggestion.

F.Y.I, I have been asking questions related to websocket for CC3235SF since few months.

I have imported CC3200 server libraries to CC3235SF and also disabled internal HTTP server.

After disabling internal HTTP server, sl_bind function is working and stuck at sl_accept which is returning an error value of -11 (which says HTTP accept retry)

Below attached the console log of CCS when I try to connect with my HTML application.

I have been playing around with TCP ports and end up having no luck.

surprisingly, I couldn't modify these library files.

Thanks and Regards,

Vignesh

-11 is SL_ERROR_BSD_EAGAIN (see simplelink/errors.h).

It is a typical return code for non-blocking sockets. Instead of waiting (blocking) for the "sl_Accept" to return (when a clients connect) you'll need to reinvoke the sl_Accept until you get a valid socket id (>=0) or other error code.

From the log it seems that eventually (i.e. in the 2nd attempt) the accept returned correctly.

I'm not sure what do you mean by "I couldn't modify these library files" - it is just a source code and i assumed you've already updated it to enable it with the CC3235 SDK. You will need to update the code so it can compile and link to the CC3235 host driver.

Br,

Kobi

Hi Kobi,

Thanks for your info.

I'm not sure what do you mean by 'reinvoke sl_Accept'. From source code point of view, it is defined (>=0) at sl_accept.

Concerning the log, until I see my HTML app on browser it says 'HTTP accept retry -11'. Once I invoke HTML using IP address I see the following log.

And I try to have connection with my HTML which doesn't happen (below picture) - says connecting all the time.

The WebServer code (see RunHttpServer()) already calls sl_Accept (the sl_Accept is called within CreateTCPClientSocket() ) in a loop when it receives -11 (see SL_EAGAIN handling). 

I'm not sure what exactly is the current issue (it doesn't appear in the log) but it is accepting the client socket.

You need to further debug the state of the webserver.

Are you using CC3200 or cc3235 for this? did it work using cc3200?

Br,

Kobi

Hi Kobi,

Current situation:

This happens when Internal HTTP server is disabled hence couldn't load HTML application on browser. (I have also tried loading HTML file from PC to check the status which also ended up happening nothing)

When enabled internal HTTP server, HTML is accessed on browser using IP address but there is no websocket connection.

This problem wasn't an issue whilst using CC3200. As even though, internal HTTP server was disabled, I was successfully able to have websocket connection with my HTML page when loaded on browser.

Also, why should we disable internal HTTP server?

What I meant by 'couldn't modify libraries' is,

I was trying to figure out at what point the return value is -98 and I couldn't do it. To check, I have tried to insert errors to see impact while building and debugging but it still builds and debugs successfully.

Hope this has given you a better idea.

Regards,

Vignesh

-98 is SL_ERROR_BSD_EADDRINUSE (see simplelnk/errors.h).

The internal HTTP server doesn't support WebSocket. You need to disable it in order to use port 80 by the host's WebServer.

The WebServer lib does works with the FS and should be able to read file if it exist.

I see that you are trying to access "/main1.html" - at least when using CC3220/35 you should avoid the leading "/" when accessing files in the root folder.

You can set a breakpoint in the sl_FsOpen (called from HttpStatic_InitRequest)  and check what is the filename used and compare it to the path of the file in your file system.

Br,

Kobi

Hi Kobi,

Thank you for the information.

As you suggested, it's not hitting the breakpoint in HttpStatic_InitRequest function where sl_FsOpen is called.

On the console I see,

Http server socket 0

Accepting new connection number 0

Connection opened

Http Client close 0

Close connection

Also, Filename is '/main.html' with FsDir 'www'. It's the exact path provided in Uniflash as well. - changed with main1.html as well (same prob)

Concerning " / " sorry, I didn't understand.

I use IP address/main1.html on browser to access. Root folder - you meant from Uniflash or file explorer?

Or do let me know how can I possibly avoid using ' /'.

Just an information required, how badly this could be the effect from HTML application?

Regards,

Vignesh

It seems that the connection was closed by the peer (Http Client Close 0), i.e. the sl_Recv returned with len == 0 which means that connection was closed (gracefully) by the peer. I'm not sure what was the reason. You may need to check with a sniffer log.

Br,

Kobi