lws_create_context: iface option issue #3365
Comments
|
Theories about how things "should" be treated - especially for free - often lead to disappointment. The code you looked at just shows that we pass -i arg into lws context creation, there's nothing wrong or interesting about that, even if it supported what you want, it would look the same. The situation is a bit more sophisticated than you are imagining, on unix we use getifaddrs() and do walk the results, scoring the "best" IP, eg, we look for a global scope ipv6 to bind to, over link-local. libwebsockets/lib/plat/unix/unix-sockets.c Line 337 in fe6ea39 In lws, a vhost may have exactly two sockets associated (for ipv4 and ipv6) and they are bound individually to "the best" ipv4 and ipv6 addresses it finds at the network interface, if you ask for it to be bound there. So as far as it goes, "multiple" addresses on a network interface binding are supported in the case n = 2 and it's the usual case of ipv4 + ipv6. Unix socket and specific IP address binding (not the netdev name) are also supported. The actual business is happening here libwebsockets/lib/core-net/network.c Line 274 in fe6ea39 AFAIK bind() is not cumulative, it's a one-shot thing on the socket filtering the socket's view to a single address. So supporting your use-case means we would need do the work to select n "best" ipv4 and ipv6 from getifaddrs() and allow as many listen sockets as needed on the vhost. |
|
I don't see how you could be describing this as a theory. If I tell a program to bind to an interface as opposed to a singular IP, I expect it to bind to the entire interface, not partially bind to it. As in, if I don't instruct it to bind to a singular, why is it trying to circumvent what I told it to? Additionally, I don't see how any program could reasonably deduce what IP is best on an interface, so why is it even trying? Even in high-level langs and architecture, dns checks are often considered the only universally reliable way of determining reliable source IPs, and even then we all know there's several problems with that and is just an approximation at best. |
|
Your suggestion this "should" be treated like a bug is your theory. Others are going to treat it according to their own ideas about what they want to do with their time, for free.
For example, I don't see any value arguing about that with you. I gave you a detailed answer about the actual situation in lws that leads to the outcome you don't like, you're welcome to look into it and propose a way forward (preferably with patches). |
|
I don't understand your point. Whether it's officially or personally labelled as a bug doesn't guarantee change either. There's nothing stopping anyone from stalling or idling the issue regardless of whether it has been officiated. That's a well-known and well-documented problem in development. I will say I do appreciate your work and help, if that's what you're bothered about. |
When attempting to implement ttyd on OpenWRT on my router, I noticed there were issues with getting ttyd running correctly, and it appears that they may be rooted in a limitation/problem with this library.
I'd like to reiterate that:
From the core issue:
Which seems to be caused by libwebsockets here:
Workaround:
A possible workaround for now, is to have ttyd check the interface first for all assigned IPs when creating the websockets
The text was updated successfully, but these errors were encountered: