[jitsi-users] Multiple Network Interfaces Preventing Jitsi Call Connections

#1

Greetings all,

I have installed Jitsi recently and have spent the past three days
attempting to make it work. I did everything from uninstall my firewall, to
disconnecting my router, to calling my ISP - no matter what I did to
Windows or otherwise I could not connect a call. I could log in, send
messages, but calls would be blocked as if a firewall was blocking it -
even with network monitoring I couldn't even locate where it was attempting
to connect to.

As part of the debug process I downloaded the previous major releases for
windows, and confirmed that the Linux distributions were functioning
(Latest Ubuntu & Debian). This confirmed to me it was a Windows issue, and
through other parties confirmed it was not specifically a Windows 8 issue.

Today I managed to track down the true problem, which required I google a
very specific part of the error code, and lead me to this obscure mailing
list post; which matches some of the debug information relating to ICE
failing to connect:
https://java.net/projects/jitsi/lists/dev/archive/2013-05/message/28

I had also disabled/enabled about every connection option in Jitsi, and
with ICE disabled it would connect but send no data (no sound/video). I
finally trawled through the entire mailing list and located this post that
a user presented as a solution, which I will quote part of here for
posterity (post by "Ken Ayott") :

I made some progress with this after digging through the code. The problem

appears to be related to unused network interfaces on one of my Win7-64bit
PC’s. This particular PC has 2 network interfaces, one of which is
unplugged and not in use. I disabled this interface and the TAP-Win32
Adapter via Control Panel and now I can establish video calls. 2-way video
is still intermittent; sometimes I end up with a black screen on one
endpoint, and sometimes it works on both, but that is likely a different
issue.

I suspect this is an issue with the way network interfaces are determined
and processed within the ice4j code, but can’t confirm that.

The solution to the error "Caused by: java.io.IOException: Failed to bind
even a single host candidate for component:Component id=1 parent
stream=audio" is to disable every network interface/driver on Windows that
is not connected to the internet. Later today I also managed to locate a
bug report submitted to the bug tracker <https://trac.jitsi.org/ticket/1164>
.

The reason I am bringing this up to the mailing list is the following: No
single post, website, or piece of information, contains both the error code
and the solution together. Even if you google the error code, it takes an
immense amount of difficulty to find the correct fix. Furthermore, the bug
report is nine months old, and does not contain precisely accurate
information.

As it took me three days to find and apply the solution after endless
frustration, and as it is very common for laptops to have both
wifi/ethernet network drivers enabled at the same time, that it deserves a
significantly higher priority and immediate fix than it has. The current
nightly build does not fix this defect either.

Therefore I request additional comment on what can be done to notify
people, who will be trying to search for a solution when this bug appears,
as well as improve the bug tracker post with more relevant information.

Thank you!

P.S. I apologize if I have breached any etiquette for the mailing list, as
I have joined simply to try and get more information compiled on this very
aggravating defect. Please forgive any oversights in my posting.

#2

Hey

Please take a look at this thread:
http://markmail.org/thread/sqqdpcbsky77uzpo

You ran into a bug in Java. Workarounds:
- don't disable IPv6
- change the binding order of your NICs
- start Jitsi with -4 (or --ipv4)

Ingo

···

-----Original Message-----
From: users-bounces@jitsi.org [mailto:users-bounces@jitsi.org] On Behalf Of
Jeremyhfht
Sent: Samstag, 15. Februar 2014 04:23
To: users@jitsi.org
Subject: [jitsi-users] Multiple Network Interfaces Preventing Jitsi Call
Connections

Greetings all,

I have installed Jitsi recently and have spent the past three days attempting
to make it work. I did everything from uninstall my firewall, to
disconnecting my router, to calling my ISP - no matter what I did to Windows
or otherwise I could not connect a call. I could log in, send messages, but
calls would be blocked as if a firewall was blocking it - even with network
monitoring I couldn't even locate where it was attempting to connect to.

