SSL Handshake fails after clienthello - networking

EDIT: I'll leave this as a good example of debugging SSL.
Final analysis: We had a networking issue in which one of our routers was misconfigured for a totally different application causing that router to be running borderline on CPU usage. The first few handshakes didn't pin it... then a subsequent one did and the connection was dropped as the router became overloaded. This presented as an SSL problem when it was really something else entirely.
Take-away: When SSL drops completely in mid connection make sure to check load level of routers in your control as well.
I've been at this for a while so hopefully I can provide an accurate picture.
We have SVN and Git repositories at a third party provider. We noticed that each would hang intermittently with no error given to the screen. In SVN's case the process had to be kill -9ed in Git a ctrl-C would suffice.
Looking into I found that the SSL handshake negotiation was failing. In SVN we would get to the handshake part and ... nothing.
Now, I know we use these repos elsewhere without known issues, so that is the first rabbithole I go down.
This only happens on one datacenter. Not in our whoel network. These repos are fine everywhere, else, but at this one datacenter about 1 in 3ish requests hangs on the SSL handshake.
These same machines can access SSL handshakes without issue everywhere else except this third party provider.
So, I delved into the SSL handshake, and finally landed at:
openssl s_client -msg -debug -state -connect DOMAIN.DOM:443 which stops here:
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x20b94e0 [0x20b9560] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 88 0a 00 73 97 ....8...4.....s.
0010 - 12 69 c9 00 65 29 10 f6-57 00 57 44 e8 0e 3f cf .i..e)..W.WD..?.
0020 - af a0 f9 80 e2 20 98 f0-d2 79 8c 00 00 9e c0 30 ..... ...y.....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$.....".!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.....2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*.&.......=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d ................
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ...../.+.'.#....
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .........g.#.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .....E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 c0 11 .......<./...A..
00b0 - c0 07 c0 0c c0 02 00 05-00 04 00 15 00 12 00 09 ................
00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d ...............m
00d0 - 00 0b 00 04 03 00 01 02-00 0a 00 34 00 32 00 0e ...........4.2..
00e0 - 00 0d 00 19 00 0b 00 0c-00 18 00 09 00 0a 00 16 ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05 ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11 ................
0110 - 00 23 00 00 00 0d 00 20-00 1e 06 01 06 02 06 03 .#..... ........
0120 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02 ................
0130 - 03 03 02 01 02 02 02 03-00 0f 00 01 01 .............
>>> TLS 1.2 Handshake [length 0138], ClientHello
01 00 01 34 03 03 88 0a 00 73 97 12 69 c9 00 65
29 10 f6 57 00 57 44 e8 0e 3f cf af a0 f9 80 e2
20 98 f0 d2 79 8c 00 00 9e c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a c0 22 c0 21 00 a3 00 9f 00 6b 00
6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0
26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 12 c0
08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0
2f c0 2b c0 27 c0 23 c0 13 c0 09 c0 1f c0 1e 00
a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00
45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00
9c 00 3c 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0
02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00
08 00 06 00 03 00 ff 01 00 00 6d 00 0b 00 04 03
00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00
0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00
06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00
01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 0f 00 01 01
SSL_connect:unknown state
And it hangs there. On successful connections the next lines to that debug output should be
read from 0x1735590 [0x173ab70] (7 bytes => 7 (0x7))
0000 - 16 03 03 00 42 02 ....B.
0007 - <SPACES/NULS>
read from 0x1735590 [0x173ab7a] (64 bytes => 64 (0x40))
0000 - 00 3e 03 03 52 fd 41 af-09 0b 96 d6 c4 01 c2 1b .>..R.A.........
0010 - eb e9 23 71 93 a6 1b 78-df 67 17 fe 86 c4 f9 82 ..#q...x.g......
0020 - 53 4f 36 09 00 c0 30 00-00 16 ff 01 00 01 00 00 SO6...0.........
0030 - 0b 00 04 03 00 01 02 00-23 00 00 00 0f 00 01 01 ........#.......
<<< TLS 1.2 Handshake [length 0042], ServerHello
02 00 00 3e 03 03 52 fd 41 af 09 0b 96 d6 c4 01
c2 1b eb e9 23 71 93 a6 1b 78 df 67 17 fe 86 c4
f9 82 53 4f 36 09 00 c0 30 00 00 16 ff 01 00 01
00 00 0b 00 04 03 00 01 02 00 23 00 00 00 0f 00
01 01
SSL_connect:SSLv3 read server hello A
So, as you can see this is way before the handshake is close to done.
From what I can tell, our clients initiate the handshake (cleinthello) and sometimes get silence on the wire.
I've already tried upgrading openssl, with no change. And again, this is only connecting to this one provider out of this one datacenter.
I'm down to some sort of networking issue filtering outgoing SSL traffic in some way, but I have no idea why that would be happening.
Any thoughts on where to go next in the troubleshooting process would be much appreciated. Thanks.
edit: Tried multiple ciphers and can reproduce with all, leading me again to possible network issue.
edit: Similar results with gnutls:
ifx14:/home/cadre/stresler# gnutls-cli -d 9 DOMAIN.DOM
Resolving 'DOMAIN.DOM'...
Connecting to 'X.X.X.X:443'...
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x1a11a60]: Sending extension CERT_TYPE
|<2>| EXT[0x1a11a60]: Sending extension SERVER_NAME
|<3>| HSK[0x1a11a60]: CLIENT HELLO was send [131 bytes]
|<4>| REC[0x1a11a60]: Sending Packet[0] Handshake(22) with length: 131
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a11a60]: Sent Packet[1] Handshake(22) with length: 136

