starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2081] IPv6 UDP resolution doesn't work over link-local addresses #876

New issue

Closed

opened 2026-03-16 00:43:17 +03:00 by kerem · 7 comments

kerem commented

2026-03-16 00:43:17 +03:00

Owner

Originally created by @orbekk on GitHub (Oct 29, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2081

Describe the bug

When querying a link-local DNS server over IPv6 UDP, the response is ignored because it's assigned a scope, which fails to match the original dns server requested by the resolver. I can reproduce this with the hickory dns server running locally, and dnsmasq running on my router.

2023-10-29T18:03:49.560905Z  WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141.

It looks like linux assigns a scope whenever it's using a link-local address:

Perhaps the scope should be ignored when matching the socket address?

To Reproduce
Steps to reproduce the behavior:

Edit ./tests/test-data/test_configs/example.toml and add listen_addrs_ipv6 = ["::"].
./target/release/hickory-dns -c ./tests/test-data/test_configs/example.toml -z ./tests/test-data/test_configs -p 24141
Query the link-local address:

$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
3: wlp39s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
[...]
    inet6 fe80::fc41:9ad0:2c20:80f8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ RUST_LOG=trace cargo run --bin resolve -- --udp -n '[fe80::fc41:9ad0:2c20:80f8]:24141' www.example.com -t AAAA                
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `/home/orbekk/projects/hickory-dns/target/debug/resolve --udp -n '[fe80::fc41:9ad0:2c20:80f8]:24141' www.example.com -t AAAA`
2023-10-29T18:08:38.911221Z TRACE hickory_resolver::async_resolver: handle passed back
Querying for www.example.com AAAA from udp:[fe80::fc41:9ad0:2c20:80f8]:24141
2023-10-29T18:08:38.911376Z DEBUG hickory_proto::xfer::dns_handle: querying: www.example.com AAAA
2023-10-29T18:08:38.911410Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:38.911463Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2023-10-29T18:08:38.911544Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:38.911699Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 63187:QUERY:RD:NoError:QUERY:0/0/0
; query
;; www.example.com. IN AAAA

2023-10-29T18:08:38.911868Z DEBUG hickory_proto::udp::udp_stream: created socket successfully
2023-10-29T18:08:38.912008Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512
2023-10-29T18:08:38.912467Z  WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141.
2023-10-29T18:08:43.912987Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out
2023-10-29T18:08:43.913078Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:43.913143Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2023-10-29T18:08:43.913242Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:43.913310Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down
2023-10-29T18:08:43.913397Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 18340:QUERY:RD:NoError:QUERY:0/0/0
; query
;; www.example.com. IN AAAA

2023-10-29T18:08:43.913526Z DEBUG hickory_proto::udp::udp_stream: created socket successfully
2023-10-29T18:08:43.913611Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512
2023-10-29T18:08:43.913917Z  WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141.
2023-10-29T18:08:48.914506Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out
2023-10-29T18:08:48.914611Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:48.914665Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2023-10-29T18:08:48.914756Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:08:48.914839Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down
2023-10-29T18:08:48.914864Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 29043:QUERY:RD:NoError:QUERY:0/0/0
; query
;; www.example.com. IN AAAA

2023-10-29T18:08:48.914976Z DEBUG hickory_proto::udp::udp_stream: created socket successfully
2023-10-29T18:08:48.915066Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512
2023-10-29T18:08:48.915341Z  WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141.
2023-10-29T18:08:53.916794Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out
ResolveError { kind: Timeout }
2023-10-29T18:08:53.917060Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down

Expected behavior
It should return a result, like it does when querying a non-link local address:

RUST_LOG=trace cargo run --bin resolve -- --udp -n '[::1]:24141' www.example.com -t AAAA    
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `/home/orbekk/projects/hickory-dns/target/debug/resolve --udp -n '[::1]:24141' www.example.com -t AAAA`
2023-10-29T18:19:56.259817Z TRACE hickory_resolver::async_resolver: handle passed back
Querying for www.example.com AAAA from udp:[::1]:24141
2023-10-29T18:19:56.259969Z DEBUG hickory_proto::xfer::dns_handle: querying: www.example.com AAAA
2023-10-29T18:19:56.260006Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:19:56.260078Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [::1]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2023-10-29T18:19:56.260163Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }]
2023-10-29T18:19:56.260341Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 61238:QUERY:RD:NoError:QUERY:0/0/0
; query
;; www.example.com. IN AAAA