As part of the debug process I downloaded the previous major releases for
windows, and confirmed that the Linux distributions were functioning (Latest
Ubuntu & Debian). This confirmed to me it was a Windows issue, and through
other parties confirmed it was not specifically a Windows 8 issue.

Today I managed to track down the true problem, which required I google a
very specific part of the error code, and lead me to this obscure mailing
list post; which matches some of the debug information relating to ICE
failing to connect: https://java.net/projects/jitsi/lists/dev/archive/2013-
05/message/28

I had also disabled/enabled about every connection option in Jitsi, and with
ICE disabled it would connect but send no data (no sound/video). I finally
trawled through the entire mailing list and located this post that a user
presented as a solution, which I will quote part of here for posterity (post
by "Ken Ayott") :

  I made some progress with this after digging through the code. The
problem appears to be related to unused network interfaces on one of my Win7-
64bit PC’s. This particular PC has 2 network interfaces, one of which is
unplugged and not in use. I disabled this interface and the TAP-Win32
Adapter via Control Panel and now I can establish video calls. 2-way video
is still intermittent; sometimes I end up with a black screen on one
endpoint, and sometimes it works on both, but that is likely a different
issue.

  I suspect this is an issue with the way network interfaces are
determined and processed within the ice4j code, but can’t confirm that.

The solution to the error "Caused by: java.io.IOException: Failed to bind
even a single host candidate for component:Component id=1 parent
stream=audio" is to disable every network interface/driver on Windows that is
not connected to the internet. Later today I also managed to locate a bug
report submitted to the bug tracker <https://trac.jitsi.org/ticket/1164> .

The reason I am bringing this up to the mailing list is the following: No
single post, website, or piece of information, contains both the error code
and the solution together. Even if you google the error code, it takes an
immense amount of difficulty to find the correct fix. Furthermore, the bug
report is nine months old, and does not contain precisely accurate
information.

As it took me three days to find and apply the solution after endless
frustration, and as it is very common for laptops to have both wifi/ethernet
network drivers enabled at the same time, that it deserves a significantly
higher priority and immediate fix than it has. The current nightly build does
not fix this defect either.

Therefore I request additional comment on what can be done to notify people,
who will be trying to search for a solution when this bug appears, as well as
improve the bug tracker post with more relevant information.

Thank you!

P.S. I apologize if I have breached any etiquette for the mailing list, as I
have joined simply to try and get more information compiled on this very
aggravating defect. Please forgive any oversights in my posting.

#3

I suppose that's a more specific fix, but a good bulk of my post here is
about why the priority of this bug needs increasing on the bug tracker, and
why it needs to be added very explicitly to the FAQ. In particular, the
error messages associated with it, so that google searching regular users
can actually find the fix until it's fixed in one of the nightly builds.

It's an incredibly major defect because it completely cripples
functionality with no obvious way to fix it. If Jitsi is to be a user
platform I would think such things would be top priority, especially due to
how common two-device systems are that do not have IPv6 enabled. This said,
I have no idea how to go about suggesting or accomplishing any of this, and
Jitsi does not have a public forum that assures search engine trawling. You
can understand why this would be important?

···

On Sat, Feb 15, 2014 at 3:53 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey

Please take a look at this thread:
http://markmail.org/thread/sqqdpcbsky77uzpo

You ran into a bug in Java. Workarounds:
- don't disable IPv6
- change the binding order of your NICs
- start Jitsi with -4 (or --ipv4)

Ingo

> -----Original Message-----
> From: users-bounces@jitsi.org [mailto:users-bounces@jitsi.org] On
Behalf Of
> Jeremyhfht
> Sent: Samstag, 15. Februar 2014 04:23
> To: users@jitsi.org
> Subject: [jitsi-users] Multiple Network Interfaces Preventing Jitsi Call
> Connections
>
> Greetings all,
>
> I have installed Jitsi recently and have spent the past three days
attempting
> to make it work. I did everything from uninstall my firewall, to
> disconnecting my router, to calling my ISP - no matter what I did to
Windows
> or otherwise I could not connect a call. I could log in, send messages,
but
> calls would be blocked as if a firewall was blocking it - even with
network
> monitoring I couldn't even locate where it was attempting to connect to.
>
>
> As part of the debug process I downloaded the previous major releases for
> windows, and confirmed that the Linux distributions were functioning
(Latest
> Ubuntu & Debian). This confirmed to me it was a Windows issue, and
through
> other parties confirmed it was not specifically a Windows 8 issue.
>
>
> Today I managed to track down the true problem, which required I google a
> very specific part of the error code, and lead me to this obscure mailing
> list post; which matches some of the debug information relating to ICE
> failing to connect:
https://java.net/projects/jitsi/lists/dev/archive/2013-
> 05/message/28
>
> I had also disabled/enabled about every connection option in Jitsi, and
with
> ICE disabled it would connect but send no data (no sound/video). I
finally
> trawled through the entire mailing list and located this post that a user
> presented as a solution, which I will quote part of here for posterity
(post
> by "Ken Ayott") :
>
>
>
> I made some progress with this after digging through the code. The
> problem appears to be related to unused network interfaces on one of my
Win7-
> 64bit PC’s. This particular PC has 2 network interfaces, one of which is
> unplugged and not in use. I disabled this interface and the TAP-Win32
> Adapter via Control Panel and now I can establish video calls. 2-way
video
> is still intermittent; sometimes I end up with a black screen on one
> endpoint, and sometimes it works on both, but that is likely a different
> issue.
>
> I suspect this is an issue with the way network interfaces are
> determined and processed within the ice4j code, but can’t confirm that.
>
>
>
> The solution to the error "Caused by: java.io.IOException: Failed to bind
> even a single host candidate for component:Component id=1 parent
> stream=audio" is to disable every network interface/driver on Windows
that is
> not connected to the internet. Later today I also managed to locate a bug
> report submitted to the bug tracker <https://trac.jitsi.org/ticket/1164>
.
>
>
> The reason I am bringing this up to the mailing list is the following: No
> single post, website, or piece of information, contains both the error
code
> and the solution together. Even if you google the error code, it takes an
> immense amount of difficulty to find the correct fix. Furthermore, the
bug
> report is nine months old, and does not contain precisely accurate
> information.
>
>
> As it took me three days to find and apply the solution after endless
> frustration, and as it is very common for laptops to have both
wifi/ethernet
> network drivers enabled at the same time, that it deserves a
significantly
> higher priority and immediate fix than it has. The current nightly build
does
> not fix this defect either.
>
>
> Therefore I request additional comment on what can be done to notify
people,
> who will be trying to search for a solution when this bug appears, as
well as
> improve the bug tracker post with more relevant information.
>
>
> Thank you!
>
>
> P.S. I apologize if I have breached any etiquette for the mailing list,
as I
> have joined simply to try and get more information compiled on this very
> aggravating defect. Please forgive any oversights in my posting.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

#4

I suppose that's a more specific fix, but a good bulk of my post here is
about why the priority of this bug needs increasing on the bug tracker, and
why it needs to be added very explicitly to the FAQ. In particular, the error
messages associated with it, so that google searching regular users can
actually find the fix until it's fixed in one of the nightly builds.

Well, me might add a link and an explanation to the bug entry.

It's an incredibly major defect because it completely cripples functionality
with no obvious way to fix it.

It's an incredible defect of Java, not Jitsi.

If Jitsi is to be a user platform I would
think such things would be top priority, especially due to how common two-
device systems are that do not have IPv6 enabled.

That is wrong. IPv6 is by default enabled on all modern systems. One would explicitly need to disable it, against all recommendations of Microsoft. Note that having IPv6 enabled does not mean you need to have an IPv6-capable internet access. And it's also not just related of having multiple NICs - most developers work on notebooks with multiple NICs every day and have no issues either.

