Installing polars-hash without rust installed

Tried installing the package with poetry add polars-hash and got this error message:
ChefBuildError

  Backend subprocess exited when trying to invoke build_wheel

  Running `maturin pep517 build-wheel -i /var/folders/1r/_9zlpd3x12d058sc8zm5lt700000gq/T/tmponxht39c/.venv/bin/python --compatibility off`
  💥 maturin failed
    Caused by: Cargo metadata failed. Do you have cargo in your PATH?
    Caused by: No such file or directory (os error 2)
  Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/var/folders/1r/_9zlpd3x12d058sc8zm5lt700000gq/T/tmponxht39c/.venv/bin/python', '--compatibility', 'off'] returned non-zero exit status 1

  at ~/Library/Application Support/pypoetry/venv/lib/python3.9/site-packages/poetry/installation/chef.py:147 in _prepare
      143│
      144│                 error = ChefBuildError("\n\n".join(message_parts))
      145│
      146│             if error is not None:
    → 147│                 raise error from None
      148│
      149│             return path
      150│
      151│     def _prepare_sdist(self, archive: Path, destination: Path | None = None) -> Path:

Note: This error originates from the build backend, and is likely not a problem with poetry but with polars-hash (0.4.2) not supporting PEP 517 builds. You can verify this by running 'pip wheel --use-pep517 "polars-hash (==0.4.2)"'.

@ElliotSteene-Ki which OS etc. do you use?

M1 Mac Pro 2020 - Sonoma 14.2.1

FYI I didn't have rust or cargo installed. I've installed them and then tried to install maturin but got an error with that too

I'll put in a fix tonight, Marco already pinged me in another issue what I need to do

@ElliotSteene-Ki can you check the 0.4.3 release in an hour or so?

@ion-elgreco - Thanks! successfully installed!


Moonlight Novels error when downloading

Source information
Moonlight Novels version 1.1.2 (also novelupdate version 0.7.3 when downloading from moonlight novels)
Steps to reproduce

Download Moonlight Novels plugin
Open it and add any novel into library
Download unread chapters

Expected behavior
The chapter should be downloaded
Actual behavior
The chapter is not downloaded, the error i got is "DOWNLOAD_CHAPTER Expected URL scheme 'http' or 'https' but was 'data'
LNReader version
2.0.0 (beta 2)
Android version
Android 14
Other details
There doesn't seem to be a problem with ratelimit, but the weird thing is, if there is a novel with 30 chapters, then there are some chapter that can be downloaded and some that can't be downloaded.
And on the other case with other novel that has 20-30 chapters, all the chapters can't be downloaded.
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 1.1.19.
[X] I have updated all installed extensions.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

Can't reproduce, try to make a backup (Google drive recommended) and unintalle the app

I uninstalled the app, then reinstall from :
https://github.com/LNReader/lnreader/releases/download/v2.0.0-beta.2/lnreader-v2.0.0-beta.2.apk
But i still got the same error Expected URL scheme 'http' or 'https' but was 'data'
The novel i'm trying to download from Moonlight Novels is Ghost Story Club.

Oh now it is fixed by downloading the latest action build :
https://github.com/LNReader/lnreader/actions/runs/10003215907
The problem only occuring on the apk from https://github.com/LNReader/lnreader/releases/download/v2.0.0-beta.2/lnreader-v2.0.0-beta.2.apk

Fixed by downloading the latest action build.


Constructing the DRR problem

Hi, thank you very much for your open-source code. I am very interested in your work. Recently, I encountered a few confusions while running the code:
1 For example, when constructing the initial translation, why is by set to 850? translations = torch.tensor([[0.0, 850.0, 0.0]], device=device)
2 Is the coordinate system of the volume data LSP?
3 If I crop a section of L4 vertebra with dimensions (302, 264, 56) from a CT scan with dimensions (512, 512, 245) as the volume data, how should I set the initial posture? Is this posture based on the coordinate system of the volume data?
4 In this situation, do I need to set the principal point offset?

Hi @linquanxu ,

For the SE(3) parameterization used in the example ("euler_angles" with ordering "ZXY"), the translation y=850.0 corresponds to the source to detector distance. That is, how far the is X-ray source from the isocenter of the volume. Here, y=850.0 means the X-ray source is 850 mm from the center of the chest CT.
The coordinate system is defined by the affine matrix of the volume.
Depends on what view you want, but yes, the coordinate system is based on the volume's affine.
You only need a principal point offset if your C-arm images were acquired with an offset. Some detector planes can move independent of the source. If your images were acquired with that setting, you need the offset. Otherwise, you can leave x0 = y0 = 0.

Hi @eigenvivek ，
Thank you for your prompt response. I encountered a case of DRR registration failure, and I am seeking further assistance.

I used TotalSegmentator to segment the spine (L1-L5 and T12) from the 3D CT DICOM data. The size of the CT data is (512, 512, 245).

I cropped out a section of the spine, such as L4. The size after cropping is (302, 264, 56).

I collected the corresponding 2D X-ray images of the patient and segmented L4.

4 I used the 2D X-ray as the ground truth for DRR registration. The initial configuration and some parameters are as follows.
The registration results are as follows:

SDD = 1085.6
HEIGHT = 300
DELX = 0.373

true_params = {
    "sdr": SDD,
    "alpha": 0.0,
    "beta": 0.0,
    "gamma": 0.0,
    "bx": 0.0,
    "by": 595.0,
    "bz": 0.0,
}

lr_rotations=5e-1,
lr_translations=1e-1,

Why are the images generated by DRR so blurry?
Based on your experience, could you please advise if there are any aspects of my experimental steps or parameter settings that could be further optimized?

A few things stand out:

