No IPv6 candidates, although it is enabled

[Maxim Devaev]

Hi all. I have an interesting situation, but I don't understand if this is a bug or if this is how it should be.

Janus is running with a very basic configuration to run on a local network on a separate server. Some JS code is written that allows me to watch the stream. When I go to my page, where is janus.js tries to establish a webrtc connection, I do it using the IPv4 address in the URL, and everything works.

If I use Firefox and enter a hostname on the local network, it resolves to an IPv6 link-local address. At the same time, Firefox tries to establish connections ONLY over IPv6 (I see the list of ICE candidates in about:webrtc), while Janus offers only IPv4.

OK, I enable the ipv6 option in Janus (and also in js), but despite the message in the log that this is now enabled, Janus does not offer IPv6 candidates. If I add the parameter ice_enforce_list=eth0 (this interface has both IPv4 and IPv6 link-local), this doesn't work either. However, if I add the ice_enforce_list = <ipv6addr> parameter, then everything starts working fine: Janus offers both IPv4 and IPv6.

My questions:

1. Does Firefox behave correctly by offering only IPv6 candidates? Is this a bug or a feature? I believe that the feature.

2. Does Janus really only take the first address from the network interface and no more?

3. If this is how it should be, do I really need to constantly use ice_enforce_list to determine the list of addresses that can be connected to?

[Alessandro Toppi]

Firefox only offering IPv6 candidates might be due to the IP privacy policy that browsers implement. Since you are connecting to the page through a v6 address and since you mentioned a streaming only web page (so no getusermedia involved) the browser may choose to only gather the addresses tied to the interface used to load the page.
Anyway IIRC on FireFox v6 addresses will always have higher priority over v4 (if both kinds are generated of course).

As of Janus ignoring local ipv6 address, it seems that is an intended behavior (cfr. https://github.com/meetecho/janus-gateway/blob/2cd01182e44be6d7ff26635de216cb65703e9778/ice.c#L3620).
We skip all ipv6 addresses starting with fe80::

[Maxim Devaev]

What would be the best solution in this situation? From the point of view of each participant in the process, the behavior is correct:

- Firefox provides privacy and prefers IPv6;

- Janus ignores link-local because the connection at this address will not go beyond the local network;

- DNS may well resolve hostname to link-local.

But in the end, there is no connection. I believe that if I add link-local to the list of addresses, then firefox outside this network will also try to use it for the connection (because of the priority), which is obviously incorrect.

понедельник, 7 июня 2021 г. в 13:25:28 UTC+3, topp...@gmail.com:

[Alessandro Toppi]

Premise: I'm not an expert in IPv6.

Suggestion: maybe working with Unique Local Address (https://datatracker.ietf.org/doc/html/rfc4193) and avoid link-local address might do the trick? I guess that for local networking those are more appropriate than link-local addresses.

As of DNS resolving hostname to a link-local address, I don't know how that is possibile, maybe  with services like avahi / zeroconf ?

Adding the address to the enforce list should not be a big problem for browsers in the public internet. ICE handshake will somehow establish a connection in the end, given that at least one pair of candidates (either v4 or v6) is working. Priority is just a matter of which pair to test first, other candidates are not excluded.

[Maxim Devaev]

I'll try to figure out where IPv6 came from on a machine with Firefox. This is Windows 10, maybe there is something similar to zeroconf.

Is there some way to force the browser to add other (including IPv4) candidates as well? I would like to make do with minimal interference with the client configuration.

понедельник, 7 июня 2021 г. в 15:27:36 UTC+3, topp...@gmail.com:

[Alessandro Toppi]

Actually we managed to find out what is happening here.

First of all, sorry for the confusion but I forgot that any v6 enabled interface has a link-local address, so having it in the NIC is totally normal (don't mess with it).

The issue here is that when NO good local addresses are being found by the janus ice setup function (due to all addresses being dropped because either blacklisted, loopback, invalid or link-local) then the available local addresses for t he connection are automatically picked by the underlying library (libnice). So in this case libnice will take the lead and all the available addresses will be notified to the browser, including the infamous ipv6 link-local.

Not sure if this is a bug or not, I'll discuss this internally.

As of the way to enable browser to also include ipv4, that is a matter of trying to find which user interaction will make the policy handler happy. We often use a dummy getUserMedia call, not sure if other kinds of interaction will do the trick though.

[Maxim Devaev]

Maybe I don't quite understand you, but the problem is that Janus has a good IPv4 address and drops IPv6 link-local, while Firefox only wants to connect over IPv6. Perhaps a good solution on the part of Janus would be to offer an IPv6 link-local candidate if the browser is on the same network with it. I don't know if this is technically possible, correct me if not.

Please keep me posted if you decide anything.

понедельник, 7 июня 2021 г. в 18:31:52 UTC+3, topp...@gmail.com:

[Alessandro Toppi]

I have tried enabling link-local only advertisement on Janus.

Both Chrome and Firefox never offered a link-local candidate, so connection could not be established.

Can you please check on about:webrtc on FF which pair is working for you? I suspect it does not involve any link-local address.

[Maxim Devaev]

I checked these parameters in about:webrtc. Now I only have a screenshot with raw candidates when trying to connect via link-local (when ice_enforce_list is not added to janus), respectively, the attempt failed: https://cdn.discordapp.com/attachments/797944185369264159/850800868084154398/unknown.png

After adding the link-local server address to the ice_enforce_list, the connection was made over link-local IPv6. Right now this car is not available to me, but I checked it and I remember exactly. Later I will be able to make other screenshots that confirm this.

понедельник, 7 июня 2021 г. в 19:20:41 UTC+3, topp...@gmail.com:

[Maxim Devaev]

s/this car/this machine/g
sorry :)

понедельник, 7 июня 2021 г. в 20:00:06 UTC+3, Maxim Devaev:

[Alessandro Toppi]

Your browser seems to collect link-local address too... weird I was not able to force the browser to do the same.

Well in this situation it is clear that connection will not succeed, since FF is only offering an ipv6, while janus is offering an ipv4 (just like you already mentioned).

I see two options:

1) fork janus and just remove the check on the 'fe80' address, in order to let janus offer it. You could also open a PR on our github, maybe the discussion might be moved over there to have more suggestions from other devs

2) edit your js code, in order to make FF gather all addresses

Again, the reason it is working when you edit the enforce list is that janus ice setup will never configure the local ice agent due to settings/interfaces combination, so the underlying library will collect all the available addresses / hosts, including the normally skipped link-local.

[Lorenzo Miniero]

I've made it configurable in this PR: https://github.com/meetecho/janus-gateway/pull/2689

Please test.

L.

[Maxim Devaev]

It seems it's working! Many thanks.

вторник, 8 июня 2021 г. в 12:53:49 UTC+3, lmin...@gmail.com: