Connection disconnect due to missing Binding replies

Describe the bug
A few seconds to a few minutes after connecting to a gateway, we disconnect from it. Thereafter we reconnect to simply experience the same thing.
From the logs pasted below we can see that we never received to our STUN request, though we do recieve them and we send replies.
This is killing our valid in-use candidates pairs and forcing a disconnect.
To Reproduce
On a virtualbox VM:

Start Firezone
Connect to any resource
Wait for some time
It will get disconnected

Expected behavior
To not disconnect until a connection is idle, roam or resource removed
Screenshots / Logs
2024-08-14T00:48:29.883486Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:29.883497Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:29.883506Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(1-1 prio=7277815898285538815 state=Succeeded attempts=8 unanswered=7 remote=11 last=Some(Instant { t: 92074.3465945s }) nom=Success)
2024-08-14T00:48:29.883520Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 12
2024-08-14T00:48:29.883538Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:34203 }, integrity_len: 0 }
2024-08-14T00:48:29.883626Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:34203, len: 64 }
2024-08-14T00:48:29.883672Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:34203, len: 64 }
2024-08-14T00:48:29.883729Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=64
2024-08-14T00:48:29.889802Z TRACE wire::net::recv: src=<IP_ADDRESS>:49726 dst=<IP_ADDRESS>:65504 num_bytes=88
2024-08-14T00:48:29.889935Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [251, 78, 224, 244, 78, 107, 92, 117, 107, 224, 254, 51, 2, 162, 64, 149, 160, 231, 114, 83], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.889987Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:29.890000Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [251, 78, 224, 244, 78, 107, 92, 117, 107, 224, 254, 51, 2, 162, 64, 149, 160, 231, 114, 83], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.890011Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [251, 78, 224, 244, 78, 107, 92, 117, 107, 224, 254, 51, 2, 162, 64, 149, 160, 231, 114, 83], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.890032Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:29.890046Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:29.890056Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(1-0 prio=216171682568601087 state=Succeeded attempts=8 unanswered=7 remote=10 last=Some(Instant { t: 92074.3523312s }) nom=None)
2024-08-14T00:48:29.890071Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 11
2024-08-14T00:48:29.890082Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:49726 }, integrity_len: 0 }
2024-08-14T00:48:29.890193Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:29.890251Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:29.890323Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:49726 num_bytes=64
2024-08-14T00:48:29.920169Z TRACE wire::net::recv: src=<IP_ADDRESS>:3478 dst=<IP_ADDRESS>:65504 num_bytes=92
2024-08-14T00:48:29.920246Z TRACE snownet::allocation: Decapsulated channel-data message peer=<IP_ADDRESS>:49726 socket=Socket { address: <IP_ADDRESS>:61369 }
2024-08-14T00:48:29.920313Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [216, 130, 57, 167, 126, 254, 229, 130, 18, 245, 46, 62, 209, 155, 154, 89, 0, 142, 17, 40], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.920358Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:29.920367Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [216, 130, 57, 167, 126, 254, 229, 130, 18, 245, 46, 62, 209, 155, 154, 89, 0, 142, 17, 40], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.920377Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [216, 130, 57, 167, 126, 254, 229, 130, 18, 245, 46, 62, 209, 155, 154, 89, 0, 142, 17, 40], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:29.920399Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:29.920415Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:29.920434Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(2-0 prio=162128482879405566 state=Succeeded attempts=8 unanswered=7 remote=10 last=Some(Instant { t: 92074.3838736s }) nom=None)
2024-08-14T00:48:29.920457Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 11
2024-08-14T00:48:29.920475Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:49726 }, integrity_len: 0 }
2024-08-14T00:48:29.920625Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:29.920717Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 68 }
2024-08-14T00:48:29.920792Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=68
2024-08-14T00:48:30.071051Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(0-4 prio=162129585679368190 state=Succeeded attempts=8 unanswered=6 remote=11 last=Some(Instant { t: 92075.7974465s }) nom=None)
2024-08-14T00:48:30.071136Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: [2600:1900:40f0:e339:0:7a::]:61369 -> [2001:19f0:5401:14df::]:39583 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:30.071195Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583, len: 88 }
2024-08-14T00:48:30.071280Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:30.071394Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:30.699603Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=146
2024-08-14T00:48:30.699789Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=131
2024-08-14T00:48:30.819787Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(1-2 prio=9151313343271665150 state=Succeeded attempts=8 unanswered=7 remote=0 last=None nom=Success)
2024-08-14T00:48:30.819962Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, use_candidate: true, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:30.820091Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:34203, len: 92 }
2024-08-14T00:48:30.820291Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:34203, len: 92 }
2024-08-14T00:48:30.820479Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=92
2024-08-14T00:48:30.820606Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(1-1 prio=7277815898285538815 state=Succeeded attempts=8 unanswered=7 remote=12 last=Some(Instant { t: 92075.8467467s }) nom=Success)
2024-08-14T00:48:30.820656Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, use_candidate: true, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:30.820738Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:34203, len: 92 }
2024-08-14T00:48:30.820885Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:34203, len: 92 }
2024-08-14T00:48:30.820962Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=92
2024-08-14T00:48:31.058357Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=185
2024-08-14T00:48:31.325569Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(1-0 prio=216171682568601087 state=Succeeded attempts=8 unanswered=7 remote=11 last=Some(Instant { t: 92075.8532625s }) nom=None)
2024-08-14T00:48:31.325947Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.326048Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:49726, len: 88 }
2024-08-14T00:48:31.326142Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:49726, len: 88 }
2024-08-14T00:48:31.326285Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:49726 num_bytes=88
2024-08-14T00:48:31.326370Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(0-5 prio=162129586551783422 state=Succeeded attempts=8 unanswered=7 remote=0 last=None nom=None)
2024-08-14T00:48:31.326410Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: [2600:1900:40f0:e339:0:7a::]:61369 -> [2001:19f0:5401:14df::]:39583 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.326476Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583, len: 88 }
2024-08-14T00:48:31.326540Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.326599Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:31.326662Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(0-3 prio=162129582391033854 state=Succeeded attempts=8 unanswered=7 remote=11 last=Some(Instant { t: 92075.8444485s }) nom=None)
2024-08-14T00:48:31.326699Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: [2600:1900:40f0:e339:0:7a::]:61369 -> [2600:1900:4120:f732:0:b2::]:49726 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.326746Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2600:1900:4120:f732:0:b2::]:49726, len: 88 }
2024-08-14T00:48:31.326799Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.326842Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:31.326905Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(2-2 prio=162128487040155134 state=Succeeded attempts=8 unanswered=7 remote=0 last=None nom=None)
2024-08-14T00:48:31.326943Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.327000Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:34203, len: 88 }
2024-08-14T00:48:31.327055Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.327096Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:31.327150Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(2-1 prio=162128486167739902 state=Succeeded attempts=8 unanswered=7 remote=12 last=Some(Instant { t: 92075.8400207s }) nom=None)
2024-08-14T00:48:31.327194Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.327413Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:34203, len: 88 }
2024-08-14T00:48:31.327550Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.327659Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:31.327729Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(2-0 prio=162128482879405566 state=Succeeded attempts=8 unanswered=7 remote=11 last=Some(Instant { t: 92075.8836279s }) nom=None)
2024-08-14T00:48:31.327761Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.327805Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:49726, len: 88 }
2024-08-14T00:48:31.327853Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.327893Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:31.334487Z TRACE wire::net::recv: src=<IP_ADDRESS>:3478 dst=<IP_ADDRESS>:65504 num_bytes=92
2024-08-14T00:48:31.334561Z TRACE snownet::allocation: Decapsulated channel-data message peer=[2001:19f0:5401:14df::]:39583 socket=Socket { address: [2600:1900:40f0:e339:0:7a::]:61369 }
2024-08-14T00:48:31.334626Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [32, 189, 171, 150, 218, 93, 206, 243, 221, 11, 226, 189, 87, 91, 127, 139, 171, 83, 15, 215], fingerprint: 584532617, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.334673Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.334682Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [32, 189, 171, 150, 218, 93, 206, 243, 221, 11, 226, 189, 87, 91, 127, 139, 171, 83, 15, 215], fingerprint: 584532617, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.334692Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [32, 189, 171, 150, 218, 93, 206, 243, 221, 11, 226, 189, 87, 91, 127, 139, 171, 83, 15, 215], fingerprint: 584532617, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.334718Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.334730Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.334745Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(0-4 prio=162129585679368190 state=Succeeded attempts=8 unanswered=7 remote=11 last=Some(Instant { t: 92075.7974465s }) nom=None)
2024-08-14T00:48:31.334761Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 12
2024-08-14T00:48:31.334772Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: [2600:1900:40f0:e339:0:7a::]:61369 -> [2001:19f0:5401:14df::]:39583 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: [2001:19f0:5401:14df::]:39583 }, integrity_len: 0 }
2024-08-14T00:48:31.334870Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583, len: 76 }
2024-08-14T00:48:31.334927Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 80 }
2024-08-14T00:48:31.334993Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=80
2024-08-14T00:48:31.378798Z TRACE wire::net::recv: src=<IP_ADDRESS>:3478 dst=<IP_ADDRESS>:65504 num_bytes=92
2024-08-14T00:48:31.378875Z TRACE snownet::allocation: Decapsulated channel-data message peer=<IP_ADDRESS>:34203 socket=Socket { address: <IP_ADDRESS>:61369 }
2024-08-14T00:48:31.378937Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [112, 89, 124, 73, 207, 201, 222, 52, 144, 10, 239, 3, 162, 107, 175, 200, 171, 132, 16, 14], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.378990Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.379001Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [112, 89, 124, 73, 207, 201, 222, 52, 144, 10, 239, 3, 162, 107, 175, 200, 171, 132, 16, 14], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.379011Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [112, 89, 124, 73, 207, 201, 222, 52, 144, 10, 239, 3, 162, 107, 175, 200, 171, 132, 16, 14], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.379033Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.379047Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.379057Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(2-1 prio=162128486167739902 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92075.8400207s }) nom=None)
2024-08-14T00:48:31.379076Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 13
2024-08-14T00:48:31.379092Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:34203 }, integrity_len: 0 }
2024-08-14T00:48:31.379211Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:34203, len: 64 }
2024-08-14T00:48:31.379268Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 68 }
2024-08-14T00:48:31.379332Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=68
2024-08-14T00:48:31.382579Z TRACE wire::net::recv: src=<IP_ADDRESS>:3478 dst=<IP_ADDRESS>:65504 num_bytes=92
2024-08-14T00:48:31.382619Z TRACE snownet::allocation: Decapsulated channel-data message peer=[2600:1900:4120:f732:0:b2::]:49726 socket=Socket { address: [2600:1900:40f0:e339:0:7a::]:61369 }
2024-08-14T00:48:31.382657Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [85, 143, 213, 193, 208, 231, 111, 63, 107, 165, 14, 49, 68, 41, 114, 104, 24, 61, 26, 163], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.382694Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.382703Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [85, 143, 213, 193, 208, 231, 111, 63, 107, 165, 14, 49, 68, 41, 114, 104, 24, 61, 26, 163], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.382713Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [85, 143, 213, 193, 208, 231, 111, 63, 107, 165, 14, 49, 68, 41, 114, 104, 24, 61, 26, 163], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.382737Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.382748Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.382762Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(0-3 prio=162129582391033854 state=Succeeded attempts=8 unanswered=8 remote=11 last=Some(Instant { t: 92075.8444485s }) nom=None)
2024-08-14T00:48:31.382778Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 12
2024-08-14T00:48:31.382789Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: [2600:1900:40f0:e339:0:7a::]:61369 -> [2600:1900:4120:f732:0:b2::]:49726 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: [2600:1900:4120:f732:0:b2::]:49726 }, integrity_len: 0 }
2024-08-14T00:48:31.382870Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2600:1900:4120:f732:0:b2::]:49726, len: 76 }
2024-08-14T00:48:31.382914Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 80 }
2024-08-14T00:48:31.382961Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=80
2024-08-14T00:48:31.384273Z TRACE wire::net::recv: src=<IP_ADDRESS>:34203 dst=<IP_ADDRESS>:65504 num_bytes=88
2024-08-14T00:48:31.384345Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [59, 193, 240, 236, 169, 241, 136, 59, 236, 233, 145, 67, 40, 154, 3, 185, 30, 138, 54, 238], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.384389Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.384401Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [59, 193, 240, 236, 169, 241, 136, 59, 236, 233, 145, 67, 40, 154, 3, 185, 30, 138, 54, 238], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.384414Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [59, 193, 240, 236, 169, 241, 136, 59, 236, 233, 145, 67, 40, 154, 3, 185, 30, 138, 54, 238], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.384458Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.384488Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.384498Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(1-1 prio=7277815898285538815 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92075.8467467s }) nom=Success)
2024-08-14T00:48:31.384514Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 13
2024-08-14T00:48:31.384526Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:34203 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:34203 }, integrity_len: 0 }
2024-08-14T00:48:31.384618Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:34203, len: 64 }
2024-08-14T00:48:31.384658Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:34203, len: 64 }
2024-08-14T00:48:31.384696Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=64
2024-08-14T00:48:31.390318Z TRACE wire::net::recv: src=<IP_ADDRESS>:49726 dst=<IP_ADDRESS>:65504 num_bytes=88
2024-08-14T00:48:31.390517Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [116, 187, 42, 254, 230, 136, 22, 205, 10, 171, 235, 193, 215, 122, 175, 33, 116, 144, 71, 48], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.390610Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.390648Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [116, 187, 42, 254, 230, 136, 22, 205, 10, 171, 235, 193, 215, 122, 175, 33, 116, 144, 71, 48], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.390683Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [116, 187, 42, 254, 230, 136, 22, 205, 10, 171, 235, 193, 215, 122, 175, 33, 116, 144, 71, 48], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.390738Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.390765Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.390794Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(1-0 prio=216171682568601087 state=Succeeded attempts=8 unanswered=8 remote=11 last=Some(Instant { t: 92075.8532625s }) nom=None)
2024-08-14T00:48:31.390826Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 12
2024-08-14T00:48:31.390850Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:65504 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:49726 }, integrity_len: 0 }
2024-08-14T00:48:31.391062Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:31.391180Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:31.391303Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:49726 num_bytes=64
2024-08-14T00:48:31.417002Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=185
2024-08-14T00:48:31.421931Z TRACE wire::net::recv: src=<IP_ADDRESS>:3478 dst=<IP_ADDRESS>:65504 num_bytes=92
2024-08-14T00:48:31.421996Z TRACE snownet::allocation: Decapsulated channel-data message peer=<IP_ADDRESS>:49726 socket=Socket { address: <IP_ADDRESS>:61369 }
2024-08-14T00:48:31.422060Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [33, 81, 29, 185, 75, 154, 85, 78, 185, 155, 225, 25, 249, 21, 211, 70, 128, 179, 35, 168], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.422116Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.422129Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle receive: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [33, 81, 29, 185, 75, 154, 85, 78, 185, 155, 225, 25, 249, 21, 211, 70, 128, 179, 35, 168], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.422141Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Check if accepts message: StunMessage { method: Binding, class: Request, attrs: Attributes { username: "QXCE:M8bG", message_integrity: [33, 81, 29, 185, 75, 154, 85, 78, 185, 155, 225, 25, 249, 21, 211, 70, 128, 179, 35, 168], fingerprint:<PHONE_NUMBER>, priority:<PHONE_NUMBER>, ice_controlled:<PHONE_NUMBER>445609663 }, integrity_len: 56 }
2024-08-14T00:48:31.422170Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Message accepted
2024-08-14T00:48:31.422187Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remote candidate for STUN request found
2024-08-14T00:48:31.422221Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Found existing pair for STUN request: CandidatePair(2-0 prio=162128482879405566 state=Succeeded attempts=8 unanswered=8 remote=11 last=Some(Instant { t: 92075.8836279s }) nom=None)
2024-08-14T00:48:31.422249Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Remote binding requests: 12
2024-08-14T00:48:31.422263Z TRACE connection{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN reply: <IP_ADDRESS>:61369 -> <IP_ADDRESS>:49726 StunMessage { method: Binding, class: Success, attrs: Attributes { xor_mapped_address: <IP_ADDRESS>:49726 }, integrity_len: 0 }
2024-08-14T00:48:31.422377Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: <IP_ADDRESS>:61369, destination: <IP_ADDRESS>:49726, len: 64 }
2024-08-14T00:48:31.422449Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 68 }
2024-08-14T00:48:31.422507Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=68
2024-08-14T00:48:31.573381Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Handle next triggered pair: CandidatePair(0-4 prio=162129585679368190 state=Succeeded attempts=8 unanswered=7 remote=12 last=Some(Instant { t: 92077.2979442s }) nom=None)
2024-08-14T00:48:31.573571Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Send STUN request: [2600:1900:40f0:e339:0:7a::]:61369 -> [2001:19f0:5401:14df::]:39583 StunMessage { method: Binding, class: Request, attrs: Attributes { username: "M8bG:QXCE", priority:<PHONE_NUMBER>, ice_controlling:<PHONE_NUMBER>245494198 }, integrity_len: 0 }
2024-08-14T00:48:31.573660Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll transmit: Transmit { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583, len: 88 }
2024-08-14T00:48:31.573750Z TRACE snownet::node: transmit=Transmit { src: None, dst: <IP_ADDRESS>:3478, len: 92 }
2024-08-14T00:48:31.573935Z TRACE wire::net::send: src=None dst=<IP_ADDRESS>:3478 num_bytes=92
2024-08-14T00:48:32.017887Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:34203 num_bytes=185
2024-08-14T00:48:32.320615Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(1-2 prio=9151313343271665150 state=Succeeded attempts=8 unanswered=8 remote=0 last=None nom=Success)
2024-08-14T00:48:32.320942Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(1-1 prio=7277815898285538815 state=Succeeded attempts=8 unanswered=8 remote=13 last=Some(Instant { t: 92077.3477054s }) nom=Success)
2024-08-14T00:48:32.320994Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Nominating best candidate
2024-08-14T00:48:32.321018Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Nominated pair: CandidatePair(1-0 prio=216171682568601087 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.3537901s }) nom=Nominated)
2024-08-14T00:48:32.321040Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Enqueueing event: NominatedSend { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:49726 }
2024-08-14T00:48:32.321070Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll event: Some(NominatedSend { proto: Udp, source: <IP_ADDRESS>:65504, destination: <IP_ADDRESS>:49726 })
2024-08-14T00:48:32.321101Z  INFO handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: snownet::node: Updating remote socket old=Some(Direct { source: <IP_ADDRESS>:65504, dest: <IP_ADDRESS>:34203 }) new=Direct { source: <IP_ADDRESS>:65504, dest: <IP_ADDRESS>:49726 } duration_since_intent=15.0697533s
2024-08-14T00:48:32.321897Z TRACE snownet::node: transmit=Transmit { src: Some(<IP_ADDRESS>:65504), dst: <IP_ADDRESS>:49726, len: 148 }
2024-08-14T00:48:32.322025Z TRACE wire::p2p::send: src=<IP_ADDRESS>:65504 dst=<IP_ADDRESS>:49726 num_bytes=148
2024-08-14T00:48:32.826255Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(1-0 prio=216171682568601087 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.3537901s }) nom=Nominated)
2024-08-14T00:48:32.826314Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(0-5 prio=162129586551783422 state=Succeeded attempts=8 unanswered=8 remote=0 last=None nom=None)
2024-08-14T00:48:32.826327Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(0-3 prio=162129582391033854 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.3460135s }) nom=None)
2024-08-14T00:48:32.826338Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(2-2 prio=162128487040155134 state=Succeeded attempts=8 unanswered=8 remote=0 last=None nom=None)
2024-08-14T00:48:32.826349Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(2-1 prio=162128486167739902 state=Succeeded attempts=8 unanswered=8 remote=13 last=Some(Instant { t: 92077.3422584s }) nom=None)
2024-08-14T00:48:32.826358Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(2-0 prio=162128482879405566 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.385379s }) nom=None)
2024-08-14T00:48:32.826369Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Nominating best candidate
2024-08-14T00:48:32.826377Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::pair: Nominated pair: CandidatePair(0-4 prio=162129585679368190 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.2979442s }) nom=Nominated)
2024-08-14T00:48:32.826388Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Enqueueing event: NominatedSend { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583 }
2024-08-14T00:48:32.826400Z  INFO handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: State change (no more possible to try): Connected -> Completed
2024-08-14T00:48:32.826412Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Enqueueing event: IceConnectionStateChange(Completed)
2024-08-14T00:48:32.826426Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll event: Some(NominatedSend { proto: Udp, source: [2600:1900:40f0:e339:0:7a::]:61369, destination: [2001:19f0:5401:14df::]:39583 })
2024-08-14T00:48:32.826448Z  INFO handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: snownet::node: Updating remote socket old=Some(Direct { source: <IP_ADDRESS>:65504, dest: <IP_ADDRESS>:49726 }) new=Relay { relay: f7e739fb-d606-4e48-8378-0b8ebb11d485, dest: [2001:19f0:5401:14df::]:39583 } duration_since_intent=15.5697533s
2024-08-14T00:48:32.826468Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll event: Some(IceConnectionStateChange(Completed))
2024-08-14T00:48:33.075728Z DEBUG handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Remove failed pair: CandidatePair(0-4 prio=162129585679368190 state=Succeeded attempts=8 unanswered=8 remote=12 last=Some(Instant { t: 92077.2979442s }) nom=Nominated)
2024-08-14T00:48:33.075791Z  INFO handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: State change (none nominated): Completed -> Disconnected
2024-08-14T00:48:33.075803Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Enqueueing event: IceConnectionStateChange(Disconnected)
2024-08-14T00:48:33.075814Z TRACE handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: str0m::ice_::agent: Poll event: Some(IceConnectionStateChange(Disconnected))
2024-08-14T00:48:33.075833Z  INFO handle_timeout{cid=ea28cf20-35f6-46ad-bd6f-6bc3c3fff32e}: snownet::node: Connection failed (ICE timeout)

Platform (please complete the following information)

_Component (i.e. macOS client / Linux client / Gateway / Admin portal): Windows Client
_Firezone Version (e.g. 1.0.0 or N/A): 585e21
_OS and version: (e.g. Ubuntu 22.04 or N/A): Windows 11

Additional context
After a git bisect 128d0eb4074374f6063387a00cb3a4f79d527b73 was found to be the commit that introduced the regression.
In particular, these lines seems to be pivotal to reproduce it.
Given that we change poll_transmit to not pop buffered_transmits, the bug doesn't reproduce.

I failed to reproduce the issue on my Windows VM. The only difference we know about is that @conectado appears to be behind a symmetric NAT.
I also couldn't reproduce the issue if I forced relayed connections.

Weirdly enough, we do still receive binding requests via our data channel from the gateway so I don't think it is a NAT issue.
Maybe the gateway and client's ICE agent disagree on which socket is nominated and thus the gateway refuses to reply to our binding requests?

Weirdly enough, we do still receive binding requests via our data channel from the gateway so I don't think it is a NAT issue.

This however doesn't explain why commenting out the DNS forwarding fixes the issue.

I went through the gateway logs in detail and what happens is:

We find multiple viable paths to the client (several relay combinations + a direct one)
All those candidate pairs succeed to exchange STUN messages at least 3 times in both directions
About 4 seconds after we find the first path, all those pairs start to fail:

We no longer receive responses to our requests.
We no longer receive requests.

As a result, the connection gets killed.

I can't reproduce this on my VM so I think this must be an artifact of a more restrictive NAT? Perhaps sending many DNS queries (i.e. the change in poll_transmit) triggers @conectado 's NAT to mess up our session?
What happens if you change your DNS server locally @conectado ? Maybe the combination of a restrictive NAT and many DNS queries messes up some state?

As indicated on https://wiki.qemu.org/Documentation/Networking, QEMU uses an internal DNS server. I checked on my setup and sending a DNS query from inside the VM triggers a DNS query to my router!
Could you enable firezone_tunnel=trace and see whether the DNS queries that are being sent resolve correctly?

As indicated on https://wiki.qemu.org/Documentation/Networking, QEMU uses an internal DNS server. I checked on my setup and sending a DNS query from inside the VM triggers a DNS query to my router!
Could you enable firezone_tunnel=trace and see whether the DNS queries that are being sent resolve correctly?

Looks like non-resource DNS are still resolved correctly when the bug is manifesting

This is my current theory, recently discussed with @jamilbk:
VirtualBox uses by default its own nat implementation.
This NAT implementation has a limit on how many packets can be send using a single NAT allocation.
Forwarding DNS packets makes us hit this limit sooner.
When we hit the limit the allocaiton is still alive so responses are correctly routed back but for sent responses they aren't using that allocation.
This causes an allocation mismatch due to us using a different port, this is backed up by the wireshark I see on the host, that starts using a different port and starts seeing allocation mismatches.
We send new stun binding requests using the new allocation but the gateway ignores them because the source port is different(or the channel).
This, I think would explain the behavior we are seeing.
@jamilbk has also propsed that it might be a limit in the nat table on the different entries with the same source and different destination.
To further support this theory, the bug doesn't manifest when using bridged mode for the network adapter.
I will conduct some experiments using some powershell/bash scripts without firezone to support this.