Are you sure the intrinsic parameters (sdd, height, delx`) are correct? Those need to match the X-ray exactly (and can be read from a DICOM header). They don't necessarily look right to me.
You're trying to register a lateral view, but your initial view for the DRR is a frontal view. That's a large gap for most registration algorithms to bridge. You could start with alpha = -torch.pi / 2.
Your lr_rotations is too high. As a rule of thumb, I usually set it to 2-3 orders of magnitude less than the lr_translations.
The degree of blurriness of a DRR is tied to the resolution of the CT. If the CT is low res, the DRR is low res, no matter how big you make the DRR detector size. One thing you can try is setting renderer="trilinear" - I've noticed it's usually less aliased than renderer="siddon" for low-resolution CTs.

@eigenvivek
Thank you for your patient explanation. I have a few more questions.
1 Since I am using cropped volume data to render DRR, there is an offset between the center of the cropped data and the original volume data. Will this affect the generation of DRR? How can I ensure that the crop volume data is within the scan range of the light source?
2 Through continuous iteration between the DRR and the real X-ray, an optimal camera pose is generated. Once we have this optimal camera pose, does the DRR image rendered with this pose need further alignment with the real X-ray image?
3 How can I find the coordinates of a point on the DRR image rendered with the optimal camera pose in the CT volume data? Are there any relevant tutorials I can refer to?

As long as you keep track of the affine matrix of the cropped volume, they'll be lined up. The 3D geometry functions can help you quickly verify that your camera is located in the right place.
No, once you've run iterative optimization, the optimized camera pose is final.
If you want to project a 3D point onto the image plane of a 2D detector plane, you can use drr.perspective_projection.

Thank you very much for your help. I will close this issue for now. This is an amazing piece of work and worth further study. If I encounter any problems in the future, I will seek your guidance again.


How can this function return null?

https://github.com/b-fuze/deno-dom/blob/ee4e7d268f75fcf61b2d03679ef5f52b2aca5ff3/src/dom/dom-parser.ts#L17
Just curious how can it be null?
It will fail earlier, with other error.

@pihentagy good point, I have no idea why its signature says that it can return null... I thought that I might have found something in the spec saying so, but just seems like a mistake on my part. I resolved that in 3f6ca910d3c17231f7a3cfdf06979af468dda2f4

Thanks, that was quick. And needed a lot of test changes.
What is your release strategy (so when can one expect next release)?

I'm not following any particular release strategy currently since my updates are so sporadic. Probably sometime today or tomorrow I'll make a new release

As part of #164 I've already released this change in v0.1.47 to both deno.land/x and JSR so closing this


proxy-jump error

Hello,
in the documentation I saw that the ssh ProxyJump option is implemented. I was testing this, but I get an error and could not figure out so far where the problem is.
I can connect to both hosts directyl just fine. But when I specify -proxy-jump, it does not work.
◆ ssh3 git:(main) ✗ ❯❯❯ ./ssh3 -insecure -pubkey-for-agent ~/.ssh/id_ed25519.pub -forward-agent -proxy-jump<EMAIL_ADDRESS>-v<EMAIL_ADDRESS>5:15PM DBG version francoismichel/ssh3 0.1.7
5:15PM DBG no OIDC config file specified, use default file: /Users/marco/.ssh3/oidc_config.json
5:15PM DBG /Users/marco/.ssh3/oidc_config.json does not exist
5:15PM DBG dialing QUIC host at <IP_ADDRESS>:443
5:15PM DBG QUIC handshake complete
5:15PM DBG try ssh-agent-based auth
5:15PM DBG we only try the first specified auth method for now
5:15PM DBG try the following Identity: agent-identity
5:15PM DBG establish conversation with the server
5:15PM DBG send CONNECT request on URL https://<IP_ADDRESS>:443/ssh3?user=pi, User-Agent="SSH 3.0 francoismichel/ssh3 0.1.7 experimental_spec_version=alpha-00"
5:15PM DBG got response with 200 OK status code
5:15PM DBG server has valid version "SSH 3.0 francoismichel/ssh3 0.1.7 experimental_spec_version=alpha-00" (protocol version = 3.0_alpha-00, software version = francoismichel/ssh3 0.1.7)
5:15PM DBG start UDP forwarding from <IP_ADDRESS>:0 to <IP_ADDRESS>:443
5:15PM DBG started proxy jump at <IP_ADDRESS>:53179
5:15PM DBG dialing QUIC host at <IP_ADDRESS>:53179
5:15PM ERR could not establish client QUIC connection: timeout: no recent network activity
5:15PM ERR could not setup transport for client: %!s(<nil>)

If I capture packets on the jump host towards the destination, I do not see a single packet leaving.
Am I specifying something wrong? Or is there an even higher debug level that I can enable? There is no error on the proxy server side.

Hi!
It might be QUIC/H3 datagram problem. Previous quic-go versions did not enable quic-in-quic forwarding due to their allowed datagram size. What is the version on the server ? If it's an old one, that may be the reason.
If it's before v0.1.7, I suggest you to update the server and try again. If it's v0.1.7, then it's either a network MTU problem or a bug (a bug seems more likely to me).
You can add quic-level debug logging by setting the QUIC_GO_LOG_LEVEL=debug environment variable, but be aware that you'll be flooded with quite a lot of logging. :-)

Server is 0.1.7. It is basically a git clone of the main branch.
Both servers are started like this and output looks the same.
root@nightowl ~/g/ssh3 (main)# QUIC_GO_LOG_LEVEL=debug SSH3_LOG_LEVEL=debug ./ssh3-server -cert cert.pem -key cert.key -url-path /ssh3 -v
password login is disabled
5:50PM DBG version francoismichel/ssh3 0.1.7
Server started, listening on [::]:443/ssh3
5:50PM INF Server started, listening on [::]:443/ssh3
2024/02/22 17:50:24 Increased receive buffer size to 4096 kiB
2024/02/22 17:50:24 Increased send buffer size to 4096 kiB
2024/02/22 17:50:24 Setting DF for IPv4 and IPv6.
2024/02/22 17:50:24 Activating reading of ECN bits for IPv4 and IPv6.
2024/02/22 17:50:24 Activating reading of packet info for IPv4 and IPv6.
2024/02/22 17:50:24 server Listening for udp connections on [::]:443
2024/02/22 17:50:26 Tracking 0 connection IDs and 0 reset tokens.

Yes, QUIC_GO_LOG_LEVEL spits out a lot on both sides. But nothing easy readable or obvious. Seems all packets related what it tries to send.
I can add both server and client here if you want.

I would be interested to see the client's full log with QUIC log included.
Also, what's the network MTU between your client and the server ? QUIC needs at lease 1200 bytes of UDP payload for their initial packet but quic-go will stuff initial packets with 1232 (ipv6)  or 1252 (ipv4) bytes. That amount will be increased by a little with proxy jump due to encapsulation (the initial packet will be encapsulated in an HTTP/3 datagram). That could amount to around 1308 bytes for the full encapsulated UDP payload, so there may be some networks that do not support that. Most network should support it though, but we never know. If the problem is the MTU, solving it would require quic-go to not stuff their initial packets that much.

It is all local ethernet and MTU is 1500. If I look in Wireshark at a packet capture, I see a few QUIC packets where the frame length is between 1394-1481. For other quic traffic like to youtube, it is always under 1300.
The actual highest quic packet length is 1439 for the 1481 frame length.
I will add the full client quic debug into the next post. Also a screenshot from Wireshark. I can also upload the packet capture, you want.

client quic debug logs.
marco@loop ~/M/g/p/ssh3 (main)> QUIC_GO_LOG_LEVEL=debug SSH3_LOG_LEVEL=debug ./ssh3 -insecure -pubkey-for-agent ~/.ssh/id_ed25519.pub -forward-agent -proxy-jump<EMAIL_ADDRESS><EMAIL_ADDRESS>1:53PM DBG version francoismichel/ssh3 0.1.7
1:53PM DBG no OIDC config file specified, use default file: /Users/marco/.ssh3/oidc_config.json
1:53PM DBG /Users/marco/.ssh3/oidc_config.json does not exist
1:53PM DBG dialing QUIC host at <IP_ADDRESS>:443
2024/02/23 13:53:44 Increased receive buffer size to 2048 kiB
2024/02/23 13:53:44 Increased send buffer size to 2048 kiB
2024/02/23 13:53:44 Setting DF for IPv6.
2024/02/23 13:53:44 Activating reading of ECN bits for IPv6.
2024/02/23 13:53:44 Activating reading of packet info bits for IPv6.
2024/02/23 13:53:44 client Starting new connection to <IP_ADDRESS> ([::]:58045 -> <IP_ADDRESS>:443), source connection ID (empty), destination connection ID 653eb4fd3228e5d212681248, version v1
2024/02/23 13:53:44 Adding connection ID (empty).
2024/02/23 13:53:44 client Not doing 0-RTT. Has sealer: false, has params: false
2024/02/23 13:53:44 client -> Sending packet 0 (1252 bytes) for connection 653eb4fd3228e5d212681248, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 653eb4fd3228e5d212681248, SrcConnectionID: (empty), Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 251, Offset + Data length: 251}
2024/02/23 13:53:44 client Parsed a coalesced packet. Part 1: 131 bytes. Remaining: 1121 bytes.
2024/02/23 13:53:44 client <- Reading packet 0 (131 bytes) for connection (empty), Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: (empty), SrcConnectionID: bf8d82eb, Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 117, Version: v1}
2024/02/23 13:53:44 client Received first packet. Switching destination connection ID to: bf8d82eb
2024/02/23 13:53:44 client 	<- &wire.AckFrame{LargestAcked: 0, LowestAcked: 0, DelayTime: 0s}
2024/02/23 13:53:44 client 	newly acked packets (1): [0]
2024/02/23 13:53:44 client 	updated RTT: 55.306874ms (σ: 27.653437ms)
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 0, Data length: 90, Offset + Data length: 90}
2024/02/23 13:53:44 client Installed Handshake Write keys (using TLS_AES_128_GCM_SHA256)
2024/02/23 13:53:44 client Installed Handshake Read keys (using TLS_AES_128_GCM_SHA256)
2024/02/23 13:53:44 client 	Queueing ACK because the first packet should be acknowledged.
2024/02/23 13:53:44 client Parsed a coalesced packet. Part 2: 1121 bytes. Remaining: 0 bytes.
2024/02/23 13:53:44 client <- Reading packet 0 (1121 bytes) for connection (empty), Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: (empty), SrcConnectionID: bf8d82eb, PacketNumber: 0, PacketNumberLen: 2, Length: 1108, Version: v1}
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 0, Data length: 1086, Offset + Data length: 1086}
2024/02/23 13:53:44 client Processed Transport Parameters: &wire.TransportParameters{OriginalDestinationConnectionID: 653eb4fd3228e5d212681248, InitialSourceConnectionID: bf8d82eb, InitialMaxStreamDataBidiLocal: 524288, InitialMaxStreamDataBidiRemote: 524288, InitialMaxStreamDataUni: 524288, InitialMaxData: 786432, MaxBidiStreamNum: 100, MaxUniStreamNum: 100, MaxIdleTimeout: 30s, AckDelayExponent: 3, MaxAckDelay: 26ms, ActiveConnectionIDLimit: 4, StatelessResetToken: 0xe19484b9c0eccd22973429975607e528, MaxDatagramFrameSize: 16383}
2024/02/23 13:53:44 client 	Queueing ACK because the first packet should be acknowledged.
2024/02/23 13:53:44 client -> Sending packet 1 (1252 bytes) for connection 653eb4fd3228e5d212681248, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: bf8d82eb, SrcConnectionID: (empty), Token: (empty), PacketNumber: 1, PacketNumberLen: 2, Length: 1238, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 0, LowestAcked: 0, DelayTime: 0s}
2024/02/23 13:53:44 client <- Reading packet 1 (1252 bytes) for connection (empty), Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: (empty), SrcConnectionID: bf8d82eb, PacketNumber: 1, PacketNumberLen: 2, Length: 1239, Version: v1}
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 1086, Data length: 1216, Offset + Data length: 2302}
2024/02/23 13:53:44 client -> Sending packet 0 (36 bytes) for connection 653eb4fd3228e5d212681248, Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: bf8d82eb, SrcConnectionID: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 23, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 1, LowestAcked: 0, DelayTime: 0s}
2024/02/23 13:53:44 client Dropping Initial keys.
2024/02/23 13:53:44 client <- Reading packet 2 (1252 bytes) for connection (empty), Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: (empty), SrcConnectionID: bf8d82eb, PacketNumber: 2, PacketNumberLen: 2, Length: 1239, Version: v1}
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 2302, Data length: 1216, Offset + Data length: 3518}
2024/02/23 13:53:44 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:44 client Parsed a coalesced packet. Part 1: 711 bytes. Remaining: 98 bytes.
2024/02/23 13:53:44 client <- Reading packet 3 (711 bytes) for connection (empty), Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: (empty), SrcConnectionID: bf8d82eb, PacketNumber: 3, PacketNumberLen: 2, Length: 698, Version: v1}
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 3518, Data length: 675, Offset + Data length: 4193}
2024/02/23 13:53:44 client Installed 1-RTT Write keys (using TLS_AES_128_GCM_SHA256)
2024/02/23 13:53:44 client Installed 1-RTT Read keys (using TLS_AES_128_GCM_SHA256)
2024/02/23 13:53:44 client 	Queueing ACK because packet 2 packets were received after the last ACK (using initial threshold: 2).
2024/02/23 13:53:44 client <- Reading packet 0 (98 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: (empty), PacketNumber: 0, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	<- &wire.NewConnectionIDFrame{SequenceNumber: 3, ConnectionID: 54693181, StatelessResetToken: 0x2f72cd78d0ce8248eb396dc513a6ffc4}
2024/02/23 13:53:44 client 	<- &wire.NewConnectionIDFrame{SequenceNumber: 2, ConnectionID: a057315a, StatelessResetToken: 0xf606ab1ab7aee2749208c9744b497c4a}
2024/02/23 13:53:44 client 	<- &wire.NewConnectionIDFrame{SequenceNumber: 1, ConnectionID: 10843ef7, StatelessResetToken: 0x3269ae820a23b77f270ef362c7a12e87}
2024/02/23 13:53:44 client 	<- &wire.StreamFrame{StreamID: 3, Fin: false, Offset: 0, Data length: 5, Offset + Data length: 5}
2024/02/23 13:53:44 client 	Queueing ACK because the first packet should be acknowledged.
2024/02/23 13:53:44 client Dropping %!s(logging.PacketType=0) packet (1252 bytes) because we already dropped the keys.
2024/02/23 13:53:44 client Dropping %!s(logging.PacketType=0) packet (1252 bytes) because we already dropped the keys.
2024/02/23 13:53:44 client -> Sending packet 1 (100 bytes) for connection 653eb4fd3228e5d212681248, Handshake
2024/02/23 13:53:44 client 	Long Header{Type: Handshake, DestConnectionID: 10843ef7, SrcConnectionID: (empty), PacketNumber: 1, PacketNumberLen: 2, Length: 62, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 3, LowestAcked: 0, DelayTime: 0s}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 36, Offset + Data length: 36}
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 0, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.RetireConnectionIDFrame{SequenceNumber:0x0}
2024/02/23 13:53:44 client -> Sending packet 1 (29 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 1, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 0, LowestAcked: 0, DelayTime: 11.954155ms}
1:53PM DBG QUIC handshake complete
1:53PM DBG try ssh-agent-based auth
1:53PM DBG we only try the first specified auth method for now
1:53PM DBG try the following Identity: agent-identity
1:53PM DBG establish conversation with the server
1:53PM DBG send CONNECT request on URL https://<IP_ADDRESS>:443/ssh3?user=pi, User-Agent="SSH 3.0 francoismichel/ssh3 0.1.7 experimental_spec_version=alpha-00"
2024/02/23 13:53:44 client -> Sending packet 2 (407 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 2, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.StreamFrame{StreamID: 2, Fin: false, Offset: 0, Data length: 5, Offset + Data length: 5}
2024/02/23 13:53:44 client 	-> &wire.StreamFrame{StreamID: 0, Fin: false, Offset: 0, Data length: 374, Offset + Data length: 374}
2024/02/23 13:53:44 client <- Reading packet 1 (255 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: (empty), PacketNumber: 1, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	<- &wire.AckFrame{LargestAcked: 1, LowestAcked: 0, DelayTime: 552µs, ECT0: 1, ECT1: 0, CE: 0}
2024/02/23 13:53:44 client Peer doesn't await address validation any longer.
2024/02/23 13:53:44 client 	newly acked packets (1): [0]
2024/02/23 13:53:44 client Canceling loss detection timer. No PTO needed..
2024/02/23 13:53:44 client Dropping Handshake keys.
2024/02/23 13:53:44 client 	<- &wire.CryptoFrame{Offset: 0, Data length: 133, Offset + Data length: 133}
2024/02/23 13:53:44 client 	<- &wire.NewTokenFrame{Token: 0xaef34b0004ce6897a001161b7261032c419513cc0c3af61bfd7f5b9817aa7f7f6cd6a91cbb5be14747f4f09672514da72df4af8dbc03026a29d9a18f28ab16b59910a6c0dbb0ada1e6cfabd31cec62a602e63462a5c6}
2024/02/23 13:53:44 client 	<- &wire.HandshakeDoneFrame{}
2024/02/23 13:53:44 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:44 client <- Reading packet 2 (111 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: (empty), PacketNumber: 2, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	<- &wire.AckFrame{LargestAcked: 2, LowestAcked: 0, DelayTime: 3.672ms, ECT0: 2, ECT1: 0, CE: 0}
2024/02/23 13:53:44 client 	newly acked packets (1): [2]
2024/02/23 13:53:44 client 	updated RTT: 48.977ms (σ: 33.396ms)
2024/02/23 13:53:44 client ECN capability confirmed.
2024/02/23 13:53:44 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:44 client 	<- &wire.StreamFrame{StreamID: 0, Fin: false, Offset: 0, Data length: 81, Offset + Data length: 81}
2024/02/23 13:53:44 client 	Queueing ACK because packet 2 packets were received after the last ACK (using initial threshold: 2).
2024/02/23 13:53:44 client -> Sending packet 3 (31 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 3, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 2, LowestAcked: 0, DelayTime: 117.709µs, ECT0: 2, ECT1: 0, CE: 0}
1:53PM DBG got response with 200 OK status code
1:53PM DBG server has valid version "SSH 3.0 francoismichel/ssh3 0.1.7 experimental_spec_version=alpha-00" (protocol version = 3.0_alpha-00, software version = francoismichel/ssh3 0.1.7)
1:53PM DBG start UDP forwarding from <IP_ADDRESS>:0 to <IP_ADDRESS>:443
1:53PM DBG started proxy jump at <IP_ADDRESS>:60745
1:53PM DBG dialing QUIC host at <IP_ADDRESS>:60745
2024/02/23 13:53:44 Increased receive buffer size to 2048 kiB
2024/02/23 13:53:44 Increased send buffer size to 2048 kiB
2024/02/23 13:53:44 Setting DF for IPv6.
2024/02/23 13:53:44 Activating reading of ECN bits for IPv6.
2024/02/23 13:53:44 Activating reading of packet info bits for IPv6.
2024/02/23 13:53:44 client Starting new connection to <IP_ADDRESS> ([::]:59517 -> <IP_ADDRESS>:60745), source connection ID (empty), destination connection ID 12cd7cd53b317a199e7e486b, version v1
2024/02/23 13:53:44 Adding connection ID (empty).
2024/02/23 13:53:44 client Not doing 0-RTT. Has sealer: false, has params: false
2024/02/23 13:53:44 client -> Sending packet 0 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:44 client -> Sending packet 4 (68 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 4, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.StreamFrame{StreamID: 4, Fin: false, Offset: 0, Data length: 43, Offset + Data length: 43}
2024/02/23 13:53:44 client <- Reading packet 3 (35 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: (empty), PacketNumber: 3, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	<- &wire.AckFrame{LargestAcked: 4, LowestAcked: 3, DelayTime: 136µs, ECT0: 4, ECT1: 0, CE: 0}
2024/02/23 13:53:44 client 	newly acked packets (1): [4]
2024/02/23 13:53:44 client 	updated RTT: 43.002ms (σ: 36.996ms)
2024/02/23 13:53:44 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:44 client 	<- &wire.StreamFrame{StreamID: 4, Fin: false, Offset: 0, Data length: 6, Offset + Data length: 6}
2024/02/23 13:53:44 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:44 client Sending ACK because the ACK timer expired.
2024/02/23 13:53:44 client -> Sending packet 5 (32 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:44 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 5, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:44 client 	-> &wire.AckFrame{LargestAcked: 3, LowestAcked: 0, DelayTime: 25.103536ms, ECT0: 3, ECT1: 0, CE: 0}
2024/02/23 13:53:44 client Loss detection alarm for Initial fired in PTO mode. PTO count: 1
2024/02/23 13:53:44 client -> Sending packet 1 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 1, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:44 client -> Sending packet 2 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 2, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:44 client Loss detection alarm for Initial fired in PTO mode. PTO count: 2
2024/02/23 13:53:44 client -> Sending packet 3 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 3, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:44 client -> Sending packet 4 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:44 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 4, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:44 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:45 client Sending a keep-alive PING to keep the connection alive.
2024/02/23 13:53:45 client -> Sending packet 6 (25 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:45 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 6, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:45 client 	-> &wire.PingFrame{}
2024/02/23 13:53:45 client <- Reading packet 4 (1352 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:45 client 	Short Header{DestConnectionID: (empty), PacketNumber: 4, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:45 client 	<- &wire.PingFrame{}
2024/02/23 13:53:45 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:45 client <- Reading packet 5 (28 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:45 client 	Short Header{DestConnectionID: (empty), PacketNumber: 5, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:45 client 	<- &wire.AckFrame{LargestAcked: 6, LowestAcked: 5, DelayTime: 26.064ms, ECT0: 6, ECT1: 0, CE: 0}
2024/02/23 13:53:45 client 	newly acked packets (1): [6]
2024/02/23 13:53:45 client 	updated RTT: 37.864ms (σ: 38.022ms)
2024/02/23 13:53:45 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:45 client Sending ACK because the ACK timer expired.
2024/02/23 13:53:45 client -> Sending packet 7 (31 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:45 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 7, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:45 client 	-> &wire.AckFrame{LargestAcked: 5, LowestAcked: 0, DelayTime: 77.687µs, ECT0: 5, ECT1: 0, CE: 0}
2024/02/23 13:53:45 client Loss detection alarm for Initial fired in PTO mode. PTO count: 3
2024/02/23 13:53:45 client -> Sending packet 5 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:45 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 5, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:45 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:45 client -> Sending packet 6 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:45 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 6, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:45 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:46 Tracking 1 connection IDs and 1 reset tokens.
2024/02/23 13:53:46 Tracking 1 connection IDs and 0 reset tokens.
2024/02/23 13:53:46 client Sending a keep-alive PING to keep the connection alive.
2024/02/23 13:53:46 client -> Sending packet 8 (25 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:46 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 8, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:46 client 	-> &wire.PingFrame{}
2024/02/23 13:53:46 client <- Reading packet 6 (1402 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:46 client 	Short Header{DestConnectionID: (empty), PacketNumber: 6, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:46 client 	<- &wire.PingFrame{}
2024/02/23 13:53:46 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:46 client <- Reading packet 7 (28 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:46 client 	Short Header{DestConnectionID: (empty), PacketNumber: 7, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:46 client 	<- &wire.AckFrame{LargestAcked: 8, LowestAcked: 5, DelayTime: 25.52ms, ECT0: 8, ECT1: 0, CE: 0}
2024/02/23 13:53:46 client 	newly acked packets (1): [8]
2024/02/23 13:53:46 client 	updated RTT: 33.343ms (σ: 37.557ms)
2024/02/23 13:53:46 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:46 client Sending ACK because the ACK timer expired.
2024/02/23 13:53:46 client -> Sending packet 9 (31 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:46 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 9, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:46 client 	-> &wire.AckFrame{LargestAcked: 7, LowestAcked: 0, DelayTime: 185.693µs, ECT0: 7, ECT1: 0, CE: 0}
2024/02/23 13:53:47 client Loss detection alarm for Initial fired in PTO mode. PTO count: 4
2024/02/23 13:53:47 client -> Sending packet 7 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:47 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 7, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:47 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:47 client -> Sending packet 8 (1252 bytes) for connection 12cd7cd53b317a199e7e486b, Initial
2024/02/23 13:53:47 client 	Long Header{Type: Initial, DestConnectionID: 12cd7cd53b317a199e7e486b, SrcConnectionID: (empty), Token: (empty), PacketNumber: 8, PacketNumberLen: 2, Length: 1230, Version: v1}
2024/02/23 13:53:47 client 	-> &wire.CryptoFrame{Offset: 0, Data length: 248, Offset + Data length: 248}
2024/02/23 13:53:47 client Sending a keep-alive PING to keep the connection alive.
2024/02/23 13:53:47 client -> Sending packet 10 (25 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:47 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 10, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:47 client 	-> &wire.PingFrame{}
2024/02/23 13:53:47 client <- Reading packet 8 (1427 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:47 client 	Short Header{DestConnectionID: (empty), PacketNumber: 8, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:47 client 	<- &wire.PingFrame{}
2024/02/23 13:53:47 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:47 client <- Reading packet 9 (28 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:47 client 	Short Header{DestConnectionID: (empty), PacketNumber: 9, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:47 client 	<- &wire.AckFrame{LargestAcked: 10, LowestAcked: 5, DelayTime: 25.808ms, ECT0: 10, ECT1: 0, CE: 0}
2024/02/23 13:53:47 client 	newly acked packets (1): [10]
2024/02/23 13:53:47 client 	updated RTT: 29.405ms (σ: 36.043ms)
2024/02/23 13:53:47 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:47 client Sending ACK because the ACK timer expired.
2024/02/23 13:53:47 client -> Sending packet 11 (31 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:47 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 11, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:47 client 	-> &wire.AckFrame{LargestAcked: 9, LowestAcked: 0, DelayTime: 263.216µs, ECT0: 9, ECT1: 0, CE: 0}
2024/02/23 13:53:48 Tracking 1 connection IDs and 1 reset tokens.
2024/02/23 13:53:48 Tracking 1 connection IDs and 0 reset tokens.
2024/02/23 13:53:48 client Sending a keep-alive PING to keep the connection alive.
2024/02/23 13:53:48 client -> Sending packet 12 (25 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:48 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 12, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:48 client 	-> &wire.PingFrame{}
2024/02/23 13:53:48 client <- Reading packet 10 (1439 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:48 client 	Short Header{DestConnectionID: (empty), PacketNumber: 10, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:48 client 	<- &wire.PingFrame{}
2024/02/23 13:53:48 client 	Setting ACK timer to max ack delay: 25ms
2024/02/23 13:53:48 client <- Reading packet 11 (28 bytes) for connection (empty), 1-RTT
2024/02/23 13:53:48 client 	Short Header{DestConnectionID: (empty), PacketNumber: 11, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:48 client 	<- &wire.AckFrame{LargestAcked: 12, LowestAcked: 5, DelayTime: 25.632ms, ECT0: 12, ECT1: 0, CE: 0}
2024/02/23 13:53:48 client 	newly acked packets (1): [12]
2024/02/23 13:53:48 client 	updated RTT: 25.956ms (σ: 33.928ms)
2024/02/23 13:53:48 client Canceling loss detection timer. No packets in flight.
2024/02/23 13:53:48 client Sending ACK because the ACK timer expired.
2024/02/23 13:53:48 client -> Sending packet 13 (31 bytes) for connection 653eb4fd3228e5d212681248, 1-RTT (ECN: ECT(0))
2024/02/23 13:53:48 client 	Short Header{DestConnectionID: 10843ef7, PacketNumber: 13, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 13:53:48 client 	-> &wire.AckFrame{LargestAcked: 11, LowestAcked: 0, DelayTime: 128.9µs, ECT0: 11, ECT1: 0, CE: 0}
2024/02/23 13:53:49 client Destroying connection: timeout: no recent network activity
2024/02/23 13:53:49 Removing connection ID (empty).
2024/02/23 13:53:49 client Connection 12cd7cd53b317a199e7e486b closed.
1:53PM ERR could not establish client QUIC connection: timeout: no recent network activity
1:53PM ERR could not setup transport for client: %!s(<nil>)
marco@loop ~/M/g/p/ssh3 (main) [255]>

Wireshark quic packets.

Thanks for the infos, it already helps to see that the client does not seem to send the HTTP/3 datagram frames towards the server to tunnel the new connection.
In the current implementation of proxy-jump, the client simply does a UDP port forwarding that tunnels the new QUIC connection.
Seeing the following line

dialing QUIC host at <IP_ADDRESS>:60745

It seems that the client correctly sends the Initial QUIC packets to the right socket address (the one that performs UDP port forwarding).
I believe that if there was a problem with quic-go's datagrams sending, there would be an error logged, so maybe the
client just does not receive the packet to forward for whatever reason.
I would be interested to see the UDP/QUIC packets on the loopback, in the run you just showed here, these would be packets with a destination port equal to 60745.
My little finger also tells me that the IP version could be involved here as well (e.g. the port forwarding only listens on a v4 but the connection establishment for the second connection sends a v6 packet.

Here is the data from the loopback interface. This is from a new run. Looks like a Client Hello and the rest is retransmissions?
I think it is also forwarded over the existing connection to the jump host. At least packets arrive at the same second(s) when the client still (re)tries. But nothing seems to come back on the loopback connection.
Last login: Fri Feb 23 15:23:41 on ttys018
You have mail.
marco@loop ~> tshark -n -r ssh3_lo.pcap
    1   0.000000    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 0, PADDING, CRYPTO
    2   0.201977    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 1, PADDING, CRYPTO
    3   0.202022    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 2, PADDING, CRYPTO
    4   0.603402    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 3, PADDING, CRYPTO
    5   0.603440    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 4, PADDING, CRYPTO
    6   1.406475    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 5, PADDING, CRYPTO
    7   1.406529    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 6, PADDING, CRYPTO
    8   3.011306    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 7, PADDING, CRYPTO
    9   3.011319    <IP_ADDRESS> 64874 <IP_ADDRESS>    64172 QUIC 1284    Initial, DCID=8bfdd183768cf0148d, PKN: 8, PADDING, CRYPTO
marco@loop ~> tshark -n -r ssh3_lo.pcap -2 -V -R "quic"
Frame 1: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:06.633815000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.633815000
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic:tls]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x5914 (22804)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 0]
    Payload: 47bdeb338e4f5901d9809ffab282b58c45bec61a0f737000cafbda0aeaf62e29d6fc8879…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        TLSv1.3 Record Layer: Handshake Protocol: Client Hello
            Handshake Protocol: Client Hello
                Handshake Type: Client Hello (1)
                Length: 243
                Version: TLS 1.2 (0x0303)
                Random: c0fb6d306db31c623209abdc5d518d62808659a1041e6089b98816df777119b0
                Session ID Length: 0
                Cipher Suites Length: 6
                Cipher Suites (3 suites)
                    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                    Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                    Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Compression Methods Length: 1
                Compression Methods (1 method)
                    Compression Method: null (0)
                Extensions Length: 196
                Extension: status_request (len=5)
                    Type: status_request (5)
                    Length: 5
                    Certificate Status Type: OCSP (1)
                    Responder ID list Length: 0
                    Request Extensions Length: 0
                Extension: supported_groups (len=10)
                    Type: supported_groups (10)
                    Length: 10
                    Supported Groups List Length: 8
                    Supported Groups (4 groups)
                        Supported Group: x25519 (0x001d)
                        Supported Group: secp256r1 (0x0017)
                        Supported Group: secp384r1 (0x0018)
                        Supported Group: secp521r1 (0x0019)
                Extension: ec_point_formats (len=2)
                    Type: ec_point_formats (11)
                    Length: 2
                    EC point formats Length: 1
                    Elliptic curves point formats (1)
                        EC point format: uncompressed (0)
                Extension: signature_algorithms (len=26)
                    Type: signature_algorithms (13)
                    Length: 26
                    Signature Hash Algorithms Length: 24
                    Signature Hash Algorithms (12 algorithms)
                        Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                            Signature Hash Algorithm Hash: Unknown (8)
                            Signature Hash Algorithm Signature: SM2 (4)
                        Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                            Signature Hash Algorithm Hash: SHA256 (4)
                            Signature Hash Algorithm Signature: ECDSA (3)
                        Signature Algorithm: ed25519 (0x0807)
                            Signature Hash Algorithm Hash: Unknown (8)
                            Signature Hash Algorithm Signature: Unknown (7)
                        Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                            Signature Hash Algorithm Hash: Unknown (8)
                            Signature Hash Algorithm Signature: Unknown (5)
                        Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                            Signature Hash Algorithm Hash: Unknown (8)
                            Signature Hash Algorithm Signature: Unknown (6)
                        Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                            Signature Hash Algorithm Hash: SHA256 (4)
                            Signature Hash Algorithm Signature: RSA (1)
                        Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                            Signature Hash Algorithm Hash: SHA384 (5)
                            Signature Hash Algorithm Signature: RSA (1)
                        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                            Signature Hash Algorithm Hash: SHA512 (6)
                            Signature Hash Algorithm Signature: RSA (1)
                        Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                            Signature Hash Algorithm Hash: SHA384 (5)
                            Signature Hash Algorithm Signature: ECDSA (3)
                        Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                            Signature Hash Algorithm Hash: SHA512 (6)
                            Signature Hash Algorithm Signature: ECDSA (3)
                        Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                            Signature Hash Algorithm Hash: SHA1 (2)
                            Signature Hash Algorithm Signature: RSA (1)
                        Signature Algorithm: ecdsa_sha1 (0x0203)
                            Signature Hash Algorithm Hash: SHA1 (2)
                            Signature Hash Algorithm Signature: ECDSA (3)
                Extension: renegotiation_info (len=1)
                    Type: renegotiation_info (65281)
                    Length: 1
                    Renegotiation Info extension
                        Renegotiation info extension length: 0
                Extension: extended_master_secret (len=0)
                    Type: extended_master_secret (23)
                    Length: 0
                Extension: application_layer_protocol_negotiation (len=5)
                    Type: application_layer_protocol_negotiation (16)
                    Length: 5
                    ALPN Extension Length: 3
                    ALPN Protocol
                        ALPN string length: 2
                        ALPN Next Protocol: h3
                Extension: signed_certificate_timestamp (len=0)
                    Type: signed_certificate_timestamp (18)
                    Length: 0
                Extension: supported_versions (len=3)
                    Type: supported_versions (43)
                    Length: 3
                    Supported Versions length: 2
                    Supported Version: TLS 1.3 (0x0304)
                Extension: key_share (len=38)
                    Type: key_share (51)
                    Length: 38
                    Key Share extension
                        Client Key Share Length: 36
                        Key Share Entry: Group: x25519, Key Exchange length: 32
                            Group: x25519 (29)
                            Key Exchange Length: 32
                            Key Exchange: 26579812b24cbc8a61f7eb7996d0f0010ef1ff377717ea56a8ce9704cfb31439
                Extension: quic_transport_parameters (len=62)
                    Type: quic_transport_parameters (57)
                    Length: 62
                    Parameter: GREASE (len=4)
                        Type: GREASE (0x94f)
                        Length: 4
                        Value: ac8a0307
                    Parameter: initial_max_stream_data_bidi_local (len=4) 524288
                        Type: initial_max_stream_data_bidi_local (0x05)
                        Length: 4
                        Value: 80080000
                        initial_max_stream_data_bidi_local: 524288
                    Parameter: initial_max_stream_data_bidi_remote (len=4) 524288
                        Type: initial_max_stream_data_bidi_remote (0x06)
                        Length: 4
                        Value: 80080000
                        initial_max_stream_data_bidi_remote: 524288
                    Parameter: initial_max_stream_data_uni (len=4) 524288
                        Type: initial_max_stream_data_uni (0x07)
                        Length: 4
                        Value: 80080000
                        initial_max_stream_data_uni: 524288
                    Parameter: initial_max_data (len=4) 786432
                        Type: initial_max_data (0x04)
                        Length: 4
                        Value: 800c0000
                        initial_max_data: 786432
                    Parameter: initial_max_streams_bidi (len=1) 10
                        Type: initial_max_streams_bidi (0x08)
                        Length: 1
                        Value: 0a
                        initial_max_streams_bidi: 10
                    Parameter: initial_max_streams_uni (len=2) 100
                        Type: initial_max_streams_uni (0x09)
                        Length: 2
                        Value: 4064
                        initial_max_streams_uni: 100
                    Parameter: max_idle_timeout (len=4) 30000 ms
                        Type: max_idle_timeout (0x01)
                        Length: 4
                        Value: 80007530
                        max_idle_timeout: 30000
                    Parameter: max_udp_payload_size (len=2) 1452
                        Type: max_udp_payload_size (0x03)
                        Length: 2
                        Value: 45ac
                        max_udp_payload_size: 1452
                    Parameter: max_ack_delay (len=1) 26
                        Type: max_ack_delay (0x0b)
                        Length: 1
                        Value: 1a
                        max_ack_delay: 26
                    Parameter: disable_active_migration (len=0)
                        Type: disable_active_migration (0x0c)
                        Length: 0
                        Value: <MISSING>
                    Parameter: active_connection_id_limit (len=1) 4
                        Type: active_connection_id_limit (0x0e)
                        Length: 1
                        Value: 04
                        Active Connection ID Limit: 4
                    Parameter: initial_source_connection_id (len=0)
                        Type: initial_source_connection_id (0x0f)
                        Length: 0
                        Value: <MISSING>
                        Initial Source Connection ID: <MISSING>
                    Parameter: max_datagram_frame_size (len=2) 16383
                        Type: max_datagram_frame_size (0x20)
                        Length: 2
                        Value: 7fff
                        max_datagram_frame_size: 16383
                [JA3 Fullstring: 771,4865-4866-4867,5-10-11-13-65281-23-16-18-43-51-57,29-23-24-25,0]
                [JA3: ea0aece5703cb982b232a0684fc35b16]

Frame 2: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:06.835792000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.835792000
    [Time delta from previous captured frame: 0.201977000 seconds]
    [Time delta from previous displayed frame: 0.201977000 seconds]
    [Time since reference or first frame: 0.201977000 seconds]
    Frame Number: 2
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0xef0a (61194)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.201977000 seconds]
        [Time since previous frame: 0.201977000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 1]
    Payload: e0892ac1f02c2f948f3cb718040b19fdacf40ae89ef391f0aeac1ef372f11cc62a8d515c…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 3: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:06.835837000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.835837000
    [Time delta from previous captured frame: 0.000045000 seconds]
    [Time delta from previous displayed frame: 0.000045000 seconds]
    [Time since reference or first frame: 0.202022000 seconds]
    Frame Number: 3
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x6a5f (27231)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.202022000 seconds]
        [Time since previous frame: 0.000045000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 2]
    Payload: 1de2cdc0f91a67999c02b4fc5276a79287cebed4a708a3b0591ef19dd8b89b503a6f092c…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 4: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:07.237217000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.237217000
    [Time delta from previous captured frame: 0.401380000 seconds]
    [Time delta from previous displayed frame: 0.401380000 seconds]
    [Time since reference or first frame: 0.603402000 seconds]
    Frame Number: 4
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x7bc9 (31689)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.603402000 seconds]
        [Time since previous frame: 0.401380000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 3]
    Payload: 5be6ab63eec84b1013ff468766ccd6941c07809b56444bd3dd218887a9dd6a6102d2b0f5…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 5: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:07.237255000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.237255000
    [Time delta from previous captured frame: 0.000038000 seconds]
    [Time delta from previous displayed frame: 0.000038000 seconds]
    [Time since reference or first frame: 0.603440000 seconds]
    Frame Number: 5
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x1694 (5780)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.603440000 seconds]
        [Time since previous frame: 0.000038000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 4]
    Payload: 970e6fae4b99011c5c0dec1b033e612d22043c886490243faadd35878e6eee1cbdaf9f7e…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 6: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:08.040290000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.040290000
    [Time delta from previous captured frame: 0.803035000 seconds]
    [Time delta from previous displayed frame: 0.803035000 seconds]
    [Time since reference or first frame: 1.406475000 seconds]
    Frame Number: 6
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0xaa12 (43538)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 1.406475000 seconds]
        [Time since previous frame: 0.803035000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 5]
    Payload: 37681d30f041707d10210a4e579ff4178ad882e8b6020c3431167cc720e11f286d5a1a55…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 7: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:08.040344000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.040344000
    [Time delta from previous captured frame: 0.000054000 seconds]
    [Time delta from previous displayed frame: 0.000054000 seconds]
    [Time since reference or first frame: 1.406529000 seconds]
    Frame Number: 7
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x76c4 (30404)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 1.406529000 seconds]
        [Time since previous frame: 0.000054000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 6]
    Payload: 705e70a3e361767d012bec6e3ce0c76c3090d979f4434fb5dc76484448321ebfbc9683e1…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 8: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:09.645121000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.645121000
    [Time delta from previous captured frame: 1.604777000 seconds]
    [Time delta from previous displayed frame: 1.604777000 seconds]
    [Time since reference or first frame: 3.011306000 seconds]
    Frame Number: 8
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x6c7d (27773)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 3.011306000 seconds]
        [Time since previous frame: 1.604777000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 7]
    Payload: b46e7405947d56e447305e03a7a35bb07e142e3694eead31a118cb982529f4f2b6a9d277…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

Frame 9: 1284 bytes on wire (10272 bits), 1284 bytes captured (10272 bits)
    Encapsulation type: NULL/Loopback (15)
    Arrival Time: Feb 23, 2024 15:24:09.645134000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time:<PHONE_NUMBER>.645134000
    [Time delta from previous captured frame: 0.000013000 seconds]
    [Time delta from previous displayed frame: 0.000013000 seconds]
    [Time since reference or first frame: 3.011319000 seconds]
    Frame Number: 9
    Frame Length: 1284 bytes (10272 bits)
    Capture Length: 1284 bytes (10272 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: null:ip:udp:quic]
Null/Loopback
    Family: IP (2)
Internet Protocol Version 4, Src: <IP_ADDRESS>, Dst: <IP_ADDRESS>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1280
    Identification: 0x7f33 (32563)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: <IP_ADDRESS>
    Destination Address: <IP_ADDRESS>
User Datagram Protocol, Src Port: 64874, Dst Port: 64172
    Source Port: 64874
    Destination Port: 64172
    Length: 1260
    Checksum: 0x0300 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 3.011319000 seconds]
        [Time since previous frame: 0.000013000 seconds]
    UDP payload (1252 bytes)
QUIC IETF
    QUIC Connection information
        [Connection Number: 0]
    [Packet Length: 1252]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    [.... 00.. = Reserved: 0]
    [.... ..01 = Packet Number Length: 2 bytes (1)]
    Version: 1 (0x00000001)
    Destination Connection ID Length: 9
    Destination Connection ID: 8bfdd183768cf0148d
    Source Connection ID Length: 0
    Token Length: 0
    Length: 1233
    [Packet Number: 8]
    Payload: cef1ec08e3a2a5970ea1c2c56af75ff5bda0773b8eb64b40d72300dfad1e2b86eed3df23…
    PADDING Length: 964
        Frame Type: PADDING (0x0000000000000000)
        [Padding Length: 964]
    CRYPTO
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 247
        Crypto Data
        This QUIC frame has a reused stream offset (retransmission?)
            [Expert Info (Note/Sequence): This QUIC frame has a reused stream offset (retransmission?)]
                [This QUIC frame has a reused stream offset (retransmission?)]
                [Severity level: Note]
                [Group: Sequence]

I think it is also forwarded over the existing connection to the jump host. At least packets arrive at the same second(s) when the client still (re)tries. But nothing seems to come back on the loopback connection.

Maybe yes, but these could also be ping packets or MTU probes from quic-go.
I did not see QUIC Datagram frames being sent in your quic-go log from the previous run, so it seems the QUIC packets are not forwarded to the jump host.
If packets were forwarded, I would expect to see such packets in your client->jumphost log, with the datagram frame being really big:
2024/02/23 16:17:18 client -> Sending packet 23 (1380 bytes) for connection 4d59f26c8dffe700d0ff11ef10dd, 1-RTT (ECN: ECT(0))
2024/02/23 16:17:18 client 	Short Header{DestConnectionID: 68b609d1, PacketNumber: 23, PacketNumberLen: 2, KeyPhase: 0}
2024/02/23 16:17:18 client 	-> &wire.DatagramFrame{DataLenPresent:true, Data:[]uint8{0x0, 0x4, 0x5d, 0xe3, ...}}
...

Everythings looks kind of okay on your packet capture, I just don't get why datagram frames are not sent from the client to the proxy, like if the client was not listening correctly on the UDP socket or if the packets were dropped by the kernel, or a firewall or anything. I guess UDP usually works well on your loopback ?
I can add some more logging on another branch to debug a little more. More logging is always good to have anyway. :-)

Now that you say you cannot reproduce it, my thought was my client is the problem or maybe difference. My client is a Mac (Intel) and that seems to be the problem.
I have tested it now on 11.7.10 and 13.6.4. On both it does not work.
I started a Linux VM on my Mac and tried it from there and that works just fine.
The go versions on Mac are recent and there was no issue compiling.
Big Sur
marco@loop ~> go version
go version go1.21.6 darwin/amd64

Ventura
marco@eagle ~> go version
go version go1.22.0 darwin/amd64

And for your other udp question. I have no experienced any udp issues on the loopback interface so far. But have also not paied much attention to it, to be honest. Don't notice any other issues.
I tried a quic-go test on loopback with the test server/client. That works fine.  One difference with your quic-go test is that you use localhost:6121 and ssh3 uses <IP_ADDRESS>:something. The packet size is also slightly smaller with raw quic-go compared to the encapsulated quic-go with ssh3's proxy jump.
I wonder if running the server on the Mac and connecting to it from localhost fails as well.
I've seen issues here and there in quic-go with problems on the loopback with BSD, that may be related (https://github.com/quic-go/quic-go/issues/4105, https://github.com/quic-go/quic-go/issues/4304).
I can try to get a mac at the office next week and dig it into more details. :-)

I did not test the server on Mac, because I read in one issue it is not supported yet. But I guess that was older.
Just tested Mac to Mac and that works in general. But using when using the Mac server as jump host same issue. Which points to something purely on the client, I guess?

I have tried to modify the 2 files, what was mentioned in the issues you mentioned The sys_con_oob.go and sys_conn_helper_freebsd.go. But I changed it in the darwin file and not the freebsd one.
<EMAIL_ADDRESS><EMAIL_ADDRESS>Did not make any difference. But also not sure, if I did it right.

Found it ! Seems related to MacOS not correctly setting the DF bit on dual-stack UDP sockets (udp instead of udp4 and udp6). This quic-go issue discusses that problem: https://github.com/quic-go/quic-go/issues/3793
without the DF bit set, quic-go won't perform path MTU discovery. Without path MTU discuvery, the default MTU will be too small to carry the quic-go initial packet (which could theoretically be 40 bytes smaller but quic-go fills the IP packet  at maximum in its initial).
One fix is to not use a dual stack socket on MacOS, the fix should come soon.

Could you try the client on MacOS from that PR https://github.com/francoismichel/ssh3/pull/130 ?
It is not fixed on the MacOS server though, only the MacOS client is fixed.


Removing the prod. part from the IDP urls and fixing some of the type erros

Removing prod. part from the idp url.
Fixing some of the type errors.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.WSO2 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report
Patch coverage has no change and project coverage change: +22.94 :tada:

Comparison is base (1a6d4d0) 57.16% compared to head (051eb2f) 80.10%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1180       +/-   ##
===========================================
+ Coverage   57.16%   80.10%   +22.94%
===========================================
  Files          13        9        -4
  Lines        1319      548      -771
  Branches      768      246      -522
===========================================
- Hits          754      439      -315
+ Misses        565      109      -456

Flag
Coverage Δ

admin-domain-service
?

idp-domain-service
80.10% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 22 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Address from another PR


Code samples should be updated to Azure.ResourceManager.Cdn

Current content is based on Microsoft.Azure.Management.Cdn.Fluent which has been deprecated. Code samples should be updated to the currently supported SDK.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: cda67fd8-ca0e-5eb1-f58c-cafebbdd855f
Version Independent ID: 21582c44-4cc0-9f6b-6042-8afc98b99c08
Content: Get started with the Azure CDN Library for .NET
Content Source: articles/cdn/cdn-app-dev-net.md
Service: azure-cdn
GitHub Login: @duongau
Microsoft Alias: duau

@JeffKoMS
Thank you for your feedback! We have assigned this issue to the author to review further and take the next course of action.

Hello @JeffKoMS, thank you for bringing this to our attention. I will be retiring that page soon and requesting our PG team to provide an updated documentation with the current SDK. For now I'll be closing this issue. #please-close


import utils vs import grlc.utils

In dev there are some issues regarding the use of importing grlc packages as
import grlc.utils as utils
AttributeError: module 'grlc' has no attribute 'utils'

@c-martinez I think we already solved this some time ago? Maybe we solved this by forcing grlc to be installed as a library inside the container and then importing utils instead of grlc.utils?

No worries, fixed in 489a36b :-)


[ldd-ctli] It is not possible to use the CTLI namespace to describe multi-mode instruments

Issue Type
Multi-mode instruments are not uncommon; I'm assuming it is a bug that they are not supported. If the intention was not  to support multi-mode instruments, then this is an enhancement, not a bug.
Describe the issue identified (if applicable)
I attempted to use the CTLI dictionary to create a context object to describe the IMACS instrument mounted on the Magellan Baade telescope at Las Campanas Observatory. A summary of instrument specs is here:
http://www.lco.cl/wp-content/uploads/2021/03/IMACShandout2021.pdf
This instrument acts as both an imager and a spectrograph (among other things). There is no  value exactly  corresponding to "spectrograph", and it is in fact a wide-field imager, which is an important characteristic to note. When I encountered the <Type_List_Area> in the  object, I went looking for documentation on how to use the CTLI dictionary, but found none (I checked the Standards, the DPH, and the CTLI repo). When I attempted to guess my way through I was informed by validation that all these variations are not schematically valid because of their structure (the attribute values themselves are valid):
Method 1:
<Type_List_Area>
  <ctli:Type_List>
    <ctli:type>Imager</ctli:type>
    <ctli:subtype>wide-field</ctli:subtype>
  </ctli:Type_List>
  <ctli:Type_List>
    <ctli:type>Spectrometer</ctli:type>
    <ctli:subtype>spectrograph</ctli:subtype>
    <ctli:subtype>multi-object</ctli:subtype>
  </ctli:Type_List>
</Type_List_Area>

Method 2:
<Type_List_Area>
  <ctli:Type_List>
    <ctli:type>Imager</ctli:type>
    <ctli:subtype>wide-field</ctli:subtype>
    <ctli:type>Spectrometer</ctli:type>
    <ctli:subtype>spectrograph</ctli:subtype>
    <ctli:subtype>multi-object</ctli:subtype>
  </ctli:Type_List>
</Type_List_Area>

Method 3:
<Type_List_Area>
    <ctli:type>Imager</ctli:type>
    <ctli:subtype>wide-field</ctli:subtype>
    <ctli:type>Spectrometer</ctli:type>
    <ctli:subtype>spectrograph</ctli:subtype>
    <ctli:subtype>multi-object</ctli:subtype>
</Type_List_Area>

Method 4:
<Type_List_Area>
  <ctli:Type_List>
    <ctli:type>Imager</ctli:type>
    <ctli:subtype>wide-field</ctli:subtype>
  </ctli:Type_List>
</Type_List_Area>
<Type_List_Area>
  <ctli:Type_List>
    <ctli:type>Spectrometer</ctli:type>
    <ctli:subtype>spectrograph</ctli:subtype>
    <ctli:subtype>multi-object</ctli:subtype>
  </ctli:Type_List>
</Type_List_Area>

Describe the solution you'd like
I need to be able to describe both types and subtypes of each of the modes of multi-mode instruments, and have the subtypes properly associated with their respective major types.
Describe alternatives you've considered
See above. Context objects are required and instrument type attributes are potential search criteria. There is no alternative to the context requirement. Not supporting search for multi-mode instruments is not an acceptable alternative.
LDD Dictionary Version
<IP_ADDRESS> and all preceding
PDS4 IM Version
ASAP. This will impact the ability to ingest essential ground-characterization data included in the DART mission.
Need-by Date
ASAP, in terms of build cycles. Data from this instrument are expected in early 2022, and would likely be registered in the March-June quarter.
Additional context
This capability will also be needed for migration of data from multi-mode instruments on Rosetta, Deep Impact, etc. That timeline is more flexible than that of the DART mission.

Yes, we thought that Method 2 was what we were allowing but it turned out not to be. Method 1 is going to be the option going forward. Posting new Ingest file shortly.

That'll work. Thanks @lylehuber!


AVX2: Switch to custom NTT coefficient ordering

The AVX2 assembly routines use a custom coefficient ordering in NTT domain, but until now, we've always conjugated the routines with permutations to keep them in standard order. This commit removes those conjugations, switching to using the custom order throughout.

This gives a small bump in performance.
ML-KEM-768 encaps on Intel Xeon 4th gen (c7i): 68089 -> 65593


Caret height when using Custom Segment

Hi,
Thank you for this great library. It has been quite a blessing using it.
I needed some information, and possibly a solution to a problem, concerning an aesthetic. Apparently, when one uses a custom segment, let's say an image, which has different dimensions that are larger than the current row height before insertion, the caret scales to the height of the image. As illustrated in the diagram (caret not visible but the drawing illustrates the issue).

Is there a possibility of ensuring the caret height remain same height as before. I've searched through the Issues (open and closed), but couldn't find a similar concern. This can be replicated by the current Rich Text Editor demo, which the program has been modified from. Currently using RichText 0.10.5 (with jdk 1.8)

Sorry, I don't think there is. I've also seen this behavior myself and also thought it was ugly :-)
I suppose some sort of test could be added (not sure about that) so that when the previous segment isn't Text then the caret doesn't grow/adjust .... ?

Yes, if there is a way that can be done, that would be awesome. But if not possible now, I can try to live with it and get used to it. Lol.


(SERVER-2059) Fix ambiguous operator in lib/puppet/functions/map.rb

Previously, we had an ambiguous operator that would always cause
warnings when running with JRuby 9k.
These warning are suspected of causing unwanted interactions with
production logging systems and should be removed regardless.
This removes the ambiguous operator usage.

@justinstoller can you move the SERVER ticket to PUP and update the commit summary with that ticket (travis is failing on the commit check)?


Click outside to close not working

Hello, and thank you so much for making this awesome date time picker!
I looked through the code and "clickOutsideToClose" is set to true, but for some reason, even in the demos here https://logbon72.github.io/angular-material-datetimepicker/ when you click outside, the dialog doesn't close.  Do you know why?

Only the mdcDateTimeDialog Service have the clickOutsideToClose set to true.
We should probably expose this parameter and clickOutsideToClose : default false
As normal user click outside by accident.


Add reporting summary message of count of Errors, issues to end of process

It would be handy to have a summary count of Errors, and count/list of feature classes with field map failures to end of processing message. Easy to overlook them when they're just inline.

This would apply to Append Military Feature, Append Military Feature from Workspace.
The use case is appending shapefile data structured for MOLE (or other shapefiles that do not match the Mil Feature schema exactly) and for cases where the SIDC does not have a match in the symbol dictionary and an error and Null symbol are returned.
Currently the tools' messaging notes these conditions inline with messages like:
"Failed to Map (Types Don't Match) Input Field: DTG to Output Field: datetimevalid"
or
"ERROR: Null Symbol returned for SIDC: WA--WSBD--P----"
I think the detailed inline reporting is good, but it would be handy at the end of the process to add a summary message reporting the total number of errors and issues encountered, people can go back and look at the log to get the specifics.

Added to Asana - https://app.asana.com/0/23146878550035/23179693844838

Closing. The toolbox and issues are managed in https://github.com/Esri/solutions-geoprocessing-toolbox/tree/dev/military_features.


Add neat factorial recursion function

Kindly merge it if you find it useful and label it as hacktoberfest
Issue #193

@Astrodevil  kind add hacktoberfest-accepted label.


Disable save button when Inspector is not editing anything

Fixes #50799
When Inspector is not editing anything:

Disable the save button.
Disable related menu items in the extra options menu.

Did a small refactoring so that the disable-on-nothing logic is not so repetitive.

Thanks!


Think about cloning behavior of different errors.

https://github.com/inf3rno/o3/issues/93

Currently the UserError creates a different stack by cloning and the CompositeError does the same. The CompositeError does not clone its properties, but I don't think it would be necessary. This is sufficient. The NativeError does not clone anything. It may not work after cloning.
I need to test

whether the UserError really has a different stack after cloning
whether the CompositeError really works and has a different composite stack
whether the NativeError works with the same stack after cloning

I don't have to test these. I checked how Object.defineProperty works by inheritance. #22 They will be okay.


fix: fix how to guide changes

Signed-off-by: Lalith Vipulananthan<EMAIL_ADDRESS>Description
Missed removing the "how-to guides" section from the main .pages file in my previous PR (#147)
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The Reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

Closing PR, since the decision was made to revert the changes in #147


Unable to create the RedHat OpenShift cluster on Azure

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az aro create Extension Name: aro. Version: 1.0.0.
Errors:
'NoneType' object has no attribute 'object_id'
Traceback (most recent call last):
Temp\pip-install-_kvuguic\knack\knack\cli.py, ln 215, in invoke
azure\cli\core\commands\__init__.py, ln 654, in execute
azure\cli\core\commands\__init__.py, ln 718, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 711, in _run_job
Local\Temp\pip-install-_kvuguic\six\six.py, ln 703, in reraise
azure\cli\core\commands\__init__.py, ln 688, in _run_job
azure\cli\core\commands\__init__.py, ln 325, in __call__
site-packages\azure\cli\core\__init__.py, ln 545, in default_command_handler
.azure\cliextensions\aro\azext_aro\custom.py, ln 66, in aro_create
    assign_contributor_to_vnet(cmd.cli_ctx, vnet, rp_client_sp.object_id, 'rp_client')
AttributeError: 'NoneType' object has no attribute 'object_id'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aro create --resource-group {} --name {} --vnet {} --master-subnet {} --worker-subnet {} --domain {} --pull-secret {}

Expected Behavior
Environment Summary
Windows-10-10.0.18362-SP0
Python 3.6.6
Installer: MSI

azure-cli 2.7.0

Extensions:
aro 1.0.0

Additional Context

aro

@vikramdillikar can you please try remove az aro extension and try using native az.
You are using the extension, which might be old already.

@yonzhan how can we close those?


Fix subtle optimizer bug

Fix subtle optimizer bug -- under some very specific circumstances, an output parameter whose default value comes from "init ops" but which actually got an instance value, and was also connected to a downstream layer, could be eliminated but incorrectly, by passing along to the downstream shader the constant value it would have been assigned by default, rather than the constant instance value.
In addition to the bug fix itself, I also added some additional debugging aids.

LGTM