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

Missing a way to get local IP address for received UDP message #1649

Closed
GlenTiki opened this issue May 7, 2015 · 9 comments
Closed

Missing a way to get local IP address for received UDP message #1649

GlenTiki opened this issue May 7, 2015 · 9 comments
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. feature request Issues that request new features to be added to Node.js. help wanted Issues that need assistance from volunteers or PRs that need help to proceed. libuv Issues and PRs related to the libuv dependency or the uv binding. stalled Issues and PRs that are stalled.

Comments

@GlenTiki
Copy link
Contributor

GlenTiki commented May 7, 2015

This is a duplicate of nodejs/node-v0.x-archive#8788

Basically: I have a udp server listening on a port on multiple interfaces - when I get a message on this port, I would like to be able to detect what interface the message was received from.

@brendanashworth brendanashworth added dgram Issues and PRs related to the dgram subsystem / UDP. feature request Issues that request new features to be added to Node.js. labels May 7, 2015
@bnoordhuis
Copy link
Member

Also nodejs/node-v0.x-archive#6589. There are valid use cases and I think it would make a good addition.

However, different platforms have different quirks and there may be performance implications to consider. It's not really clear to me what the best way forward is.

@kanongil
Copy link
Contributor

I just encountered this issues when working on a multicast receiver, which is a slightly different case.

Essentially, it is impossible to only receive packets on a specific multicast address when the port number is otherwise used on the host.

  1. Process 1 registers and listens to traffic for 239.254.1.1:1234.
  2. Process 2 registers and listens to traffic for 239.254.1.2:1234.

Now both will have bound to port 1234 and receive all packets on that interface.

To fix this, we need to filter on the destination address, either manually using an exposed destination property, or through a new bind option.

Edit: My issue can be fixed by binding to the multicast address.

@nickdesaulniers
Copy link

This would be helpful for my ICE agent since I need to create sockets for each address accessible from the network. I have to do some funky iteration through os.networkInterfaces and also can't seem to bind to specific ipv6 addresses.

@Trott Trott added libuv Issues and PRs related to the libuv dependency or the uv binding. help wanted Issues that need assistance from volunteers or PRs that need help to proceed. labels Jun 8, 2016
@Trott Trott added the stalled Issues and PRs that are stalled. label Jul 7, 2017
@refack refack added this to To do in feature requests Nov 11, 2018
@refack
Copy link
Contributor

refack commented Nov 11, 2018

Put into https://github.com/nodejs/node/projects/13 backlog

@refack refack closed this as completed Nov 11, 2018
feature requests automation moved this from backlog/orphan to Done Nov 11, 2018
@refack refack moved this from Done to backlog/orphan in feature requests Nov 11, 2018
Trott pushed a commit to Ell-i/node that referenced this issue Jun 25, 2020
Add IPv6 link local scope ID suffix to the
rinfo address in those received upd6 datagrams
whose source address is a link local address.

Add a new test case, test-dgram-udp6-link-local-address,
to verify that IPv6 UDP datagrams received from a
link-local source address do contain the scope ID
suffix in the rinfo address field.

When a packet is received from a link-local source
address, if the address does not contain the scope
ID suffix, it is impossible to reply back to the
sender, as the kernel is not able to determine
the right network interface to send the packet
through and returns with an error.

Ref: nodejs#1649
PR-URL: nodejs#14500
sxa pushed a commit that referenced this issue Jul 21, 2020
Add IPv6 link local scope ID suffix to the
rinfo address in those received upd6 datagrams
whose source address is a link local address.

Add a new test case, test-dgram-udp6-link-local-address,
to verify that IPv6 UDP datagrams received from a
link-local source address do contain the scope ID
suffix in the rinfo address field.

When a packet is received from a link-local source
address, if the address does not contain the scope
ID suffix, it is impossible to reply back to the
sender, as the kernel is not able to determine
the right network interface to send the packet
through and returns with an error.

Ref: #1649
PR-URL: #14500

Refs: #1649
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Stewart X Addison <sxa@uk.ibm.com>
cjihrig pushed a commit that referenced this issue Jul 23, 2020
Add IPv6 link local scope ID suffix to the
rinfo address in those received upd6 datagrams
whose source address is a link local address.

Add a new test case, test-dgram-udp6-link-local-address,
to verify that IPv6 UDP datagrams received from a
link-local source address do contain the scope ID
suffix in the rinfo address field.

When a packet is received from a link-local source
address, if the address does not contain the scope
ID suffix, it is impossible to reply back to the
sender, as the kernel is not able to determine
the right network interface to send the packet
through and returns with an error.

Ref: #1649
PR-URL: #14500

Refs: #1649
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Stewart X Addison <sxa@uk.ibm.com>
MylesBorins pushed a commit that referenced this issue Jul 27, 2020
Add IPv6 link local scope ID suffix to the
rinfo address in those received upd6 datagrams
whose source address is a link local address.

Add a new test case, test-dgram-udp6-link-local-address,
to verify that IPv6 UDP datagrams received from a
link-local source address do contain the scope ID
suffix in the rinfo address field.

When a packet is received from a link-local source
address, if the address does not contain the scope
ID suffix, it is impossible to reply back to the
sender, as the kernel is not able to determine
the right network interface to send the packet
through and returns with an error.

Ref: #1649
PR-URL: #14500

Refs: #1649
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Stewart X Addison <sxa@uk.ibm.com>
addaleax pushed a commit that referenced this issue Sep 22, 2020
Add IPv6 link local scope ID suffix to the
rinfo address in those received upd6 datagrams
whose source address is a link local address.

Add a new test case, test-dgram-udp6-link-local-address,
to verify that IPv6 UDP datagrams received from a
link-local source address do contain the scope ID
suffix in the rinfo address field.

When a packet is received from a link-local source
address, if the address does not contain the scope
ID suffix, it is impossible to reply back to the
sender, as the kernel is not able to determine
the right network interface to send the packet
through and returns with an error.

Ref: #1649
PR-URL: #14500

Refs: #1649
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Stewart X Addison <sxa@uk.ibm.com>
@JKRhb
Copy link

JKRhb commented Aug 21, 2023

If I see it correctly, this issue has not really been resolved yet, right?

@bnoordhuis
Copy link
Member

It's never been implemented because of irreconcilable platform differences. The last attempt was almost 10 years ago but I don't think the situation has materially improved.

@JKRhb
Copy link

JKRhb commented Aug 22, 2023

I see, thank you for your feedback on this! Since the issue remains unresolved, would make it sense to reopen it, though..?

@bnoordhuis
Copy link
Member

Only if there is some way forward but that's not the case here. If it can't be made to work, it can't be made to work.

@oxygen
Copy link

oxygen commented Aug 22, 2023

For broadcast UDP messages I just listened on the broadcast address of each subnet of each interface. Don't listen on 255.255.255.255.

This should work for unicast too (by listening on specific addresses).

Normally you won't find two interfaces with overlapping subnets. If you do, then problably it has something to do with those platform differences and you surely already have bigger problems like NodeJS not allowing binding/restricting the socket to a specific interface.

So, in short, you shouldn't need Node telling you the destination IP address of the received packet, you can figure it out.

Also, by listening on specific broadcast addresses and specific IPs you can automatically rule out interfaces you're not suposed to listen on. A big security plus as a default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. feature request Issues that request new features to be added to Node.js. help wanted Issues that need assistance from volunteers or PRs that need help to proceed. libuv Issues and PRs related to the libuv dependency or the uv binding. stalled Issues and PRs that are stalled.
Projects
No open projects
feature requests
  
backlog/orphan
Development

No branches or pull requests

9 participants