2023-10-29T18:19:56.260488Z DEBUG hickory_proto::udp::udp_stream: created socket successfully
2023-10-29T18:19:56.260599Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512
2023-10-29T18:19:56.260978Z TRACE hickory_proto::rr::record_data: reading AAAA
2023-10-29T18:19:56.261004Z DEBUG hickory_proto::udp::udp_client_stream: received message id: 61238
2023-10-29T18:19:56.261050Z DEBUG hickory_resolver::error: Response:; header 61238:RESPONSE:RD,AA:NoError:QUERY:1/0/0
; query
;; www.example.com. IN AAAA
; answers 1
www.example.com. 86400 IN AAAA ::1
; nameservers 0
; additionals 0

2023-10-29T18:19:56.261101Z DEBUG hickory_resolver::error: Response:; header 61238:RESPONSE:RD,AA:NoError:QUERY:1/0/0
; query
;; www.example.com. IN AAAA
; answers 1
www.example.com. 86400 IN AAAA ::1
; nameservers 0
; additionals 0

Success for query www.example.com IN AAAA
        www.example.com. 86400 IN AAAA ::1
2023-10-29T18:19:56.261228Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down

System:

OS: Linux
Architecture: x86_64
Version 6.1.58
rustc version: rustc 1.75.0-nightly (e5cfc5547 2023-10-28)

Version:
Crate: resolver
Version: b0c0566483

Additional context
Add any other context about the problem here.