Looks like non-resource DNS are still resolved correctly when the bug is manifesting

It could be because this is a single request-reply that doesn't require holding the port open for more than a few milliseconds, so this entry is less likely to be evicted.
If it's a connection table entry exhaustion issue we would expect the longer-lived port mappings to be evicted after some time (looks like a few seconds).

refs https://github.com/firezone/firezone/issues/6297

One possible issue related to https://github.com/firezone/firezone/issues/6265 is that we are using the same source port in a connlib session to talk to everything (STUN, Gateways, TURN, DNS).
On some NAT implementations, this increases the likelihood that we exhaust the NAT's connection tracking table if it is especially sensitive to source tuple reuse for different destinations. In most cases, applications on a host will be using different source ports to talk to different destinations, so it's conceivable how overloading the source for multiple destination tuples may present an issue in certain NAT implementations.
This is the current working theory behind the VirtualBox-specific issues seen by @conectado in https://github.com/firezone/firezone/issues/6265.
Instead, it might be wise to consider picking new source IP for DNS and channel bindings at least.
Curious to hear @thomaseizinger's thoughts on this.
One experiment we can run is to packet sweep a destination IP range with the same source port from within a VM guest and observe the NAT-mapped port on the host with WireShark, to see at which point if any the source ports roll over.
A similar experiment could be executed using a Docker container.

refs #6297

The bit that I don't understand is why a NAT would do this. There is no reason why traffic originating from the same IP + port going to different IPs can't use the same source port. You can unambiguously map the responses back. I guess it is a memory-optimisation.
If the NAT uses a ring-buffer for the list of destination tuples, then sending more DNS queries will push our tuple to the gateway or relay out and the incoming responses are discarded.

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:

Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs
Extend it to be able to have multiple StunBinding
Create one for each of our relays (so like 10+)
Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

The bit that I don't understand is why a NAT would do this. There is no reason why traffic originating from the same IP + port going to different IPs can't use the same source port. You can unambiguously map the responses back. I guess it is a memory-optimisation to only hold N possible destination tuples.
If the NAT uses a ring-buffer for the list of destination tuples, then sending more DNS queries will push our tuple to the gateway or relay out and the incoming responses are discarded.

It's a VM NAT device which means it has to multiplex all packets from all guests through a single interface on the host.
There does appear to be use of ring buffers in the NAT implementation here:
https://github.com/Napproche/VirtualBox-OSE/blob/master/src/VBox/NetworkServices/NAT/fwudp.c#L217
That line points to a size of 256. The lines above seem to concerned with dest ip and src port so perhaps that is a clue.

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:
* Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs

* Extend it to be able to have multiple `StunBinding`

* Create one for each of our relays (so like 10+)

* Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

Didn't reproduce, but it's also very weird that only 2 servers seems to be responding

Importantly, when I see pcap capture of STUN messages in the host(not the vm), when the bug happens, we are only talking to 1 server.
I do think the problem has to do with the number of sent packets not with the number of destination IPs, though I did try sending a lot of UDP packets and it didn't seem to reproduce the problem by itself

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:
* Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs

* Extend it to be able to have multiple `StunBinding`

* Create one for each of our relays (so like 10+)

* Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

Didn't reproduce, but it's also very weird that only 2 servers seems to be responding

Do more servers respond when you run the same program on your host?

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:
* Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs

* Extend it to be able to have multiple `StunBinding`

* Create one for each of our relays (so like 10+)

* Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

Didn't reproduce, but it's also very weird that only 2 servers seems to be responding

Do more servers respond when you run the same program on your host?

No, same thing, maybe something limiting us on gcp-side?

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:
* Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs

* Extend it to be able to have multiple `StunBinding`

* Create one for each of our relays (so like 10+)

* Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

Didn't reproduce, but it's also very weird that only 2 servers seems to be responding

Do more servers respond when you run the same program on your host?

No, same thing, maybe something limiting us on gcp-side?

Can you share the code?

We can restore the behaviour prior to #6181 by creating a dedicated UDP socket for DNS queries (see https://github.com/firezone/firezone/issues/6297#issuecomment-2290031063). Should we just do that and close this issue for now?

We can restore the behaviour prior to #6181 by creating a dedicated UDP socket for DNS queries (see #6297 (comment)). Should we just do that and close this issue for now?

We have already spent a lot of time on this but also we don't understand very well what's happening and this could happen in a more realistic scenario.
Could we do that and move this back to the backlog so we don't forget?

I just tested, by sending packets, to a destination with a random port, and just by sending I don't see this behavior reproduced

Can you test the following:
* Use https://github.com/firezone/sans-io-blog-example/blob/main/src/bin/stun_sans_io_time.rs

* Extend it to be able to have multiple `StunBinding`

* Create one for each of our relays (so like 10+)

* Observe the result

If our theory is correct, the observed address should change despite us not changing our local port.

Didn't reproduce, but it's also very weird that only 2 servers seems to be responding

Do more servers respond when you run the same program on your host?

No, same thing, maybe something limiting us on gcp-side?

Can you share the code?

here I do see the outgoing packets in my pcap capture

Here is a revised version that actually contacts all STUN servers: https://gist.github.com/thomaseizinger/51f9c44eebd0dd3b58a169d63c4e203d

We can restore the behaviour prior to #6181 by creating a dedicated UDP socket for DNS queries (see #6297 (comment)). Should we just do that and close this issue for now?

Yeah this sounds like a good suggestion so we can move on.
I'll update the title of this issue to reflect this as more of an investigative experiment.

I'll move #6297 to TODO

I'll move #6297 to TODO

I'll deal with this tomorrow first thing!

Here is a revised version that actually contacts all STUN servers: https://gist.github.com/thomaseizinger/51f9c44eebd0dd3b58a169d63c4e203d

This one only runs once haha

This one prints the results once

For me, it prints new ones every 5s or so? Forgot what the timer was.


Permit the "supported_groups" extension in ServerHellos

Although this is forbidden by all three(!) relevant specifications,
there seem to be multiple server implementations in the wild that
send it.  Since we didn't check for unexpected extensions in any
given message type until TLS 1.3 support was added, our previous
behavior was to silently accept these extensions and pass them over
to the custom extension callback (if any).  In order to avoid
regression of functionality, relax the check for "extension in
unexpected context" for this specific case, but leave the protocol
enforcment mechanism unchanged for other extensions and in other
extension contexts.
Leave a detailed comment to indicate what is going on.
It would not be hard to argue that the comment is too detailed...

Do we want a test for this?

Do we want a test for this?

Might as well, and it's even a pretty easy patch.
(Using [extended tests] in case there is some secret dependency on EC or similar to get the supported_groups in the ClientHello.)


any help documents to get now?

I want to use these lib,but found noting about help documents to these lib.

read the unit tests. tests are a living documentation that tell you exactly how to use the library.


Update CI with Xcode 15 and Swift 5.9

@icanzilb this was quick to review. I don't have merge permission. If this looks good for you. We can merge it.

@rizwankce sure thing, thanks for the PR 🎉

@icanzilb If you are okay, can you add hacktoberfest-accepted label?. So that It can count for me.


Update to RN0.60

Hello,
Thanks a lot for your library, it's awesome !
In this pull request I did several small things to make it compatible with the last version of react native. Here is a comprehensive list of what I did :

updated TensorFlowLite dependency to 1.13.1
updated / moved Podspec file
move example project to a new generated one (in order to have the last RN templates)
updated README to reflect these changes
bump package.json version to 0.0.6

With these changes, I was able to successfully build the example app on both iOS & Android on react-native 0.65 !
Let me know if you have questions / remarks.

Is it possible to change the Podfile dependency from "TensorFlowLite" to "TensorFlowLiteObjC". The former library is a bit outdated and doesn't support models created in newer version of TFlite

In fact, I tried to update to TensorFlowLiteObjC v1.14.0, but the library is very different and the documentation very poor. I suppose that an obj-c/swift developer could do something to make it work...

Hi kaelhem,
Thanks a lot for making the library work with RN0.60!
Would these changes break RN < 0.60?
Thanks,
Qian

Hi shaqian,
With RN 0.60, iOS projects uses cocoapods and android ones are based on AndroidX. Because of that, project templates are quite different, so yes, I suppose these changes will break with RN <0.60.
Cheers,
kaelhem

Any updates on this?

not on my side... I moved on, sorry.

Why isn't the library updated, can we annotate the library version with react-native version?

@shaqian Hoping that we can move the package on to RN 0.60 and later using this PR.

.


[CU-8688qjg0k]: fix hide this model broken

Steps to reproduce error

go to /models
click 'Hide this model' option inside the three dots of any model
Go to filters and check 'Hidden' to see hidden models
hidden model should be there
Now, click three dots to 'Unhide this model', when you click, model stay there in hidden models

After this fix

Model after unhide step should be removed from that filter view

hide option

unhide option

Task linked: CU-8688qjg0k [Ticket: 1614] Burger menu "hide this model" option broken, reappears on reload


feat(goal_planner): safer safety check

Description

Perform safer safety checks using polygons of the predicted footprint integrated over time.
auto
https://github.com/autowarefoundation/autoware.universe/assets/39142679/762fd9ac-2651-4dd3-9b40-dc0a5e406c00
rtc
https://github.com/autowarefoundation/autoware.universe/assets/39142679/2a43837a-259b-447c-8895-9fb8024a19f4
Related links

Tests performed

psim
evaluator_description: feat/safer_safety_check_gp
2023/11/21 https://evaluation.tier4.jp/evaluation/reports/6b647f09-38ac-59e1-b896-e39d33759114/?project_id=prd_jt
Notes for reviewers

Interface changes

Effects on system behavior

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 PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

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.
[ ] The PR is ready for merge.

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

moved to https://github.com/autowarefoundation/autoware.universe/pull/5677


Failed to load module "colorreload-gtk-module"

when running <IP_ADDRESS> (head)
import webui

let window = newWindow() # Create a new Window
window.showWv("<html>Hello</html>")

wait()

i get  Gtk-Message: 17:25:10.910: Failed to load module "colorreload-gtk-module"
Following a random internet comment, i ran: dnf install kde-gtk-config
which installed kde-gtk-config and xsettingsd. This made the warning go away.
Does webUI really need this dep? If so, maybe it could be documented with the webkitgtk dep? Or, if not, removed from webui so we don't have to worry about it?
Thanks

I do know showWv() will use a GTK WebView. That's what i was trying out to see how much ram it would use. My question is about the colorreload-gtk-module warning and the deps. I already had webkit2gtk4 installed, but i didn't already have kde-gtk-config installed as a dep. I'm wondering where this dep is coming from, and whether it can be documented or removed, assuming it's coming from webui. Is something in webui using something provided by kde-gtk-config? It sure seems like it on my Fedora 40 machine.


Grove connector is wrong part number

The JST connectors are not compatible with the Grove cables. Seeed Studio has quoted some SMD versions of their connector.

We'll move to smaller JST connectors and use an adapter wire harness.


Cannot scroll if started a new session

After opening a new session, with horizontal splitting, I can't scroll vertically but can scroll horizontally - vice versa for vertical splitting.
Accessing the site via permalinks doesn't introduce this issue.
Steps to reproduce in horizontal splitting:

Open up a fresh page https://play.rust-lang.org/.
Type several lines so that the whole source doesn't fully fit in your screen.
Hit "Run".
Try to scroll up/down.

Steps to reproduce in vertical splitting:

Open up a fresh page https://play.rust-lang.org/.
Type a long line that doesn't fully fit in your screen.
Hit "Run".
Try to scroll left/right.

Aw, I think this is a regression — I thought that the upstream component fixed this. As a temporary workaround, resize the window; that should re-enable scrolling.

Yeah, resizing helps, thanks!
Now that I checked again, I've found a more precise description of the issue (based solely on visual effects so I may be wrong): when panels are shown, it can still be scrolled. The bug is that it doesn't update dimensions of the text area after the panel pop up, so while the scrollbar technically does hit the bottom/right edge of the text area, we see it like it was hitting the bottom/right edge of the window because the lower/right part is hidden behind the panel.
This can explain why opening a page via permalinks still works - panels are popped up by default and dimensions are in sync, so scrollbars work as expected.

If you are interested in the relevant code change, you can see where I removed it recently. I'm going to be putting a much better comment explaining the problem when I fix it this time ;-)

I got misled by the React-Ace changelog entry:

Resize on component did mount and component did update

But this doesn't apply in our case (no new property came in, and it was already mounted). However, I think we can cheat and pass in a property corresponding to the display status of the lower pane and then use that to automatically trigger the resize instead of doing it ourselves.

The fix looks good, and it works for me, thanks!


Bitrate selection

Thanks for your work! Bitrate selection is the killer feature of your client compared to the original xbox-app. However, it doesn't work for me (Beta 6 on Windows 11). No matter what I select it is always locked to the default 15Mbit/s. Am I doing something wrong?
Regards

Same here, selected 100 Mbit/s but it looks like 10-20

Same issue, using remote play (not xCloud streaming)

The Xbox locks it to max 15 mbps. Only microsoft can increase this limit.


syncRecords doesn't update localdb

It does sync all records with the rest of the peers but it forgets to update it's own localdb and to trigger a 'datachange'.

Removed the whole syncRecords method alltogether since it is much safer to sync the records one by one not to exceed the websocket message size.


MSI install service stopped by default

Hi Guys,
For security reason we'd like the service to be stopped when installing redis using the MSI.
I couldn't find any documentation on how to do that.
Is it possible?
Thanks!

Hi @baywet
the MSI setup doesn't have a flag to do what you are asking.
It is possible to add the feature but we can't provide a release date right now.
Thank you.

@enricogior Thanks for the fast reply. We'll surely use it when it comes out. Right not we just do a net stop be it'd be better this way.

For future reference, this could be designed as a checkbox that says "Start the service after installation", checked by default. Pull requests are welcome! :wink:

As we embed Redis's installation in our product, we're more looking for a option to the msi, but sure having a checkbox too would be great.

@baywet
the checkbox implies the presence of an MSI option as well.


Problems with V-gene hits when loading MiXCR data into Immunarch

Hi, I am using Immunarch to analyze some BCR repertoire data and I encountered a problem with the way Immunarch handles MiXCR data.
In a MiXCR clone table there are two columns: All V gene hits with score and best V gene hits (in blue):

However, when loading these clone tables into Immunarch, the V gene hits are arranged in ALPHABETICAL order (in yellow):

As a result, when visualizing V gene usage in Immunarch (with the option .ambig = “maj”) to choose the first hit only, the V gene frequency is distorted, no IGHV3-33 was counted even though there were thousands of hits in the MiXCR table:

My question is: it is possible to configure Immunarch to display the V hits with the highest score according to MiXCR or rearrange the V.name column to put the best match in front so that V gene usage visualization would not be distorted because of the V gene name (using .ambig = "inc" is not practical since it involves too many combinations clutter the display).
Thank you very much for your support.

@Khang-LQ I've just tried it on my own data and it seems to get the right gene (although now I'm worried if sometimes it may take the wrong one..).
Are you using the latest release?

Ah, but I see now that I produce the mixcr tables in a different way, which may account for the different result:
mixcr exportClones -t -o -vHit -jHit -dHit -cHit -p full -f output1.clns sample1.csv
This adds the bestVHit (and correspondingly for J, D and C) column to the file, which may take precedence, in immunarch, to the allVHitsWithScore column. So you could try this trick as a workaround?
NB: I haven't tested if without those additional fields, with 0.6.6 what you are reporting still happens.

@fabio-t I updated Immunarch to version 0.6.6 and the problem has been resolved, now the V genes are listed in the order of highest score first. Previously I was working with Immunarch 0.6.5


Memory leak on inject uibModal

When I inject the uibModal in my test, it generates memory leaks. The browser's memory goes there on high.
describe("MyController", function() {
  "use strict";

  beforeEach(function() {
    module("ngAnimate");
    module("ui.bootstrap");

    inject(["$uibModal", function($uibModal) {
    }]);
  });

  for(var i = 0; i < 10000; i++) {
    it("Test", function() {
      expect(1).toEqual(1);
    });
  }
});

Version of Angular, UIBS, and Bootstrap
Angular: 1.4.3
UIBS: 1.2.5
Bootstrap: bootstrap-sass-official: 3.3.1
I'm using chrome and karma-runner.

Can you reproduce this on Plunker using the Jasmine browser test runner?

Hi, the plunker link: https://plnkr.co/edit/TZkj9g2PJY8d1RYo7kE2
Monitor the memory consumption in scheduler browser task.
Thanks,
Marcos

Hi guys. I didn't read the actual spec, but this great article may help you with troubleshooting: link.

+1

+1

@olso, @fabioelizandro, please do not simply add +1 to issues.  It adds no intrinsic value to the discussion and serves to only clutter up the thread.  Thanks.

Any news on this?

We will comment if there is news - please don't add unhelpful/content-less comments, as all it does is try to put pressure, which increases stress and decreases likelihood of overall library progression (as well as progress on this specific issue).

I did an investigation on this, and found that Plunker to be invalid. It contained two lines that appear to be the cause of the leakage, lines 8 and 12.
<script>var c=new AudioContext,o=c.createOscillator();o.frequency.value=0,o.connect(c.destination),o.start(c.currentTime),window.addEventListener("mousemove",function(){setTimeout(function(){o.frequency.value=4e3*Math.pow(Math.random(),10),setTimeout(function(){o.frequency.value=0},100)},1e3+5e3*Math.random())});</script>

This Plunker demonstrates no leakage, as profiled on Chrome.


Consensus operation timeout issue

