CC3000 as websocket server

Frank Vannieuwkerke

Other Parts Discussed in Thread: CC3100

Is it possible to use the CC3000 as a websocket server?

I ran following test using the CC3000 connected to a FRDM-KL25Z board :

CC3000 firmware and driver updated to the latest version.
I created a websocket client (HTML/Javascript - opened in google chrome).
Checked with wireshark whether the CC3000 responds to the websocket client (see picture).
Wireshark shows the client request and the CC3000 ACK.

When i connect the client to the CC3000, the CC3000 tells my code a connection is made but there is a lock-up, as a result, i cannot call receive (The CC3000 still responds to ping requests).

There is probably a problem with my KL25Z - CC3000 driver but, before i start debugging, i'd first like to know if the CC3000 can be used as a websocket server.

over 10 years ago

0 _theroot over 10 years ago

Prodigy 130 points

Hi Frank,

Can you share some code? Where is your code locking up? Are you able to read any packets from the CC3000 or are you locking up when you call `recv`?

Cheers

Josh

0 Frank Vannieuwkerke over 10 years ago in reply to _theroot

Prodigy 210 points

Hi Josh,

This is a project at mbed.org (user: frankvnk - not yet published - will be published in the coming days.

As the code rejects non-websocket connections (and tells us so through the serial interface), i tried to connect using the server IP address (using Google Chrome) and i do get the error message (ERROR: Non websocket). I noticed Chrome already tries to connect before i entered the entire IP address (address already present in the history) and tries to reconnect 2 more times after i hit enter. I solved the pre-connect by disabling Predict network actions to improve page load performance, but still, chrome tries 2 more times (so a total of 3 calls). Still using Google Chrome, when i try to use the annexed HTML code, i get a connect reply and the program locks-up before TCPSocketConnection::receive->recv can be called (recv is called through mbed's socket interface).

Next, i repeated above tests using IE10. Here, the direct IP address only returns ERROR: Non websocket once and connecting to the websocket using the annexed HTML code does work.

This is not the first time i noticed Chrome acts 'strange' as another CC3000 project, Wi-Go IOT Demo MKII (webserver), increments the page count by 2 when used with Chrome and correctly increments the page count when used with IE10.

It seems to me Chrome times out to soon (found several forums mentioning this - i don't know if this has been solved), overloading the CC3000 with additional requests = lock-up.

Perhaps i can (or need) to modify my HTML code to make it work with different browsers (probably not the best code - i am still learning a lot)?

HTML code

<!DOCTYPE html>
<html>
<body>
<h3>Simple WebSocket client - connect to ws://ip_address/ws/</h3>

<p> Send: <span id="wsmsg"</span></p>
<p> Recv: <span id="wsrcv"</span></p>
<p> WS status: <span id="wsstat"</span></p>
<p> WS readyState: <span id="wsid"</span></p>

Device IP:
<input type="text" id="ipName" name="ipName" value="192.168.0."></input>
<button onclick="WSopen()">Open</button>
<button onclick="WSclose()">Close</button>
<button onclick="WSsend()">Send</button>
<button onclick="WSrdy()">Ready State</button>

<script>
  var ws;
  var wsmsg = "Hi mbed ...";

  function WSopen() {
    ws = new WebSocket("ws://"+document.getElementById("ipName").value+"/ws/");
    document.getElementById("wsstat").innerHTML = "OPENED";
        ws.onmessage = function (evt) {
      WSdata(evt.data);
    };
    WSrdy();
  }

  function WSclose() {
    ws.close();
    document.getElementById("wsstat").innerHTML = "CLOSED";
    WSrdy();
  }

  function WSsend() {
    ws.send(wsmsg);
    document.getElementById("wsmsg").innerHTML = wsmsg;
  }

  function WSrdy() {
    document.getElementById("wsid").innerHTML = ws.readyState;
  }

  function WSdata(data) {
    document.getElementById("wsrcv").innerHTML = data;
  }
</script>

</body>
</html>

0 _theroot over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 130 points

"Next, i repeated above tests using IE10. Here, the direct IP address only returns ERROR: Non websocket once and connecting to the web-socket using the annexed HTML code does work." - Have you Wireshark'd the difference between Chrome's request and IE10's?

There is nothing special about the CC3000 which would prevent you from using it as a WebSocket server. Its Host Driver implementation give you a BSD socket *like* interface. This give you low enough access to build WebSocket server. The issue is more likely to be in your web-socket server implementation. Have you implemented this yourself or are you using a 3P library?

0 Frank Vannieuwkerke over 10 years ago in reply to _theroot

Prodigy 210 points

I will run a Wireshark capture tomorrow.

As for the WebSocket server code, this was created by another mbed user at developer.mbed.org/.../WebSocketServer

Note : at first, an IE request was rejected due to a little error in this code : Upgrade: websocket was checked for instead of Upgrade: Websocket

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

Update :

First of all, it seems only IE10 sends a Websocket request (capital W), so i'll just have to add a check for this in my code (or even better: capitalize all and check against capitalized data).

I attached the WireShark capture file :

Frames 1..19 are captured when connecting with IE10 - packet 4 is the websocket request and gets ACKed / processed correctly.

Frames 20..32 are captured when connecting with Google Chrome - packet 23 is the websocket request , only ACKed and a lock-up in the code (TCPSocketConnection::receive->recv is never reached).

IE and CHROME.zip

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

Update

To make sure my computer was not causing the issue, i repeated all tests on another system. The results are exactly the same :

IE10 = OK
Google Chrome Version 41.0.2272.101 m = lock-up at websocket connect (recv is never reached).

Next, i ran a test using Mozilla Firefox Version 36.0.4 and it works without any problems. As a result, this probably rules out a problem with the CC3000 microcode and/or user code?

Could it be Google Chrome adds/changes http header info that messes up the CC3000? What still surprises me is that the CC3000 ACKs the Websocket request before stopping all communication with the user code, while the CC3000 still responds to pings.

I really need a decent solution/explanation why this occurs, preferably not by telling me the CC3000 is obsolete and needs to be replaced with a CC3100/3200.

0 _theroot over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 130 points

"[...] the CC3000 is obsolete and needs to be replaced with a CC3100/3200." - Yeah, I'm getting fed up with hearing that too.

In your case, by the sound of it, the issue is in the web-socket implementation your using, not with the device its self. Have you approached the author?

0 Frank Vannieuwkerke over 10 years ago in reply to _theroot

Prodigy 210 points

Yes, i got in touch with the author of the websocket server code and asked him to test his code using Google Chrome (awaiting his reply - his WiFi module is from another manufacturer). On the other hand, i still doubt whether this code is causing the issue as i ran a very simple test : add printf("."); at the very start of tcpsocketconnection:: receive and to the recv function. When used with Google Chrome, this is never reached, so the server cannot process the request and tell Chrome the websocket is accepted.

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

Update

I just got confirmation from the author of the WebSocketServer code. He ran a test using Google Chrome and he confirmed it works without problems. The module he used to connect to was a Murata type YD Wi-Fi. The only difference is he uses Chrome with OSX, i am using Windows 7 Pro 64 but i don't think this makes a big difference (unless Chrome got a serious workover to run on OSX).

Please TI engineers, shed some light on this?

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

Confirmation : CC3000 as a websocket server doesn't like Google Chrome.
I got my hands on OSX and tried to connect to the CC3000 websocket server using Google Chrome. As expected, recv is never reached. I assume the header sent to the CC3000 by google Chrome contains info that is not understood/accepted by the CC3000 microcode. I hope the next generation CC3xxx will not suffer the same problem.

One solution would be TI releases the CC3000 microcode (probably won't happen), so we can fix this ourselves.

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

SOLVED

@_theroot : You were (partially) right, there was a driver problem, not in the websocket server code, but in the mbed CC3000 driver (shame on me).

I should have paid more attention to the size of the websocket request headers from each browser: IE10=327 bytes, Firefox=488 bytes and Chrome=537 bytes

The RX buffer size in the mbed code (ported from Avnet code) uses #define CC3000_MAXIMAL_RX_SIZE (511 + 1)

As the Chrome websocket request header exceeds this value, we get a lock-up. Raising this value to 767+1 already solved the problem.

In order to match Windows MTU (1500) i set it to TI's default value : #define CC3000_MAXIMAL_RX_SIZE (1519 + 1)

Perhaps other users having lock-up problems also need to check whether CC3000_MAXIMAL_RX_SIZE isn't set too low?

0 Frank Vannieuwkerke over 10 years ago in reply to Frank Vannieuwkerke

Prodigy 210 points

SOLVED

@_theroot : You were (partially) right, there was a driver problem, not in the websocket server code, but in the mbed CC3000 driver (shame on me).

I should have paid more attention to the size of the websocket request headers from each browser: IE10=327 bytes, Firefox=488 bytes and Chrome=537 bytes

The RX buffer size in the mbed code (ported from Avnet code) uses #define CC3000_MAXIMAL_RX_SIZE (511 + 1)

As the Chrome websocket request header exceeds this value, we get a lock-up. Raising this value to 767+1 already solved the problem.

In order to match Windows MTU (1500) i set it to TI's default value : #define CC3000_MAXIMAL_RX_SIZE (1519 + 1)

Perhaps other users having lock-up problems also need to check whether CC3000_MAXIMAL_RX_SIZE isn't set too low?

Wi-Fi

Wi-Fi forum

CC3000 as websocket server