Originally created by @orbekk on GitHub (Oct 29, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2081 **Describe the bug** When querying a link-local DNS server over IPv6 UDP, the response is ignored because it's assigned a scope, which fails to match the original dns server requested by the resolver. I can reproduce this with the hickory dns server running locally, and dnsmasq running on my router. ``` 2023-10-29T18:03:49.560905Z WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141. ``` It looks like linux assigns a scope whenever it's using a link-local address: * https://github.com/torvalds/linux/blob/master/net/ipv6/udp.c#L407C5-L407C24 * https://github.com/torvalds/linux/blob/2af9b20dbb39f6ebf9b9b6c090271594627d818e/include/net/ipv6.h#L571 Perhaps the scope should be ignored when matching the socket address? **To Reproduce** Steps to reproduce the behavior: 1. Edit ./tests/test-data/test_configs/example.toml and add `listen_addrs_ipv6 = ["::"]`. 2. ./target/release/hickory-dns -c ./tests/test-data/test_configs/example.toml -z ./tests/test-data/test_configs -p 24141 3. Query the link-local address: ``` $ ip -6 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 3: wlp39s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 [...] inet6 fe80::fc41:9ad0:2c20:80f8/64 scope link noprefixroute valid_lft forever preferred_lft forever $ RUST_LOG=trace cargo run --bin resolve -- --udp -n '[fe80::fc41:9ad0:2c20:80f8]:24141' www.example.com -t AAAA Finished dev [unoptimized + debuginfo] target(s) in 0.08s Running `/home/orbekk/projects/hickory-dns/target/debug/resolve --udp -n '[fe80::fc41:9ad0:2c20:80f8]:24141' www.example.com -t AAAA` 2023-10-29T18:08:38.911221Z TRACE hickory_resolver::async_resolver: handle passed back Querying for www.example.com AAAA from udp:[fe80::fc41:9ad0:2c20:80f8]:24141 2023-10-29T18:08:38.911376Z DEBUG hickory_proto::xfer::dns_handle: querying: www.example.com AAAA 2023-10-29T18:08:38.911410Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:38.911463Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2023-10-29T18:08:38.911544Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:38.911699Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 63187:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; www.example.com. IN AAAA 2023-10-29T18:08:38.911868Z DEBUG hickory_proto::udp::udp_stream: created socket successfully 2023-10-29T18:08:38.912008Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512 2023-10-29T18:08:38.912467Z WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141. 2023-10-29T18:08:43.912987Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out 2023-10-29T18:08:43.913078Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:43.913143Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2023-10-29T18:08:43.913242Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:43.913310Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down 2023-10-29T18:08:43.913397Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 18340:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; www.example.com. IN AAAA 2023-10-29T18:08:43.913526Z DEBUG hickory_proto::udp::udp_stream: created socket successfully 2023-10-29T18:08:43.913611Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512 2023-10-29T18:08:43.913917Z WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141. 2023-10-29T18:08:48.914506Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out 2023-10-29T18:08:48.914611Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:48.914665Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [fe80::fc41:9ad0:2c20:80f8]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2023-10-29T18:08:48.914756Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:08:48.914839Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down 2023-10-29T18:08:48.914864Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 29043:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; www.example.com. IN AAAA 2023-10-29T18:08:48.914976Z DEBUG hickory_proto::udp::udp_stream: created socket successfully 2023-10-29T18:08:48.915066Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512 2023-10-29T18:08:48.915341Z WARN hickory_proto::udp::udp_client_stream: ignoring response from [fe80::fc41:9ad0:2c20:80f8%3]:24141 because it does not match name_server: [fe80::fc41:9ad0:2c20:80f8]:24141. 2023-10-29T18:08:53.916794Z DEBUG hickory_resolver::name_server::name_server: name_server connection failure: request timed out ResolveError { kind: Timeout } 2023-10-29T18:08:53.917060Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down ``` **Expected behavior** It should return a result, like it does when querying a non-link local address: ``` RUST_LOG=trace cargo run --bin resolve -- --udp -n '[::1]:24141' www.example.com -t AAAA Finished dev [unoptimized + debuginfo] target(s) in 0.08s Running `/home/orbekk/projects/hickory-dns/target/debug/resolve --udp -n '[::1]:24141' www.example.com -t AAAA` 2023-10-29T18:19:56.259817Z TRACE hickory_resolver::async_resolver: handle passed back Querying for www.example.com AAAA from udp:[::1]:24141 2023-10-29T18:19:56.259969Z DEBUG hickory_proto::xfer::dns_handle: querying: www.example.com AAAA 2023-10-29T18:19:56.260006Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:19:56.260078Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: [::1]:24141, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2023-10-29T18:19:56.260163Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("www.example.com"), query_type: AAAA, query_class: IN }] 2023-10-29T18:19:56.260341Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 61238:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; www.example.com. IN AAAA 2023-10-29T18:19:56.260488Z DEBUG hickory_proto::udp::udp_stream: created socket successfully 2023-10-29T18:19:56.260599Z TRACE hickory_proto::udp::udp_client_stream: creating UDP receive buffer with size 512 2023-10-29T18:19:56.260978Z TRACE hickory_proto::rr::record_data: reading AAAA 2023-10-29T18:19:56.261004Z DEBUG hickory_proto::udp::udp_client_stream: received message id: 61238 2023-10-29T18:19:56.261050Z DEBUG hickory_resolver::error: Response:; header 61238:RESPONSE:RD,AA:NoError:QUERY:1/0/0 ; query ;; www.example.com. IN AAAA ; answers 1 www.example.com. 86400 IN AAAA ::1 ; nameservers 0 ; additionals 0 2023-10-29T18:19:56.261101Z DEBUG hickory_resolver::error: Response:; header 61238:RESPONSE:RD,AA:NoError:QUERY:1/0/0 ; query ;; www.example.com. IN AAAA ; answers 1 www.example.com. 86400 IN AAAA ::1 ; nameservers 0 ; additionals 0 Success for query www.example.com IN AAAA www.example.com. 86400 IN AAAA ::1 2023-10-29T18:19:56.261228Z DEBUG hickory_proto::xfer::dns_exchange: io_stream is done, shutting down ``` **System:** - OS: Linux - Architecture: x86_64 - Version 6.1.58 - rustc version: rustc 1.75.0-nightly (e5cfc5547 2023-10-28) **Version:** Crate: resolver Version: b0c05664837684d74d396dae8cceb6171ea4c556 **Additional context** Add any other context about the problem here.

kerem

2026-03-16 00:43:17 +03:00

closed this issue
added the
bug

crate:client

crate:proto

crate:resolver

easy

crate:recursor
labels

kerem commented

2026-03-16 00:43:34 +03:00

Author

Owner

@ReactorScram commented on GitHub (Jan 3, 2024):

Seeing the same problem on Windows 11 after enabling IPv6 on my home router. Might be that I'm passing the wrong IPs into hickory? 🤔

rustc 1.73.0 (cc66ad468 2023-10-03)
x86_64
hickory 0.24

@ReactorScram commented on GitHub (Jan 3, 2024): Seeing the same problem on Windows 11 after enabling IPv6 on my home router. Might be that I'm passing the wrong IPs into hickory? 🤔 - rustc 1.73.0 (cc66ad468 2023-10-03) - x86_64 - hickory 0.24

kerem commented

2026-03-16 00:43:39 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 3, 2024):