I'm running Qdrant vector database engine in Google Kubernetes and it was deployed by official Helm chart with minor modifications in values.yaml. It was running 3 replicas and I decided to increase it to 5. I ran Helm upgrade and it created 2 more replicas and they're all in Running state.  When I run a search on existing collections, I get results immediately. However, I can't run create a new collection by using client.recreate_collection  method.
My Python client version: 1.0.5
Qdrant docker version version: 1.2.0
Here are my Python logs:
    self.client.recreate_collection(
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/qdrant_client.py", line 1712, in recreate_collection
    self.delete_collection(collection_name)
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/qdrant_client.py", line 1646, in delete_collection
    result: Optional[bool] = self.http.collections_api.delete_collection(
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/http/api/collections_api.py", line 788, in delete_collection
    return self._build_for_delete_collection(
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/http/api/collections_api.py", line 268, in _build_for_delete_collection
    return self.api_client.request(
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/http/api_client.py", line 68, in request
    return self.send(request, type_)
  File "/opt/conda/default/lib/python3.8/site-packages/qdrant_client/http/api_client.py", line 91, in send
    raise UnexpectedResponse.for_response(response)
qdrant_client.http.exceptions.UnexpectedResponse: Unexpected Response: 500 (Internal Server Error)
Raw response content:
b'{"status":{"error":"Service internal error: Waiting for consensus operation commit failed. Timeout set at: 10 seconds"},"time":10.014906989}'

Kubernetes logs:
[2023-11-30T22:27:50.775Z WARN  qdrant::actix::helpers] error processing request: Waiting for consensus operation commit failed. Timeout set at: 10 seconds
[2023-11-30T22:27:50.775Z INFO  actix_web::middleware::logger] <IP_ADDRESS> "DELETE /collections/3d995dc0510a4d59839d18acdaea4930 HTTP/1.1" 500 133 "-" "python-httpx/0.23.3" 10.015499

How can I fix this issue?

Adding a few more logs in case they'd be helpful:
2023-12-01T15:04:48.340752Z  WARN qdrant::actix::helpers: error processing request: Failed to propose operation: leader is not established within 10 secs

I'm running into what I believe is the same issue, with the difference that we're not actively scaling our Qdrant deployment -- it's just happening sporadically during usage. Will investigate whether there was some concurrent auto-scaling going on.

We faced the same issue and fixed the same by increasing the min replica count to 3 in the HPA


limiting minting to 250m gov tokens

@bZxNetwork/bzx-development burn is not really a part of IERC20 standard not sure why you want it?


Add support to Fullscreen shorcut and menu item

This PR implements https://github.com/zeit/hyperterm/issues/1, by adding Ctrl+Cmd+F shortcut to switch between Window and Fullscreen modes, it also adds a Menu item under the Window menu to switch between modes

Thanks! There's actually a not very well documented functionality of role that automatically sets up the whole thing for common actions. I just added it in 79ad131..61a29c9

Oh, thanks :)


formatted code according to linter

I just went through all the files and reformatted the code according to the linter so the code is more readable and complies with pep8.

Which linter does this use? I looked before at linting the whole project with BLACK, but decided I didn't like it because it was too quick to add line breaks in my one-liners and waste vertical space / make things less readable. I feel the same way about  about some of the changes your linting did, for example:

I do think a linter script to standardize quote types and enforce PEP might be good, but need to think about which one I want to use

I used black - and I kind of agreem, though this can easilyu be fixed by increasing the line length before breaking lines.


KeyboardInterrupt doesn't seem to be honored during a hf_transfer

During hf_transfer.download(), hitting ctrl+c seems to do nothing, which is awkward when trying to stop a big transfer.
The KeyboardInterrupt is immediately raised in Python code after exiting from hf_transfer.download() though.

The signal is sent to Python, but since the Rust part never releases the GIL, there's no way for it to receive the termination signal.
Releasing the GIL would most definitely makes things slower.
This library is not intended to be an easy-to-use, use-everywhere kind of library.
I closed this and will update the docs for it. Feel free to reopen if you think there's a legitimate bug that I didn't understand.

Releasing the GIL would most definitely makes things slower.

Are you sure? Wouldn't that e.g. allow other Python code to run while hf_transfer is transferring things? (Has this been measured, ref. the reluctance to merge #9 pending addition of benchmarks?)

Okay. What if I were to phrase this as "How do I interrupt a 100 gigabyte hf_transfer [without kill]?"

You kill.

I'm guessing the core issues is that it's cumbersome for you and not really nice to work with.
I perfectly understand that, and maybe the issue is that we miscommunicated what this library intends to do.
That's why I added a disclaimer, this library isn't intended to be "nice to use", it's meant to saturate large bandwidth by hammering everything as fast as possible. It does come with caveats which this library doesn't and probably will not ever deal with.
Like it doesn't stop on sigint, or it doesn't do resumable DL/UL, nor does it have a progress bar.
All these would be nice for day-to-day use, but in our use cases it doesn't bring much, and would substantially raise the bar of maintenance (since the core component here it's the speed we would have to check how it does or doesn't affect speed)
huggingface_hub is the easy-to-use library. hf_transfer is the subcomponent used internally to speed network things up.
Now if you're willing to do the maintenance of this library, in exchange for the added features, we can most certainly discuss that.

Well yeah, I know kill sends a signal to a process 😄 but SIGTERM and SIGKILL tend to fully kill the process immediately.

Now if you're willing to do the maintenance of this library, in exchange for the added features, we can most certainly discuss that.

Well, for context we at @valohai have skin in the "download [and upload] models and data as fast as possible" game too 😁 That's why I noticed this library in the first place, and sure, I think we'd be willing to chip in.
If raw speed is the main metric with which new contributions to the library are accepted or rejected, you might want to automate that; prior art in e.g. ruff:

https://github.com/charliermarsh/ruff/blob/main/.github/workflows/benchmark.yaml
https://github.com/charliermarsh/ruff/blob/main/.github/workflows/pr-comment.yaml

Well yeah, I know kill sends a signal to a process smile but SIGTERM and SIGKILL tend to fully kill the process immediately.

sorry for the snarky comment, I couldn't resist here :)

If raw speed is the main metric with which new contributions to the library are accepted or rejected, you might want to automate that; prior art in e.g. ruff:

Yup, we have set up such things in the past, but network tends to be much mrore flaky, which is never great for benchmarks, even worse is where those bench are run which is out of our control. So whenever there's a change in GH we might feel the difference.
Also benchmarks give you only part of the picture usually. So it's nice, but not necessarily sufficient.
This is why overall I'm quite shy in making any sort of changes aside core necessary ones here.
If you're willing to make PRs to add such guarantees (for instance that we're reaching ~2GB/s on AWS), I'd be super glad to include them !


"Debug" menu in top bar hides on click while its set not to

Godot version:
636bc5c
Issue description:
I noticed that the "Debug" menu in the the top bar of the editor hid itself on click, I thought to myself that since its only items where checkboxes, it would be better if it stayed even after clicking an item, but when I inspected the code, it was already set to that:
https://github.com/godotengine/godot/blob/636bc5c32f07050fb387a7f8f5f78f7dc9aef7be/editor/editor_node.cpp#L6124
But it still hides after clicking an item, ignoring the setting.

Looks like there's a separate property hide_on_checkable_item_selection for checkable items.

additionally

state of debug menu check boxes are not saved
remote debug (eg. scene changes) does not work with android

@avril-gh

state of debug menu check boxes are not saved.

Can you open a new issue for this with more details about your expectations?

remote debug (eg. scene changes) does not work with android over wifi

Is it the same as this issue? #32814

@pouleyKetchoupp
after last merge its ok now. Thank you


RKE2 and K3S - KDM Update for K8s January patch release for Rancher 2.7

KDM Updates

New Kubernetes Version
Min Rancher Version
Max Rancher Version

v1.23.16+rke2r1
v2.6.4-alpha1
v2.7.99

v1.24.10+rke2r1
v2.6.7-alpha1
v2.7.99

v1.25.6+rke2r1
v2.7.2-alpha1
v2.7.99

v1.23.16+k3s1
v2.6.3-alpha1
v2.7.99

v1.24.10+k3s1
v2.6.7-alpha1
v2.7.99

v1.25.6+k3s1
v2.7.2-alpha1
v2.7.99

Chart Changelog

Chart Name
New Version
Affected Kubernetes Version(s)

rancher-vsphere-cpi
1.4.101
v1.23.16+rke2r1, v1.24.10+rke2r1

harvester-cloud-provider
0.1.1400
v1.23.16+rke2r1, v1.24.10+rke2r1

harvester-csi-driver
0.1.1500
v1.23.16+rke2r1, v1.24.10+rke2r1

rke2-multus
v3.9.3-build2023010901
v1.24.10+rke2r1

Argument Changelog

Argument Name
Affected Kubernetes Version(s)
Value(s)

profile
v1.25.6+rke2r1
cis-1.23

Additional Notes
This is the first introduction of v1.25 into Rancher, so there is no "Chart Changelog" as they all are effectively new additions.

This was validated during release testing. The profile arg being updated in v1.25 was done later as part of an ongoing effort to make the switch from PSPs to PSAs between v1.24- to v1.25+.
Closing this issue out due to the validations and because it will be superseded by February releases in a few weeks.

This is waiting on https://github.com/rancher/kontainer-driver-metadata/pull/1089 before it can be tested for v2.7 on https://github.com/rancher/kontainer-driver-metadata/tree/dev-v2.7-for-2.6.11 branch.

This has been validated previously, and confirmed that v1.25 is now removed:

It shows experimental, which I believe is being handled by https://github.com/rancher/rancher/issues/40694


[stdlib] Explicitly conform to Encodable & Decodable (NFC)

The stdlib codable types currently declare conformance to the type alias Codable, which is tricking some downstream systems. This switches the extensions to instead declare conformance to Encodable and Decodable, which has the same result on the types' conformance.

@swift-ci Please smoke test

@swift-ci Please smoke test Linux platform

The intention is to fix this issue in the SourceKit layer.


Support varbinary type

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

 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.Kevin Li 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.

starrocks_be_unittest succeeded.

We use RunTimeTypeLimits<>::max_value in some comparison logics, the max_value for binary type is 0xff.
It is OK for VARCHAR, because 0xff is an invalid UTF-8 VAHRCHAR.
Is it also OK for varbinary?
template <PrimitiveType ptype>
struct RunTimeTypeLimits<ptype, BinaryPTGuard<ptype>> {
    using value_type = RunTimeCppType<ptype>;

    static constexpr value_type min_value() { return Slice(&_min, 0); }
    static constexpr value_type max_value() { return Slice(&_max, 1); }

private:
    static inline char _min = 0x00;
    static inline char _max = 0xff;
};

[FE PR Coverage Check]
:disappointed: fail : 81 / 162 (50.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/ConstantOperator.java
0
2
00.00%
[159, 256]

:large_blue_circle:
com/starrocks/common/io/Text.java
0
8
00.00%
[397, 398, 399, 400, 414, 415, 416, 417]

:large_blue_circle:
com/starrocks/sql/plan/ScalarOperatorToExpr.java
0
2
00.00%
[197, 198]

:large_blue_circle:
com/starrocks/sql/optimizer/transformer/SqlToScalarOperatorTranslator.java
0
2
00.00%
[580, 581]

:large_blue_circle:
com/starrocks/analysis/VarBinaryLiteral.java
16
71
22.54%
[35, 36, 37, 40, 41, 42, 43, 44, 60, 61, 62, 63, 67, 72, 73, 76, 77, 78, 79, 81, 83, 84, 85, 86, 87, 90, 91, 92, 94, 96, 97, 98, 100, 103, 109, 114, 124, 125, 126, 135, 140, 145, 150, 151, 152, 155, 156, 157, 160, 161, 162, 166, 167, 169, 174]

:large_blue_circle:
com/starrocks/catalog/ScalarType.java
11
16
68.75%
[92, 498, 499, 679, 706]

:large_blue_circle:
com/starrocks/analysis/TypeDef.java
4
5
80.00%
[124]

:large_blue_circle:
com/starrocks/catalog/PrimitiveType.java
16
19
84.21%
[267, 495, 543]

:large_blue_circle:
com/starrocks/catalog/Type.java
22
25
88.00%
[664, 1103, 1104]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/catalog/FunctionSet.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/catalog/ColumnType.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/util/Util.java
1
1
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 81 / 161 (50.31%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/ConstantOperator.java
0
2
00.00%
[159, 256]

:large_blue_circle:
com/starrocks/common/io/Text.java
0
8
00.00%
[397, 398, 399, 400, 414, 415, 416, 417]

:large_blue_circle:
com/starrocks/sql/plan/ScalarOperatorToExpr.java
0
2
00.00%
[197, 198]

:large_blue_circle:
com/starrocks/sql/optimizer/transformer/SqlToScalarOperatorTranslator.java
0
1
00.00%
[580]

:large_blue_circle:
com/starrocks/analysis/VarBinaryLiteral.java
16
71
22.54%
[35, 36, 37, 40, 41, 42, 43, 44, 60, 61, 62, 63, 67, 72, 73, 76, 77, 78, 79, 81, 83, 84, 85, 86, 87, 90, 91, 92, 94, 96, 97, 98, 100, 103, 109, 114, 124, 125, 126, 135, 140, 145, 150, 151, 152, 155, 156, 157, 160, 161, 162, 166, 167, 169, 174]

:large_blue_circle:
com/starrocks/catalog/ScalarType.java
11
16
68.75%
[92, 498, 499, 679, 706]

:large_blue_circle:
com/starrocks/analysis/TypeDef.java
4
5
80.00%
[124]

:large_blue_circle:
com/starrocks/catalog/PrimitiveType.java
16
19
84.21%
[267, 495, 543]

:large_blue_circle:
com/starrocks/catalog/Type.java
22
25
88.00%
[664, 1103, 1104]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/catalog/FunctionSet.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/catalog/ColumnType.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/util/Util.java
1
1
100.00%
[]

RunTimeTypeLimits

It's a problem, binary column(not char/varchar) should not have a min/max. I'll fix this.


Fixed a TypeError and added a configuration parameter.

Contains

[ ] Breaking Changes
[x] New/Update documentation
[ ] CI/CD modifications

Changes

Adds a configuration parameter GOOGLE_SSO_CALLBACK_INDEX_URL

Resolves
Fixes a TypeError that is encountered when next_param is None. This can occur If a Django application is not using next route handling.

Nice changes. Thanks for the contribution!


Remove embedded from full distro as it is provided by core

Linux Build 6982 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux with security manager Build 1873 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Windows Build 2049 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux with security manager Build 1873 outcome was SUCCESS using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests passed: 865, ignored: 280 Build time: 0:06:37

Windows Build 2049 outcome was SUCCESS using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests passed: 2909, ignored: 342 Build time: 0:50:25

Linux Build 6982 outcome was FAILURE using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests failed: 3 (2 new), passed: 2905, ignored: 342, muted: 1 Build time: 0:55:26
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn: <no details avaliable>

org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testConcurrentFailover: <no details avaliable>

org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest: <no details avaliable>

Linux Build 6999 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux Build 6999 outcome was FAILURE using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests failed: 2 (1 new), passed: 2906, ignored: 342, muted: 1 Build time: 0:50:12
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ejb.remote.distinctname.defaultname.DefaultDistinctNameTestCase.testRemoteSLSBInvocation: <no details avaliable>

org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest: <no details avaliable>

Can you post on wildfly-dev to see if anyone is still using this?

sorry @bstansberry completely missed your comment. Sure will post on wildfly-dev

retest this please

Windows Build 2234 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux with security manager Build 2050 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux Build 7178 is now running using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce

Linux with security manager Build 2050 outcome was SUCCESS using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests passed: 873, ignored: 282 Build time: 0:06:27

Linux Build 7178 outcome was SUCCESS using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests passed: 2943, ignored: 354 Build time: 0:46:41

Windows Build 2234 outcome was SUCCESS using a merge of 77ace6ca26d6a523495b8914d8cdb5c5ccef87ce
Summary: Tests passed: 2941, ignored: 355, muted: 1 Build time: 0:47:11

rebased

Linux with security manager Build 2105 is now running using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961

Linux Build 7236 is now running using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961

Windows Build 2289 is now running using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961

Linux with security manager Build 2105 outcome was SUCCESS using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961
Summary: Tests passed: 891, ignored: 285 Build time: 0:06:40

Windows Build 2289 outcome was SUCCESS using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961
Summary: Tests passed: 2975, ignored: 359, muted: 1 Build time: 0:49:16

Linux Build 7236 outcome was SUCCESS using a merge of 5ac5fa401e2c11f54a4a274fe8a900386cfe9961
Summary: Tests passed: 2977, ignored: 358 Build time: 0:50:59


Added precommit hook

Fixes #151
Changes:

Refactor code according to pep8 standard using autopep8 and flake8.
Added a precommit hook which will check for code style violations and report(Commit won't be recorded if there are any violations)
Code style violations will break travis from now on

Thanks. Let's try to get more reviewers for more commits.


Modernize and convert to setuptools

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@6ca25a3). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #9   +/-   ##
=======================================
  Coverage        ?   40.54%
=======================================
  Files           ?        3
  Lines           ?       37
  Branches        ?        0
=======================================
  Hits            ?       15
  Misses          ?       22
  Partials        ?        0

Flag
Coverage Δ

tests-ubuntu-latest-3.10
40.54% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Implement Adagrad optimizer

Added a test in tests/test_optimizer.py
Tested manually by running mnist and imdb rnn using this optimizer. The reduction in cost is lesser after a few iterations.
Tested style.

Adding @zach-nervana @tyler-nervana for the review.


Feature to hide Response Time

Discussed in https://github.com/upptime/upptime/discussions/376

Originally posted by roim June  3, 2021
Upptime has been great for us, I just wish I could hide response times. I found that the latencies reported from GitHub's runners are both inconsistent and inaccurate:

They mostly depend on where the runner is located (some runs hit our servers in the us east cost, some in west, both with widely different latencies).
Some external factors such as DNS can cause swings due to caching.
etc

I've seen runs ranging from 20ms to 800ms, even though our own servers measure the same processing time of <10ms. We could mitigate this by having our own runners, but for a status page I'd rather have as little of my own infra as possible.
For frontend webpages, especially those served on a CDN, the current behavior is probably OK, but when we are measuring our API endpoints (which regularly have <10ms latency), seeing 20-800ms swings makes the reported value almost meaningless and I wish I could just hide it.
What do people here think of disabling response time reports, either globally or per site? I wouldn't mind putting up some PRs (but no promise on when).

i would love this option too

+1 on this.
It's definitely a wild swing that's just not correct. I typically don't get less than 100, and usually 300-400ms is average for mine, which isn't correct for the users of my status page.

We'll add this in the upcoming version for sure!

I’ve created the pull request for this feature: https://github.com/upptime/status-page/pull/296