[sr-dev] WebSockets broken?

Peter Dunkley peter.dunkley at crocodile-rcs.com
Fri May 31 12:18:47 CEST 2013


I found the problem.  It was a typo on my part in the configuration file 
(added as I was trying different things to work out why it was 
seg-faulting earlier).

To find it I just loaded on an earlier version of Chrome with "better" 
error messages and recognised it as something I'd seen before.

Regards,

Peter

On 30/05/13 19:08, Peter Dunkley wrote:
> The reserved bits are part of the WebSocket header that gets put 
> before the actual data.
>
> Looking in Wireshark those bits are (correctly) all 0. But it is not 
> unusual for Chrome to present an error message that is completely 
> inaccurate and it is probably something else in the header that is the 
> problem.
>
> Tomorrow morning I plan to roll-back the build and I should be able to 
> produce two traces that are almost identical (as far as the payload 
> goes) - one for each version.  At that point I will be able to do a 
> proper bit-level comparison between the data in the IP packet.
>
> That might at least give a clue as to which set of commits the problem 
> might have appeared in :-)
>
> Regards,
>
> Peter
>
> On 30 May 2013, at 18:03, Daniel-Constantin Mierla <miconda at gmail.com 
> <mailto:miconda at gmail.com>> wrote:
>
>> Hello,
>>
>> you can have some fun and then revert :-)
>>
>> Are the reserved bits before or after the websocket payload?
>>
>> Cheers,
>> Daniel
>>
>> On 5/30/13 6:58 PM, Peter Dunkley wrote:
>>> Hi Daniel,
>>>
>>> I don't think it is an MSRP issue.  It's just I have first spotted 
>>> it with MSRP and now can't risk touching my SIP WebSocket server.
>>>
>>> My suspicion is that (if it is related to the changes made in the 
>>> last 10 days) it is something that happens during or after a call to 
>>> tcp_send().
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>>
>>> On 30/05/13 17:56, Daniel-Constantin Mierla wrote:
>>>>
>>>> On 5/30/13 6:44 PM, Peter Dunkley wrote:
>>>>> I don't have a commit ID for it working as the system that is 
>>>>> working was installed from RPMs.  However, It was compiled at 
>>>>> 18:39:25 (BST) on May 20 2013.
>>>>>
>>>>> It will have been a clean pull from Git at the time it was built.
>>>> After that date, from core perspective, sctp was moved as a module, 
>>>> syn_branch parameter removed and pv cache used for confg vars, but 
>>>> it doesn't look like should be a direct effect on msrp. A bit 
>>>> before was removal of IPv6 define.
>>>>
>>>> Maybe is a side effect with some memory overflow. Can you compile 
>>>> with MEMDBG=1 and see if you get some errors from memory manager?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>>
>>>>> Peter
>>>>>
>>>>> On 30/05/13 17:36, Daniel-Constantin Mierla wrote:
>>>>>>
>>>>>> On 5/30/13 6:17 PM, Peter Dunkley wrote:
>>>>>>> When latest Kamailio git master sends a message over WebSocket 
>>>>>>> (specifically an MSRP reply on my test system) I get the error,
>>>>>>>
>>>>>>>     One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0
>>>>>>>
>>>>>>> in Google Chrome.  This happens for WebSockets over TCP and 
>>>>>>> WebSockets over TLS.  It doesn't happen with a build of Kamailio 
>>>>>>> git master from around two weeks ago.
>>>>>>>
>>>>>>> Have there been any changes in the network code over the last 
>>>>>>> couple of weeks that might have had an effect on what Kamailio 
>>>>>>> puts out on the wire for TCP and TLS?
>>>>>> I don't recall any, but if you give the commit id of the version 
>>>>>> you are running and it is ok, we can check the rest of the 
>>>>>> commits till today.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>>
>>>>>>> The code to send an MSRP reply over WebSocket is in 
>>>>>>> modules/msrp/msrp_netio.c:msrp_reply()
>>>>>>>          if (unlikely((env->srcinfo.proto == PROTO_WS
>>>>>>>                          || env->srcinfo.proto == PROTO_WSS)
>>>>>>>                          && sr_event_enabled(SREV_TCP_WS_FRAME_OUT))) {
>>>>>>>                  struct tcp_connection *con = tcpconn_get(env->srcinfo.id, 0, 0,
>>>>>>>                                                                  0, 0);
>>>>>>>                  ws_event_info_t wsev;
>>>>>>>
>>>>>>>                  if (con == NULL)
>>>>>>>                  {
>>>>>>>                          LM_WARN("TCP/TLS connection for WebSocket could not be"
>>>>>>>                                  "found\n");
>>>>>>>                          return -1;
>>>>>>>                  }
>>>>>>>
>>>>>>>                  memset(&wsev, 0, sizeof(ws_event_info_t));
>>>>>>>                  wsev.type = SREV_TCP_WS_FRAME_OUT;
>>>>>>>                  wsev.buf = rplbuf;
>>>>>>>                  wsev.len = p - rplbuf;
>>>>>>>                  wsev.id = con->id;
>>>>>>>                  return sr_event_exec(SREV_TCP_WS_FRAME_OUT, (void *) &wsev);
>>>>>>>          }
>>>>>>>
>>>>>>> The code that handles the SREV_TCP_WS_FRAME_OUT event is in 
>>>>>>> modules/websocket/ws_frame.c and basically involves:
>>>>>>>
>>>>>>>   * filling in the WebSocket message header
>>>>>>>   * identifying the correct TCP/TLS connection
>>>>>>>   * setting some flags (for example, SND_F_FORCE_CON_REUSE)
>>>>>>>   * calling tcp_send()
>>>>>>>
>>>>>>> These areas of the code haven't been changed for months.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sr-dev mailing list
>>>>>>> sr-dev at lists.sip-router.org
>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>>>
>>>>>> -- 
>>>>>> Daniel-Constantin Mierla -http://www.asipto.com
>>>>>> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>>>>>> Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
>>>>>>    *http://asipto.com/u/katu  *
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sr-dev mailing list
>>>>>> sr-dev at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sr-dev mailing list
>>>>> sr-dev at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>> -- 
>>>> Daniel-Constantin Mierla -http://www.asipto.com
>>>> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
>>>>    *http://asipto.com/u/katu  *
>>>>
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>> -- 
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
>>    *http://asipto.com/u/katu  *
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130531/88c9536b/attachment.html>


More information about the sr-dev mailing list