build the http_client of lsquic(v2.7.1) to connect to quic-go server, it always failed when do the handshake.

[initlifeinc]

i build lsquic (v2.7.1) and use the http_client to connect to a quic server(quic-go, support draft-23 ,24), it is failed and cannot finish handshake. finally i find when i send handshake packet to server, it seems the final secret keys calc by both side sharekey maybe not the same, i am not sure the real problem. i ask the author of quic-go, his response is the quic-go client can connect to lsquic-server and quic-go can connect to 6 other QUIC implementation.

i also try to use lsquic client to connect other public quic server, it seems can works. so do you have some any other suggestions? Can you try to use lsquic client to connect quic-go? because i am not sure whether the build env or steps are wrong.

[dtikhonov]

Is this a public quic-go server? I can give it a shot.

Note that quic-go has not been participating in the IETF QUIC Interop events lately. quic-go client may be OK, but no one (until you) tested his client against a quic-go server.

[initlifeinc]

ok, i will prepare a quic-go server. and provide a server address to you.

[dtikhonov]

I used the following command:

./http_client -H quic-go.server.com -s 192.119.67.12:6121 -p / -L debug 2>client.out

Looking at the debug output in client.out, I see that the server never sends the response.

My guess is that the problem is with the server, as lsquic client successfully interoped with 10 other implementations during the last Interop event a few weeks ago. You can try using lsquic client against other public access endpoints to check it out.

For example:

[dmitri@ubuntu-dmitri lsquic]$ ./http_client -s www.cloudflare.com -p / -M HEAD | head
HTTP/1.1 200 OK
date: Fri, 06 Dec 2019 04:20:32 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d425709503de3109011b47d5a144b09081575606032; expires=Sun, 05-Jan-20 04:20:32 GMT; path=/; domain=.www.cloudflare.com; HttpOnly
cf-ray: 540b77c73c6ecce2-EWR
age: 4
cache-control: public, s-max-age=30
etag: W/"22f25-qt4FSoW4EhFWFpH4lFiXnfEIhaE"
strict-transport-security: max-age=31536000
vary: Accept-Encoding
[dmitri@ubuntu-dmitri lsquic]$ ./http_client -s www.litespeedtech.com -p / -M HEAD | head
HTTP/1.1 200 OK
x-powered-by: PHP/7.3.5
x-logged-in: False
x-content-powered-by: K2 v2.7.1 (by JoomlaWorks)
content-type: text/html; charset=utf-8
expires: Wed, 17 Aug 2005 00:00:00 GMT
last-modified: Thu, 05 Dec 2019 23:24:26 GMT
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
pragma: no-cache
etag: "6133111-1575588266;;;"
[dmitri@ubuntu-dmitri lsquic]$

[initlifeinc]

ok, i will check again,

[initlifeinc]

above log show the client seems have finished handshake, but server not return response

[dtikhonov]

Yes, that's my conclusion as well.

[litespeedtech]

Closing -- not a bug.

[Zeymo]

@dtikhonov I find some special logic of lsquic length encode.

when quic-go receive handshake frame and parse length after Source Connection ID

234,255,0,0,24,4,116,187,225,87,8,179,143,138,177,169,100,79,165,64,56 SCID len, SCID ,length(64 56), packet number

I can see 64 is the first bytes of length, the two most significant bits of the first byte is 01 means that length has two bytes, then read next byte 56 and really lenght is 56 + 64&(0xff-0xc0) = 56 + 0 = 56

why 56 length need 2 bytes for length encode? 1 byte is enough

when 56 convert to length is 1 bytes for header offset at remote and absolutely mismatch correct offset and occur decryption failed

func VarIntLen(i uint64) protocol.ByteCount {
    if i <= maxVarInt1 { //63
        return 1
    }
    if i <= maxVarInt2 {//16383
        return 2
    }
    if i <= maxVarInt4 {//1073741823
        return 4
    }
    if i <= maxVarInt8 {//4611686018427387903
        return 8
    }
}

Is my wrong , correct me

[Zeymo]

https://github.com/lucas-clemente/quic-go/issues/2259

[initlifeinc]

hi, @dtikhonov ， i have some questions about these two functions. could you help to explain for me. (especially the second question).

Because when i debug lsquic, i find lsquic will reply a packno bits=PACKNO_BITS_1 when send PNS_HSK packet and the packet number is only 3 (i understand that it is also a current way to use 2 bytes to indicate the number 3 in ietf draft, just want to confirm whether it is a special logics or guess here?)

1. what's schedule stream packets means in lsquic?
2. what's guess_packno_bits? why need to guess the packno bits?

enum packno_bits lsquic_send_ctl_packno_bits (lsquic_send_ctl_t *ctl) 
{
    if (lsquic_send_ctl_schedule_stream_packets_immediately(ctl))
        return lsquic_send_ctl_calc_packno_bits(ctl);
    else
        return lsquic_send_ctl_guess_packno_bits(ctl);
 }

enum packno_bits
lsquic_send_ctl_guess_packno_bits (lsquic_send_ctl_t *ctl)
{
    return PACKNO_BITS_1;   /* This is 2 bytes in both GQUIC and IQUIC */
}

[dtikhonov]

@Zeymo writes:

why 56 length need 2 bytes for length encode? 1 byte is enough

It does not need to use 2 bytes. Always using 2 bytes is simply more convenient in lsquic.

[dtikhonov]

@initlifeinc writes:

1. what's schedule stream packets means in lsquic?

When streams are written to, the data is placed into packets. When write occurs in the on_write() callback, these packets are placed into the Scheduled queue immediately. Otherwise, the packets are placed into one of the Buffered queues.

2. what's guess_packno_bits? why need to guess the packno bits?

The difference between the Scheduled and the Buffered queues is that packet numbers are assigned immediately in the former case. In the latter case, the code has to guess how many bits it will need to encode the packet number when the buffered packet is finally scheduled. At the moment, it simply guesses 2 bytes each time (as you observe above).

When packet is created to be scheduled immediately, the packet number length calculation is a bit more involved. This is described in more detail in Section 17.1 of the transport I-D.

[Zeymo]

@dtikhonov writes

It does not need to use 2 bytes. Always using 2 bytes is simply more convenient in lsquic.

Get it

when peer only use minimal varint encoding some error will happen.

quic-go is preparing a fix for this . thx for ur time