http_client can't get html page from caddy server about lsquic HOT 12 CLOSED

As I said in another closed thread before I experience the same issue of not getting a response using windows 10 in both ipv4 and ipv6.

from lsquic.

@somanybut, thank you for the report. The log messages you include only describe the beginning of the session -- I don't know whether you get any packets back. Do you get any response packets?

Also, is your bug report Caddy-specific? That is, can you fetch an index from a different web server (e.g. www.google.com or www.litespeedtech.com?)

(The log message time display has been fixed in 560db45.)

from lsquic.

I try to visit www.litespeedtech.com, chrom is ok, but http_client can't get reponse from server, the same as to visit my Caddy server.

...
-1:-1:-1.522 [DEBUG] [QUIC:1113064085529127296] event: generated STREAM frame: stream 1, offset: 0,size: 1024, fin: 0
-1:-1:-1.527 [DEBUG] [QUIC:1113064085529127296-1] stream: flushed to or past required offset 1024
-1:-1:-1.529 [DEBUG] [QUIC:1113064085529127296] pacer: pacer_packet_scheduled: replenish tokens: 10
-1:-1:-1.532 [DEBUG] [QUIC:1113064085529127296] pacer: pacer_packet_scheduled: tokens: 9
-1:-1:-1.537 [DEBUG] [QUIC:1113064085529127296] sendctl: lsquic_send_ctl_can_send: n_out: 1370 (unacked_retx: 0, out: 0); cwnd: 46720
-1:-1:-1.542 [DEBUG] [QUIC:1113064085529127296] pacer: pacer_can_schedule: 1
-1:-1:-1.544 [DEBUG] engine: incref conn 1113064085529127296, 'H' -> 'HO'
-1:-1:-1.548 [DEBUG] engine: decref conn 1113064085529127296, 'HOT' -> 'HO'
-1:-1:-1.552 [DEBUG] [QUIC:1113064085529127296] pacer: intertick estimate: 0; real value: 0; error:0
-1:-1:-1.557 [DEBUG] [QUIC:1113064085529127296] pacer: pacer_can_schedule: 1
-1:-1:-1.560 [DEBUG] handshake: lsquic_enc_session_encrypt: hsk_state: 0
-1:-1:-1.562 [DEBUG] engine: encrypted packet 1; plaintext is 1358 bytes, ciphertext is 1370 bytes
-1:-1:-1.564 [DEBUG] engine: batched packet 1 for connection 1113064085529127296
-1:-1:-1.570 [DEBUG] engine: batched all outgoing packets for conn 1113064085529127296
-1:-1:-1.572 [DEBUG] engine: packets out returned 1 (out of 1)
-1:-1:-1.574 [DEBUG] [QUIC:1113064085529127296] event: sent packet 1, size 1370, frame types: STREAM PADDING
-1:-1:-1.578 [DEBUG] [QUIC:1113064085529127296] sendctl: packet 1 has been sent (frame types: STREAM PADDING)
-1:-1:-1.586 [DEBUG] [QUIC:1113064085529127296] sendctl: set retx alarm to 27226771314, which is 150000 usec from now, mode RETX_MODE_HANDSHAKE
-1:-1:-1.590 [DEBUG] engine: decref conn 1113064085529127296, 'HO' -> 'H'
-1:-1:-1.593 [DEBUG] engine: send_packets_out: sent 1 packet
-1:-1:-1.595 [DEBUG] [QUIC:1113064085529127296] sendctl: lsquic_send_ctl_can_send: n_out: 1370 (unacked_retx: 1370, out: 0); cwnd: 46720
-1:-1:-1.603 [DEBUG] [QUIC:1113064085529127296] pacer: pacer_can_schedule: 1
-1:-1:-1.605 [DEBUG] engine: incref conn 1113064085529127296, 'H' -> 'HT'
-1:-1:-1.608 [DEBUG] engine: incref conn 1113064085529127296, 'HT' -> 'HTA'

from lsquic.

command: http_client -H www.litespeedtech.com -p / -L debug

from lsquic.

@somanybut, you need to use -s option to specify IP address and port number.

from lsquic.

I think the way to figure this out is to see whether the QUIC packets make it from the client to the server. On your Windows machine (client), you can use Wireshark to see whether the packets are sent; on the Ubuntu machine (server), use Wireshark or tcpdump to see whether the QUIC packets are received.

from lsquic.

So let me give you some data on this:
I switch to a Ubuntu Dual boot. I also don't get a response from the google servers. I tested it with both my local lan connection and my mobile phone connection (via Wifi hotspot) so connection shouldn't be the problem.
I also tried connecting to www.litespeedtech.com where I indeed got an answer from the server although most of it was still encrypted in the console:

(Top 3 commands)

In and outcoming packets with wireshark for google ipv4:

Google ipv6:

and litespeed tech ipv4

Also I wanted to ask if Port 443 really is the correct one since google quic is not using tls right now.
Wiki: "443: HTTP Secure (HTTPS) HTTP over TLS/SSL"

from lsquic.

The response from www.litespeedtech.com is not encrypted: it is compressed (see the content-encoding: gzip header). The fact that you get a QUIC reply shows that the library works.

In the second screenshot, one can see that no QUIC responses come back from 74.125.22.106. I just tested with this IP address and it works for me -- I get a response. Try using the IP address of www.google.com where you are -- it may be different. For example, run nslookup www.google.com.

from lsquic.

Indeed the problem was the different ip adress in my region:

Thanks for your help!
You might want to add this as a small note in the examples.txt

from lsquic.

Excellent.

You might want to add this as a small note in the examples.txt

Feel like making a pull request? 😃

from lsquic.

Sure. I tried to make one. Let me know if it worked.

from lsquic.

Closing: no further comment by the original reporter on the reported issue for over a month.

from lsquic.