I'm an ios programmer
my server gave me h264 data with TCP
but the data is not freindly like this
The startcode (00 00 00 01 or 00 00 01) is not at the start of each response data
So how can i get a whole nalu?
Related
I have setup advertising in bluez using hcitool The device sow up as expected.
The setup is done as follow:
#advertising
sudo hcitool -i hci0 cmd 0x08 0x0008 18 02 01 06 02 0a 00 11 07 9e ca dc 24 0e e5 a9 e0 93 f3 a3 b5 01 00 40 6e 00 00 00 00 00 00 00
#scan response
sudo hcitool -i hci0 cmd 0x08 0x0009 0d 0c 09 6f 6f
#setup advertising interval
sudo hcitool -i hci0 cmd 0x08 0x0006 80 02 c0 03 00 00 00 00 00 00 00 00 00 07 00
#turn advertising on
sudo hcitool -i hci0 cmd 0x08 0x000a 01
After a devie connect the advertising is gone. How kan I keep continuing advertising?
I did a workaround calling sudo hcitool -i hci0 cmd 0x08 0x000a 01 repeatedly.
Another question is how setup the advertising above using the d-bus interface.
ps.
Many info have been found in Bluetooth specification 5.0 (Core_v5.0.pdf), 7.8.5 LE Set Advertising Parameters command p.1321
Most stacks/implementations (including BlueZ) will automatically switch off adverts when a device's state switches from advertising to accepting an incoming connection. The reason for this is that according to the stack Link Layer states (Please see picture below which is available Bluetooth specification v5.1, Vol 6, Part B, Section 1.1: Link Layer States), the state of the device should change from Advertising to Connected as the device cannot be in two different states at the same time.
However, once you are in a connection you can restart your adverts as you have done manually. Please have a look at the answer below for more information:-
Link Layer state for more than one simultaneous connection
I hope this helps.
I'm struggling with extracting application/x-gzip HTTP responses manually because Fiddler can't extract them. For example, my Android device queries https://android.clients.google.com/fdfe/selfUpdate from time to time. The response has Content-Type: application/x-gzip and the body is only 9 bytes long (hex):
0A 03 BA 02 00 2A 02 08 00
According to the following W3C paper: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
However, GZIP should start with hex bytes 1F 8B. And according to GZIP file format, the header is always 10 bytes long so if the response body has only 9 bytes, it can't be stored as a valid GZIP file. If I store it in a file anyway, none of the following extractors can process it: gzip, arclite, 7-Zip, WinRar. As mentioned before, Fiddler can't extract it too.
Perhaps the GZIP 10-byte header was stripped - let's add it. The file contents is now:
1F 8B 08 00 00 00 00 00 00 00
0A 03 BA 02 00 2A 02 08 00
Unfortunately, this doesn't really change anything, none of the extractors mentioned above can process it.
EDIT:
Looking at a few other x-gzip responses from Google servers, the body always starts with 0x0A byte. No other similarity found.
I captured and decrypted an HTTPS request using fiddler. It looks about like this:
CONNECT qwer1234.com:443 HTTP/1.0
User-Agent: Blabla Example/1.0
Host: qwer1234.com:443
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 13 35 55 0B F2 3C 9D A3 A2 C2 E4 3E 66 FA D3 DD E5 15 27 33 F1 E6 CD A5 E0 C4 10 4E 41 67 32 8E
SessionID: empty
Extensions:
renegotiation_info 00
server_name qwer1234.com
status_request 01 00 00 00 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algorithms 00 01 06 07 05 08 03 09 04 03 06 04 04 07 01 09
SessionTicket empty
Ciphers:
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[002F] TLS_RSA_AES_128_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
Is this a special kind of HTTPS request? Why is only half of the request excrypted? What do the random generated numbers mean / what are they for? How would I send this request using a WinHttpRequest? How does it differ from other HTTPS requests?
I'm kind of bad in finding the right places to ask questions like this. Tell me if you think that I should have asked this on a different page and if so, where.
This isn't a HTTPS request at all, it is a CONNECT tunnel through which HTTPS traffic subsequently flows. Client applications first send a CONNECT request to the proxy (like Fiddler) to tell them where to establish a TCP/IP connection to, then after the connection establishes, a HTTPS handshake is performed and the requests are sent.
When showing you the CONNECT tunnel, Fiddler analyzes the parameters and displays them for you to read. The actual HTTPS requests will appear after this tunnel in the Web Sessions list, if and only if you have enabled HTTPS decryption in the Tools > Fiddler Options > HTTPS screen.
I am trying to access a remote webservice from an asp.net application in an iis 6 server to a remote webserver.
As I wasn't able to connect, I used MS Network Monitor to look over what was happening.
This is the TLS progress
2 15:26:31 14.03.2013 0.0000000 yyy.yyy.yyy.yyy XXX.XXX.XXX.XXX TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
3 15:26:31 14.03.2013 0.0312500 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
4 15:26:31 14.03.2013 0.0312500 yyy.yyy.yyy.yyy XXX.XXX.XXX.XXX TLS TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange. Certificate Verify.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
5 15:26:31 14.03.2013 0.0468750 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
6 15:26:31 14.03.2013 0.0781250 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 Encrypted Alert {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
And this is final TLS transaction with the alert
- TlsRecordLayer: TLS Rec Layer-1 Encrypted Alert
ContentType: Encrypted Alert
- Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 18 (0x12)
EncryptedData: Binary Large Object (18 Bytes)
And finaly this is the hex dump for the alert part.
15 03 01 00 12 CE CA A3 1C C9 44 5C AC A2 3C BB 3C F3 F9 8A A6 4F 22
According to http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol I tried to decode the meaning
15 = 21 dec <- always 21
03 01 = major and minor Version
00 12 = lentgh
And now it gets weird. Normaly the next two bytes should be the level and description of the alert. But they make no sense. Beside that, they differ every trace I run. While the front part stays constantly the same.
Any ideas how i can decrypt the alert?
My first thought was that the other side may not allow TLS 1, while IIS 6 only supports TLS 1 (atleast that is what i thougt).
Thanks alot in advanced
The alert itself is encrypted, because the handshake was successful. So before you know what it says, you have to decrypt it - you could use ssldump, in case you have the server's private key.
Found this here: http://www.wireshark.org/lists/ethereal-users/200110/msg00055.html - after I puzzled about the same problem for a while.
This is about ssldump: http://www.rtfm.com/ssldump/
Using Wireshark, you can decrypt everything, in case you have the private key that was used for encryption: http://support.citrix.com/article/ctx116557
I created this small example. I have an EchoServer on Port 8080 and a LogServer on Port 9090 (exemplary in this example). Both are started on the same machine (with Server, which contains the main).
Server started on port 8080
Server started on port 9090
As soon a client -- via telnet -- connects, the EchoServer establishes a connection to the LogServer. Now I am entering a long text, let's say 5000 character (see the long_text in the example), even if bash cannot handle it:
EchoServer Received: 1024
LogServer Received: 1024
EchoServer Received: 2048
LogServer Received: 2048
EchoServer Received: 1025
LogServer Received: 1025
If I enter the text again, I am getting:
EchoServer Received: 2048
LogServer Received: 2048
EchoServer Received: 2049
LogServer Received: 2049
Let's do it again:
EchoServer Received: 3072
EchoServer Received: 1025
LogServer Received: 3072
LogServer Received: 1025
And again:
EchoServer Received: 4096
EchoServer Received: 1
LogServer Received: 4096
LogServer Received: 1
The last time:
EchoServer Received: 4097
LogServer Received: 4097
My observation:
First of all, the data is fragmented. Additionally, each time the fragmends are extended by 1024 bytes (1024,2048,3072,4096,...). I guess the last behavious is because of the TCP slow start.
How can I achive the forwarding to the LogServer without fragmentation, such my text will arrive as one single message? I guess the problem is, how I connect to the LogServer.
[EDIT1]
I changed the logs. It seems, that it's already happening between telnet and the EchoSever. Anyway, I still have the problem in the real environment. The whole message (some Kilobyte) is arriving via WebSockets and the Forwarding to another Connection is fragmented.
[EDIT2]
I did some more research (with wireshark -- the log). I guess it has noting to do with TCP Slow Start. The data (I was sending 4095 times the letter A) arriving on the machine as three correct TCP packets:
Frame 1 (1506 bytes) with 1440 bytes TCP data (41 41 41 ... 41 41 41/HEX)
Frame 2 (1506 bytes) with 1440 bytes TCP data (41 41 41 ... 41 41 41/HEX)
Frame 3 (1283 bytes) with 1217 bytes TCP data (41 41 41 ... 41 0d 0a/HEX)
All 4095 A characters + CRLF arrived as expected.
The EchoServer said:
EchoServer Received: 1024
EchoServer Received: 2048
EchoServer Received: 1025
It also received the 4095 characters + CRLF, but it is different fragmented than the TCP segments (exactly same as the first log above). How can I avoid this Netty behavior?
In non-blocking I/O, there's no practical way to get the number of available bytes in socket receive buffer. Because of that problem, Netty predicts the number of available bytes. It starts from 1024 and then increases the prediction depending the number of read bytes. You can shcnage this behavior by employing a different prediction algorithm.
The default implementation is AdaptiveReceiveBufferSizePredictor and you might want to take a look into its source code to write your own one.
However, no matter what prediction algorithm you choose, you have to keep in mind that TCP/IP is a streaming protocol, which means you can always get messages in a split or merged form. Please refer to the user guide: http://netty.io/docs/stable/guide/html/ (See the 'Dealing with a Stream-based Transport' section.)
You require a FrameDecoder in your pipeline can which assemble bytes from the network into complete frames. In your case I think you need to combine the StringDecoder and DelimiterBasedFrameDecoder. Take a look at the Telnet example and specifically the TelnetServerPipelineFactory