This is old and already answered, but we suffered the same exact issue and the cause was different.
The key was to sniff traffic on our edge router, where we saw ICMP messages to the server (GitHub.com) asking for fragmentation. This was messing the connection, with retransmissions, duplicated ACKs and so.
The ICMP packet had a field, MTU of next hop with a weird value, 1450. The usual value is 1500.
We checked our router and one of the interfaces (an Ethernet tunnel) had this value as MTU, so the router was taking the minumum MTU of all interfaces as next hop. As soon as we removed this interface (it was unused), the SSL handshake started to work again.

As I can see, the client hello has one byte to much on position 00cb: the 0xFF should not be there. So the following bytes data cannot be read correctly...
00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d ...............m
Not sure, but it seems to be a bug in openssl, so a firewall or web proxy ignores the request.

For folks who come across this issue, I created a checklist:
Make sure all TLS versions are enabled in Internet Explorer (This is for testing. You can later disable the unsecure versions once you find out the root cause)
Check the registry keys below to make sure what you set in Internet Explorer is applied at registry level. If there are working and non-working servers, mirror the working server’s settings HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Collect a network trace from the client side. Check if the client and server are agreeing on a cipher suite. If they are not, make sure the client uses the cipher suites the server is trying to use. The Group Policy setting is below Computer Configuration > Administrative Templates > Network > SSL> Configuration Settings > SSL Cipher Suite Order
If the issue sill exists, look for any network device (proxy, firewall, load balancer etc.) in between that might be blocking TLS traffic
Check the website binding in IIS. Make sure the certificate is valid and the port is set to 443
Make sure the port 443 is listened in the server (netstat -an -p TCP | find /I "listening"). More details: Port 80 and 443 are not listened in IIS server
Change the port number to 444 and test website. If it is accessible, it means there is a software blocking or overwriting 443 port. More details
Disable Windows Firewall (If it works, you can enable it back and set up rules accordingly)
Look for any third-party applications such as antivirus or endpoint protection software in the server such as Symantec Endpoint Security and Symantec Data Center Security Server Agent (Based on this document, Security Server Agent uses port 443). Uninstall them (Don’t just disable. Uninstall completely. If it works, you can install them back and configure them accordingly)
Check if there is any Microsoft software that is using port 443. Applications like SQL Server Reporting Services (SSRS) and Windows Admin Center might interfere the port 443. An example
Source: The missing Server Hello in TLS handshake (ERR_SSL_PROTOCOL_ERROR

Well, I had a similar problem. SSL handshake terminated with error right after ClientHello. It turned out the server required stronger ciphers than I had installed so I had to install the Java Cryptography Extension (JCE) (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html).
More interestingly, we had the very same problem on a server and we had the jars for JCE there but some older version so it suffered the same problem. Replacing them with the newest version solved the issue.
BTW, do you know how to get required server ciphers? Or better compare the client and server ciphers? So one would immediately see the mismatch.

Related

Disable client-initiated secure renegotiation in nginx

I use Nginx 1.19.6 and OpenSSL 1.1.1i.
But I checked my server support client-initiated secure renegotiation... (https://www.immuniweb.com/ssl/?id=Ek4FSF6C)
I don't know why my server supports client-initiated secure renegotiation.
Check Code:
openssl s_client -connect gjan.info:443 -msg -tls1_2
Result:
---
R
RENEGOTIATING
>>> ??? [length 0005]
16 03 03 00 f6
>>> TLS 1.2, Handshake [length 00de], ClientHello
01 00 00 da 03 03 cb bf ab b8 6f a1 31 14 2d fb
ad 63 aa d2 15 c6 5d fc 8c 19 fc db 4c 7f 5b d8
f1 f1 fd f3 29 fa 00 00 36 c0 2c c0 30 00 9f cc
a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 01
00 00 7b ff 01 00 0d 0c 1b a5 84 2c 92 28 da 6e
0c 84 5f c4 00 00 00 0e 00 0c 00 00 09 67 6a 61
6e 2e 69 6e 66 6f 00 0b 00 04 03 00 01 02 00 0a
00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 18 00 23
00 00 00 16 00 00 00 17 00 00 00 0d 00 30 00 2e
04 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b
08 04 08 05 08 06 04 01 05 01 06 01 03 03 02 03
03 01 02 01 03 02 02 02 04 02 05 02 06 02
<<< ??? [length 0005]
15 03 03 00 1a
<<< TLS 1.2, Alert [length 0002], warning no_renegotiation
01 64
>>> ??? [length 0005]
15 03 03 00 1a
>>> TLS 1.2, Alert [length 0002], fatal handshake_failure
02 28
547636304368:error:14094153:SSL routines:ssl3_read_bytes:no renegotiation:../ssl/record/rec_layer_s3.c:1560:
Is just ImmuniWeb error or really my web server supported? If supported how can I disable?
It's just immuniweb. Qualys/ssllabs correctly shows
Secure Renegotiation Supported
Secure Client-Initiated Renegotiation No
Insecure Client-Initiated Renegotiation No
The first means the RFC5746 negotiation during handshake works; the second and third mean actual renegotiation initiated by the client fails.
PS: this isn't really a programming question or problem, but as long as others haven't voted to close I won't bother.
It might not be possible to use a setting in nginx to solve this security issue. However, you might refer nginx developers to this answer so they can make proper changes in their codebase. This is NOT just immuniweb as the other answer indicates.
The SSL_OP_NO_RENEGOTIATION option were added in OpenSSL 1.1.1. To make immuniweb give you the same score as we have (A+) you need to set SSL_OP_NO_RENEGOTIATION in order to disable all renegotiation in TLSv1.2 and earlier. This needs to be set where the SSL_CTX is created. You might also need to make additional changes in order to get the wanted scoring.
SSL_CTX *ssl_ctx = SSL_CTX_new(TLS_method());
...
SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_RENEGOTIATION);
Source: SSL_CTX_set_options man 1.1.1

Understanding how DNS queries work at a deeper level

It's currently 04:40 AM and I am stuck on something I simply do not understand. I am trying to look up a domain's nameservers directly by using the DNS protocol. If I send a host -t ns google.com 1.1.1.1 and monitor it with Wireshark, I can see the full query of the DNS query. However, I cannot figure out, why some ASCII characters are used one time, but not another time. Here is an example:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 38 d6 ff 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .8.......P......
0020 01 01 e8 40 00 35 00 24 a0 19 9e f7 01 00 00 01 ...#.5.$........
0030 00 00 00 00 00 00 06 67 6f 6f 67 6c 65 03 63 6f .......google.co
0040 6d 00 00 02 00 01 m.....
In this DNS query, I am looking up the nameservers for google.com. The actual query starts at 06 07.
06 in ASCII is ACK/Acknowledgment.
Now, if we take a look at gmail.com instead:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 37 d7 00 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .7.......P......
0020 01 01 e8 58 00 35 00 23 8f cc 6f e2 01 00 00 01 ...X.5.#..o.....
0030 00 00 00 00 00 00 05 67 6d 61 69 6c 03 63 6f 6d .......gmail.com
0040 00 00 02 00 01 .....
the query starts at 05 67 instead.
05 is ENQ/Enquiry.
Why are they different? If I try to send 06 instead of 05 the DNS server gives me no response but Wireshark tells me:
Unknown extended label
I've seen 05, 06, and 09 so far. 09 is my biggest "wat" of all time, because it's a HT/Horizontal Tab.
Anyone with a lot of DNS knowledge who can help me here? I'm not looking for "just use dig/nslookup/host command". I'm currently trying to research a bit on the DNS protocol, and this is a thing I do not understand.
Good read where I got a lot of help: http://dev.lab427.net/dns-query-wth-netcat.html
For a binary protocols like this, you can't assume each byte corresponds to the matching ASCII character.
Take a look at section 4.1.2 of the DNS RFC (https://www.ietf.org/rfc/rfc1035.txt).
The domain name in a DNS request is broken up into "labels". For each label, the first byte is the length of the label, then the bytes for the string are written.
For your Google.com example, the labels are "google" and "com". The 06 is the number of bytes in the first label. This is followed by the bytes for "google". Then the 03 is the number of bytes in the "com" label. After the "com" bytes, the 00 byte is the NULL label to mark the end.

TCP handshaking fails - what's wrong with the server's reply?

I'm building a server with the ENC28J60 chip and a PIC18F4620. The chip is connected to my PC via ethernet. Currently, I'm trying to set up the TCP connection over which I'll build an HTTP connection later on. I have never worked with TCP before.
I'm implementing TCP on the embedded device only, not on the PC.
After the needed ARP requests and replies are sent, I open up my browser, type the IP address of the chip in and press enter. In wireshark, I see a TCP request1 with the SYN flag is made. I believe the SYN flag indicates a new handshake initiation, so that's good, isn't it?
My chip's reply1 has the SYN and ACK flag enabled. From what I understood, that is the correct way to reply to a SYN-flagged request. The acknowledgement number the chip sends is correct. Now, the chip should get a reply with the ACK flag enabled, according to the same reference.
However, the process seems to start over: the PC sends the exact same packet1 as its first packet, only the 'identification' has changed. I programmed my chip to stop replying when it keeps getting SYN requests on the same socket, so this is the end of the transmission, in the browser I read that the server can't be reached.
This connection is made on four sockets at the same time, all with the same result.
As I'm just using my PC as client (and there's nothing wrong with my ethernet port / driver), the problem must be something with the server and thus with the second packet.
What's wrong with the second packet? Wireshark doesn't mark anything as incorrect, but the client doesn't send an ACK.
1: Here are the packets wireshark picks up:
Client: 3085 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
0000 00 13 d4 c6 53 16 00 1a a0 03 c7 21 08 00 45 00 ....S... ...!..E.
0010 00 40 de 48 40 00 80 06 9a e1 c0 a8 00 01 c0 a8 .#.H#... ........
0020 00 3c 0c 0d 00 50 88 ab 7e 18 00 00 00 00 b0 02 .<...P.. ~.......
0030 ff ff a1 4f 00 00 02 04 05 b4 01 03 03 03 01 01 ...O.... ........
0040 08 0a 00 00 00 00 00 00 00 00 01 01 04 02 ........ ......
Server: 80 > 3085 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8
0000 00 1a a0 03 c7 21 00 13 d4 c6 53 16 08 00 45 00 .....!.. ..S...E.
0010 00 30 88 10 40 00 7f 06 f2 29 c0 a8 00 3c c0 a8 .0..#... .)...<..
0020 00 01 00 50 0c 0d 00 00 00 01 88 ab 7e 19 70 12 ...P.... ....~.p.
0030 ff ff ef 77 00 00 02 04 05 b4 01 03 03 03 ...w.... ......
Client: 3085 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
0000 00 13 d4 c6 53 16 00 1a a0 03 c7 21 08 00 45 00 ....S... ...!..E.
0010 00 40 de 6f 40 00 80 06 9a ba c0 a8 00 01 c0 a8 .#.o#... ........
0020 00 3c 0c 0d 00 50 88 ab 7e 18 00 00 00 00 b0 02 .<...P.. ~.......
0030 ff ff a1 4f 00 00 02 04 05 b4 01 03 03 03 01 01 ...O.... ........
0040 08 0a 00 00 00 00 00 00 00 00 01 01 04 02 ........ ......
All this happens similarly with three other client's source ports.
For comparison, I made a request to google.com and here is the TCP stream:
Client: 49562 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
0000 00 1a a0 03 c7 21 08 9e 01 30 ee 69 08 00 45 00 .....!.. .0.i..E.
0010 00 34 32 3f 40 00 80 06 38 ab c0 a8 00 3c 4a 7d .42?#... 8....<J}
0020 84 78 c1 9a 00 50 74 b8 31 9c 00 00 00 00 80 02 .x...Pt. 1.......
0030 20 00 56 f7 00 00 02 04 05 b4 01 03 03 08 01 01 .V..... ........
0040 04 02 ..
Server: 80 > 49562 [SYN, ACK] Seq=0 Ack=1 Win=62920 Len=0 MSS=1430 SACK_PERM=1 WS=64
0000 08 9e 01 30 ee 69 00 1a a0 03 c7 21 08 00 45 00 ...0.i.. ...!..E.
0010 00 34 9e e3 00 00 2e 06 5e 07 4a 7d 84 78 c0 a8 .4...... ^.J}.x..
0020 00 3c 00 50 c1 9a f4 5e 12 bc 74 b8 31 9d 80 12 .<.P...^ ..t.1...
0030 f5 c8 7a 22 00 00 02 04 05 96 01 01 04 02 01 03 ..z".... ........
0040 03 06 ..
Client: 49562 > 80 [ACK] Seq=1 Ack=1 Win=65536 Len=0
0000 00 1a a0 03 c7 21 08 9e 01 30 ee 69 08 00 45 00 .....!.. .0.i..E.
0010 00 28 32 49 40 00 80 06 38 ad c0 a8 00 3c 4a 7d .(2I#... 8....<J}
0020 84 78 c1 9a 00 50 74 b8 31 9d f4 5e 12 bd 50 10 .x...Pt. 1..^..P.
0030 01 00 af 9e 00 00 00 00 00 00 00 00 ........ ....
I used text2pcap to load your capture into wireshark.
If you enable TCP checksum validation and absolute sequence numbers, you will see a bad TCP checksum in your chip’s SYN-ACK packet.
Also, the chip starting at absolute sequence number 0 is very weak.

What is this bittorrent network flow? [closed]

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I've recorded some network traffic in my home that only appear up while running BitTorrent or uTorrent.
I've been reading the bittorrent protocol descriptions, but I am stuck trying to figure out a particular network flow.
Can someone help me identify what the following bittorrent network traffic is exactly?
It lasts quite a long time, even after stopping downloads.
All packets are in one direction - from my local machine running Bittorrent to a remote machine.
Here is data payload of one packet (copied from Wireshark):
00000000 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000010 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000020 20 5a 01 45 bd 13 b1 65 01 04 44 4a e7 d5 04 04 Z.E...e ..DJ....
00000030 01 00 00 00 05 02 ea cf ........
All the packets in the network flow are similar, here are two more:
00000038 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000048 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000058 20 5a 01 45 bd 13 b1 65 01 04 08 8e 35 9f 04 04 Z.E...e ....5...
00000068 01 00 00 00 05 02 ea cf ........
00000070 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000080 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000090 20 5a 01 45 bd 13 b1 65 01 04 12 3e ba 6c 04 04 Z.E...e ...>.l..
000000A0 01 00 00 00 05 02 ea cf ........
These bittorrent packets are typically several seconds apart, and this flow seems to go on indefinitely. Which one of the bittorrent protocols describes this network flow?
I just sent a response to you on our mailing list, but I'm gonna post here too in case anyone else stumbles across it and finds it useful.
They're Teredo packets (with no payload). Wireshark can decode these
but it doesn't do so without coercion.
http://en.wikipedia.org/wiki/IPv6_packet
http://en.wikipedia.org/wiki/Teredo_tunneling
One of your packets dissected:
IP Version: 6
Traffic Class: 0 0
Flow Label: 0 00 00
Payload Length: 00 00
Next Header: 3b (indicates that there is no payload present)
Hop Limit: 15
Source: 20 01 00 00 9d 38 6a b8 04 b9 18 bf 9c 90 d8 81
Destination: 20 01 00 00 9d 38 6a b8 20 5a 01 45 bd 13 b1 65
The source and destination also encode the source and destination
public ipv4 addresses and ports.
The hop-by-hop options header (in type-length-value format) follows in
this case. The possible types can be found here:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
So we have this:
01 04: c3 ae 60 38 ("PadN", random bytes)
04 04: 01 00 00 00 ("Tunnel Encapsulation Limit")
05 02: ea cf ("Router Alert")
No clue what the value of the router alert field is here. I would
expect it to be listed here:
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xml
But it looks like either that's out of date or the Teredo
implementation you're using is doing something non-standard (or
there's something I've missed).
Anyways, these are clearly keep-alive packets. We're not directly
triggering them in the client as far as I know. I believe they're sent
by your Teredo driver to keep your tunnels open.