It has only been the second time in almost a year since this has come up on the list. If it would have been such a big issue, we'd have heard more of it.

This said, I have no idea
how to go about suggesting or accomplishing any of this, and Jitsi does not
have a public forum that assures search engine trawling. You can understand
why this would be important?

The mailing list archive is public and indexed, a forum wouldn't do any better.

Don't get me wrong, we'd like to have this fixed. But we just cannot fix bugs in Java (Oracle must do that, instead of still relying on incorrectly used APIs from Windows 98) and working around it would need resources we simply don't have.

Ingo

#5

I do believe you are suffering from a selection bias. Almost nobody bothers
to sign up for mailing lists, and as most users of Jitsi would migrate from
skype, Jitsi not working would only provoke apathy. They would just keep
using Skype. I only signed up to the mailing list to report this issue
because of the fact I am not the only one of my friends to have this
problem.

I greatly love Jitsi, and greatly despise Skype, so I am already very
interested in its future. A lot of power users have to disable IPv6 due to
conflicts with either bad hardware, or bad software, and in my case it was
both. In my friends case they use other clients that break when IPv6 is
enabled - which is also why I had it disabled.

Basically all I am asking is for some way to make this error actually help
the user. As it stands, the mailing lists and solutions make it difficult
or impractical for anyone but a technically competent and invested user to
care about fixing.

Additionally, IPv6 enabled systems are a lot fewer than you
think<http://www.ipv6actnow.org/info/statistics/>(based on what few
data collection sources I could locate to check this),
as some Windows updates actually disable IPv6 variously due to new security
exploits or bug conflicts with networking updates. Relying on persistent
enabling of IPv6 does not seem like an ideal - and at the very least there
should be a very clear error message telling users how to fix the issue.

···

On Sat, Feb 15, 2014 at 7:01 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I suppose that's a more specific fix, but a good bulk of my post here is
> about why the priority of this bug needs increasing on the bug tracker,
and
> why it needs to be added very explicitly to the FAQ. In particular, the
error
> messages associated with it, so that google searching regular users can
> actually find the fix until it's fixed in one of the nightly builds.

Well, me might add a link and an explanation to the bug entry.

> It's an incredibly major defect because it completely cripples
functionality
> with no obvious way to fix it.

It's an incredible defect of Java, not Jitsi.

> If Jitsi is to be a user platform I would
> think such things would be top priority, especially due to how common
two-
> device systems are that do not have IPv6 enabled.

That is wrong. IPv6 is by default enabled on all modern systems. One would
explicitly need to disable it, against all recommendations of Microsoft.
Note that having IPv6 enabled does not mean you need to have an
IPv6-capable internet access. And it's also not just related of having
multiple NICs - most developers work on notebooks with multiple NICs every
day and have no issues either.

It has only been the second time in almost a year since this has come up
on the list. If it would have been such a big issue, we'd have heard more
of it.

> This said, I have no idea
> how to go about suggesting or accomplishing any of this, and Jitsi does
not
> have a public forum that assures search engine trawling. You can
understand
> why this would be important?

The mailing list archive is public and indexed, a forum wouldn't do any
better.

Don't get me wrong, we'd like to have this fixed. But we just cannot fix
bugs in Java (Oracle must do that, instead of still relying on incorrectly
used APIs from Windows 98) and working around it would need resources we
simply don't have.

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

#6

> messages associated with it, so that google searching regular users can
> actually find the fix until it's fixed in one of the nightly builds.

Well, me might add a link and an explanation to the bug entry.

That should do it, thanks!

It has only been the second time in almost a year since this has come up on
the list. If it would have been such a big issue, we'd have heard more of
it.

For me it it was perfect timing that Jeremy posted about it.
After struggling through the NAT issues I was about to write off jitsi
for good, and I am quite certain that this happens much more than
the error gets reported on the list.

I am now happy that it finally works. :slight_smile:
-Chris