Thanks for tracking down the details on this. I think we need to do a comparison on the raw IP and port rather than the IpAddr. I was unaware of the change in Rust 1.69 to start tracking these additional fields on the IpAddr. I'm guessing that if you compile with something pre 1.69 this issue will go away. I think I can get a patch ready for this today, it will likely impact all previous versions.

This is the comparison that needs to be updated:

github.com/hickory-dns/hickory-dns@0d965da4b1/crates/proto/src/udp/udp_client_stream.rs (L333)

@bluejekyll commented on GitHub (Jan 3, 2024): Thanks for tracking down the details on this. I think we need to do a comparison on the raw IP and port rather than the IpAddr. I was unaware of the change in Rust `1.69` to start tracking these additional fields on the IpAddr. I'm guessing that if you compile with something pre `1.69` this issue will go away. I think I can get a patch ready for this today, it will likely impact all previous versions. This is the comparison that needs to be updated: https://github.com/hickory-dns/hickory-dns/blob/0d965da4b16e2c9f4ade7d72019dac40ad66ce6d/crates/proto/src/udp/udp_client_stream.rs#L333

kerem commented

2026-03-16 00:43:44 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 3, 2024):

I've published a patch which should fix this issue in #2124 if you want to experiment with seeing that it resolves this issue.

@bluejekyll commented on GitHub (Jan 3, 2024): I've published a patch which should fix this issue in #2124 if you want to experiment with seeing that it resolves this issue.

kerem commented

2026-03-16 00:43:49 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 4, 2024):

I'm realizing this could be responsible for a bunch of other IPv6 issues...

@bluejekyll commented on GitHub (Jan 4, 2024): I'm realizing this could be responsible for a bunch of other IPv6 issues...

kerem commented

2026-03-16 00:43:54 +03:00

Author

Owner

@orbekk commented on GitHub (Jan 4, 2024):

I gave it a try and it looks good. Left a comment in #2124 with the testing.

@orbekk commented on GitHub (Jan 4, 2024): I gave it a try and it looks good. Left a comment in #2124 with the testing.

kerem commented

2026-03-16 00:43:59 +03:00

Author

Owner

@djc commented on GitHub (Jan 4, 2024):

@bluejekyll did you track down the std changes for 1.69? What you're saying sounds kinda scary since I think most code would expect the SocketAddr comparisons to only involve IP and port...

@djc commented on GitHub (Jan 4, 2024): @bluejekyll did you track down the std changes for 1.69? What you're saying sounds kinda scary since I think most code would expect the `SocketAddr` comparisons to only involve IP and port...

kerem commented

2026-03-16 00:44:04 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 5, 2024):

Oh, you know what, I’m misreading the docs. 1.69 is when it became const. Maybe we just haven’t had a lot of local IPv6 usage on windows or Linux and macOS doesn’t set these options? I’ll have to investigate those fields and how they’re set on the different OSs. By default they are zeroed out.

@bluejekyll commented on GitHub (Jan 5, 2024): Oh, you know what, I’m misreading the docs. 1.69 is when it became const. Maybe we just haven’t had a lot of local IPv6 usage on windows or Linux and macOS doesn’t set these options? I’ll have to investigate those fields and how they’re set on the different OSs. By default they are zeroed out.

kerem referenced this issue

2026-03-16 02:24:07 +03:00

[PR #876] [CLOSED] Bump cfg-if from 0.1.9 to 0.1.10 #1761