GPRS PPP connect failture during LCP negotiation

I did some work to transplant TCP/IP stack to MCU. Through GPRS, MCU can connect internet.
However, I met with some trouble during LCP negotiation.The following is my solution referring networking material
In order to make MCU PPP simpler.The LCP option request will be respond with rejection.
Server:7e ff 03 c0 21 01 01 00 14 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 54 06 7e
MCU:7e ff 03 c0 21 04 01 00 04 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 69 78 7e
A authentication request is expected in the second step. But i get a none LCP option request.
    
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
    
This means server forces MCU to start LCP negotiation.I am missing.
I send a authentication option request to server so that forcing server to start authentication option negotiation.Server respond me two packets.One is a ACK packet for authentication request.The another still is the none LCP option.
MCU:7e ff 03 c0 21 01 05 00 08 03 04 C0 23 ac 56 7e
Server:7e ff 03 c0 21 02 05 00 08 03 04 C0 23 bd 34 7e
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
After several "none option" request, The negotiation over. What should I do? I am l
(My english is not good .I hope you can understand my means.)
When you respond with Configure-Reject when modem sends Configure-Request. Then modem will send a new modified Configure-Request. See RFC1661 chapter 6.4.
So you should respond with Configure-Ack when Configure-Request contains suitable values for you. So you should send Configure-Ack after the second Configure-Request.

Resources