Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binding to IPV4_UNSPECIFIED/IPV6_UNSPECIFIED #86

Closed
manekinekko opened this issue Dec 12, 2023 · 2 comments
Closed

Binding to IPV4_UNSPECIFIED/IPV6_UNSPECIFIED #86

manekinekko opened this issue Dec 12, 2023 · 2 comments

Comments

@manekinekko
Copy link
Contributor

manekinekko commented Dec 12, 2023

Hi. I am working on implementing wasi-sockets for jco. I'd like to make sure I understand this UDP test program correctly.

In crates/test-programs/src/bin/preview2_udp_sample_application.rs:49:

assert_eq!(datagrams[0].remote_address, client_addr);

We are checking the remote_address received from the remote socket matches the client_addr used in the bind call. However, when client is bound to unspecified_addr (0.0.0.0), the resolved remote_address of the remote client ends up being 127.0.0.1 (this is probably spec'ed out in an ietf rfc but I couldn't find which one).

So, the test case is failing because of this:

left: IpSocketAddress::Ipv4(Ipv4SocketAddress { port: 52726, address: (127, 0, 0, 1) })
right: IpSocketAddress::Ipv4(Ipv4SocketAddress { port: 52726, address: (0, 0, 0, 0) })

Also, I tried patching the remote socket resolved address making sure it's 0.0.0.0, which passes the test above, however this breaks the test_udp_dual_stack_conversation:111 test case, because we cannot send a UDP packet to remote address which value is 0.0.0.0 (triggering a -65 errno):

   server_outgoing
        .blocking_send(&[OutgoingDatagram {
            data: msg.data.clone(),
            remote_address: Some(msg.remote_address), // cannot send to 0.0.0.0
        }])
        .unwrap();

Can you please help adding some clarity?

cc @badeend @pchickey @guybedford

@badeend
Copy link
Collaborator

badeend commented Dec 12, 2023

I have only skimmed the JCO implementation so I could be wrong, but: my guess is that it has to with the fact that you cache the local address, but don't update it after a stream call.

"connect"ing a socket updates the local binding. This is documented on the stream method in udp.wit:

This function only changes the local socket configuration and does not generate any network traffic. On success, the remote-address of the socket is updated. The local-address may be updated as well, based on the best network path to remote-address.

@guybedford
Copy link
Contributor

I can confirm that this is resolved in the JCO implementation now.

@badeend badeend closed this as completed Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants