Closed Bug 1117182 Opened 11 years ago Closed 9 years ago

TCPSocket data breaks on NULL character.

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: dave, Unassigned)

References

Details

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.
Like this? socket = navigator.mozTCPSocket.open(server, port); socket.binaryType = "arraybuffer"; That makes no difference.
Ah, binaryType is readonly. I've gotten it figured out. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
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 → ---
Blocks: 878972
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
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
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.
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
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
Closed: 11 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.