TCPSocket data breaks on NULL character.

RESOLVED WORKSFORME

Status

Firefox OS
General
RESOLVED WORKSFORME
3 years ago
a year ago

People

(Reporter: David Holdeman, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150101004004

Steps to reproduce:

Any packet with data containing a NULL character (\0) received with mozTCPSocket.ondata is broken at the null character.
Example packet: (from nethack.alt.org)
11:20:38.112285 IP alt.org.telnet > mycomputer.40832: Flags [P.], seq 70:636, ack 134, win 91, options [nop,nop,TS val 3104729753 ecr 271876358], length 566
        0x0000:  0017 f207 ff5d 6470 0299 4a9a 0800 4508  .....]dp..J...E.
        0x0010:  026a 2e79 4000 2a06 0ea0 ccec 82d2 c0a8  .j.y@.*.........
        0x0020:  0106 0017 9f80 453b 44b1 0777 7511 8018  ......E;D..wu...
        0x0030:  005b 981a 0000 0101 080a b90e 6a99 1034  .[..........j..4
        0x0040:  8106 fffb 0144 6562 6961 6e20 474e 552f  .....Debian.GNU/
        0x0050:  4c69 6e75 7820 362e 300d 0a3b 1b5d 323b  Linux.6.0..;.]2;
        0x0060:  6e65 7468 6163 6b2e 616c 742e 6f72 6707  nethack.alt.org.
        0x0070:  1b5b 324a 1b5b 3f31 3034 3968 1b5b 313b  .[2J.[?1049h.[1;
        0x0080:  3234 721b 5b6d 1b28 421b 5b34 6c1b 5b3f  24r.[m.(B.[4l.[?
        0x0090:  3768 1b5b 3f31 681b 3d1b 5b33 393b 3439  7h.[?1h.=.[39;49
        0x00a0:  6d1b 5b33 393b 3439 6d1b 5b6d 1b28 421b  m.[39;49m.[m.(B.
        0x00b0:  5b48 1b5b 324a 1b5b 3234 3b31 481b 5b3f  [H.[2J.[24;1H.[?
        0x00c0:  3130 3439 6c0d 001b 5b3f 316c 1b3e 1b5b  1049l...[?1l.>.[
        0x00d0:  324a 1b5b 3f31 3034 3968 1b5b 313b 3234  2J.[?1049h.[1;24
        0x00e0:  721b 5b6d 1b28 421b 5b34 6c1b 5b3f 3768  r.[m.(B.[4l.[?7h
        0x00f0:  1b5b 3f31 681b 3d1b 5b33 393b 3439 6d1b  .[?1h.=.[39;49m.
        0x0100:  5b33 393b 3439 6d1b 5b6d 1b28 421b 5b48  [39;49m.[m.(B.[H
        0x0110:  1b5b 324a 1b5b 481b 5b32 4a1b 5b32 6420  .[2J.[H.[2J.[2d.
        0x0120:  2323 201b 5b30 3b31 6d1b 2842 1b5b 3333  ##..[0;1m.(B.[33
        0x0130:  6d1b 5b34 306d 6e65 7468 6163 6b2e 616c  m.[40mnethack.al
        0x0140:  742e 6f72 6720 2d20 6874 7470 3a2f 2f6e  t.org.-.http://n
        0x0150:  6574 6861 636b 2e61 6c74 2e6f 7267 2f1b  ethack.alt.org/.
        0x0160:  5b33 3b32 481b 5b33 393b 3439 6d1b 5b6d  [3;2H.[39;49m.[m
        0x0170:  1b28 4223 231b 5b34 6408 0823 2320 4761  .(B##.[4d..##.Ga
        0x0180:  6d65 7320 6f6e 2074 6869 7320 7365 7276  mes.on.this.serv
        0x0190:  6572 2061 7265 2072 6563 6f72 6465 6420  er.are.recorded.
        0x01a0:  666f 7220 696e 2d70 726f 6772 6573 7320  for.in-progress.
        0x01b0:  7669 6577 696e 6720 616e 6420 706c 6179  viewing.and.play
        0x01c0:  6261 636b 211b 5b36 3b33 484e 6f74 206c  back!.[6;3HNot.l
        0x01d0:  6f67 6765 6420 696e 2e1b 5b38 3b33 486c  ogged.in..[8;3Hl
        0x01e0:  2920 4c6f 6769 6e1b 5b39 3b33 4872 2920  ).Login.[9;3Hr).
        0x01f0:  5265 6769 7374 6572 206e 6577 2075 7365  Register.new.use
        0x0200:  721b 5b31 303b 3348 7729 2057 6174 6368  r.[10;3Hw).Watch
        0x0210:  2067 616d 6573 2069 6e20 7072 6f67 7265  .games.in.progre
        0x0220:  7373 1b5b 3132 3b33 4873 2920 7365 7276  ss.[12;3Hs).serv
        0x0230:  6572 2069 6e66 6f1b 5b31 333b 3348 6d29  er.info.[13;3Hm)
        0x0240:  204d 4f54 442f 6e65 7773 2028 7570 6461  .MOTD/news.(upda
        0x0250:  7465 643a 2032 3031 342e 3033 2e32 3329  ted:.2014.03.23)
        0x0260:  1b5b 3135 3b33 4871 2920 5175 6974 1b5b  .[15;3Hq).Quit.[
        0x0270:  3139 3b33 483d 3e20                      19;3H=>.

The null character occurs on 0x00c0 just after "1049l".


Actual results:

With the above packet, this is the string that is received:
"Debian GNU/Linux 6.0

;]2;nethack.alt.org[2J[?1049h[1;24r[m(B[4l[?7h[?1h=[39;49m[39;49m[m(B[H[2J[24;1H[?1049l"


Expected results:

AFAIK there is no reason to break a packet on a null character. Telnet doesn't do it, and neither does netcat.
Did you set the socket in binary mode as explained at https://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMTCPSocket.idl#158 ?
(Reporter)

Comment 2

3 years ago
Like this?
    socket = navigator.mozTCPSocket.open(server, port);
    socket.binaryType = "arraybuffer";

That makes no difference.
(Reporter)

Comment 3

3 years ago
Ah, binaryType is readonly.
I've gotten it figured out.
Thanks!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

3 years ago
I have discovered the hard way that this bug applies to 2.1+ even with binary type set to arrayBuffer.
Re-opening.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Updated

3 years ago
Blocks: 878972
(Reporter)

Comment 5

3 years ago
Still not working in 3.0 emulator. (Build ID 20150318010207)
Doesn't work on a flame flashed to the latest nightlies either
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

2 years ago
I bring you good news that will cause great joy for (hopefully) all the fxos-ers in need of an SSH-client: After installing FXOS 2.6 I found it working again \o/

Device: Flame
Platform Version: 45.0a1
Build Identifier: 20151105150203
Tested with App: https://github.com/chuckwagoncomputing/fxos-firemote

Can anyone confirm?

If this is a stable status I'll get rid of Android at last.
Thanks a lot! 

cc https://bugzilla.mozilla.org/show_bug.cgi?id=878972 done
(Reporter)

Comment 8

2 years ago
If anyone can confirm, please do. I don't have a new enough build running to test this and will not for a few days. If someone can confirm before then, I may submit Firemote to marketplace.

Comment 9

2 years ago
Hi David, meanwhile I can confirm that Firemote is also working on a Flame with
  Firefox 2.5
  Platform Version: 44.0a1
  Build Identifier: 20151023030241
which is the normal nightly FOTA version at present.
Again many thanks for Firemote.
/m
(Reporter)

Comment 10

2 years ago
Thanks. I've submitted Firemote to Marketplace.
Based on m's comment 7 and comment 9, and David, the reporter's, comment 10, plus our fairly long-standing unit test at http://searchfox.org/mozilla-central/source/dom/network/tests/test_tcpsocket_client_and_server_basics.js#257 that verifies the full range of binary values, I'm going to close this out as worksforme.  (And the understanding that not using { binaryType: 'arraybuffer' } would absolutely cause the observed problems.)
Status: NEW → RESOLVED
Last Resolved: 3 years agoa year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.