[jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

Archive
1

I've set Jitsi up on 40 PCs so far without (mostly) issues. But for 3 PCs we are having issues where Jitsi will not connect to the server.

I've attached 3 captures using wireshark for DNS traffic when loading up Jitsi (I flushed DNS cache on local pc before each capture). The issue is with "OtherPC"

MyPC2-BackupResolverEnabled.pcapng
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverEnabled.pcapng
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries the Jitsi backup resolver DNS (8.8.4.4) for the SRV record for ssdcservices.com and gets "no such name" response
Other PC (165.245.158.209) queries 10.1.1 and 8.8.4.4 for the Host (A) record for ssdcservices.com and gets a result (207.243.17.83)
Other PC (165.245.158.209) Jitsi tries to connect to 207.243.17.83 and fails the connection (because there is not an XMPP server running on this server)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com gets the resultant openfire server (165.245.147.163) but does not try to connect.
Result: Never connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverDisabled.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

Okay, I've done some more testing.... I did not flush the dns cache on the local client pc before running this wireshark capture. I merely set the Advanced --> DNS --> Start backup resolver after --> 20,000 ms (20seconds).

Result? I get connected while keeping Jitsi parallel dns resolving enabled, but it takes a REALLY long time to connect to the openfire server. It is like this:
Gets FQDN of openfire server ===wait 10 seconds===>> lookup IPv4 address ===wait 10 seconds===>> lookup IPv6 address ===>> instantly connect to IPv4 address of openfire

OtherPC2-BackupResolverEnabled20secTimeout.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and gets FQDN of openfire server as response (ssdcappp01.ssdcdsi.com)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (165.245.147.163)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (AAA) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (IPv6 address) and then successfully connects to our openfire IPv4 address (165.245.147.163)!
Result: Successfully connects to our openfire server hosted on 165.245.147.163

It is very strange the exact 10 second wait between DNS queries. Our internal DNS server is responding to the queries under 1000ms. What is most strange is my PC is trying to query 10.0.1.1 for the SRV record. I ran a wireshark capture for 10 minutes and surfed the web and did other activities and there was NO TRAFFIC between "OtherPC" and 10.0.1.1. Only when I opened up Jitsi did it try to query it. Again, we don't even had this 10.0.1.1 subnet on our network.

Conclusion: Our workaround will be to disable parallel DNS resolving in Jitsi as we do not need it anyway.

Aaron Dixon | IT Specialist | SSDC Services

OtherPC-2014-03-29@17.37.26-logs.zip (37 KB)

MyPC-2014-03-29@17.31.59-logs.zip (33.3 KB)

OtherPC-20secondtimeout-2014-03-29@18.52.17-logs.zip (13.4 KB)

OtherPC2-BackupResolverDisabled.pcapng (4.93 KB)

OtherPC2-BackupResolverEnabled20secTimeout.pcapng (4.38 KB)

OtherPC2-BackupResolverEnabled.pcapng (8.3 KB)

MyPC2-BackupResolverEnabled.pcapng (6.13 KB)

···

Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com<mailto:aaron.dixon@ssdcservices.com>

2

The bug report I just submitted may be too much to read. If so...

Re-cap is that the afflicted PCs are trying to do DNS query against 10.0.1.1 for the XMPP SRV record when Jitsi starts up. This is taking too long and the Jitsi backup resolver is being used. Eventually, the host (A) record is resolved using jitsi backup resolver but there is no openfire server hosted there so Jitsi never connects.

What should be happening is the XMPP SRV record should be resolved from our internal DNS server. I think there is some bug in Jitsi which is causing the PC to look at 10.0.1.1 for dns lookup. This 10.0.1.1 does not exist on our network and is not hard coded as DNS server for the network interface on the pc so I do not know why it is being queried. Wireshark capture shows no traffic to 10.0.1.1 until Jitsi is loaded.

Sorry for long winded last msg. Hopefully this is better. Logs and captures attached to last post.

···

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Aaron Dixon
Sent: Saturday, March 29, 2014 7:05 PM
To: Jitsi Developers
Subject: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

I've set Jitsi up on 40 PCs so far without (mostly) issues. But for 3 PCs we are having issues where Jitsi will not connect to the server.

I've attached 3 captures using wireshark for DNS traffic when loading up Jitsi (I flushed DNS cache on local pc before each capture). The issue is with "OtherPC"

MyPC2-BackupResolverEnabled.pcapng
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverEnabled.pcapng
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries the Jitsi backup resolver DNS (8.8.4.4) for the SRV record for ssdcservices.com and gets "no such name" response
Other PC (165.245.158.209) queries 10.1.1 and 8.8.4.4 for the Host (A) record for ssdcservices.com and gets a result (207.243.17.83)
Other PC (165.245.158.209) Jitsi tries to connect to 207.243.17.83 and fails the connection (because there is not an XMPP server running on this server)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com gets the resultant openfire server (165.245.147.163) but does not try to connect.
Result: Never connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverDisabled.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

Okay, I've done some more testing.... I did not flush the dns cache on the local client pc before running this wireshark capture. I merely set the Advanced --> DNS --> Start backup resolver after --> 20,000 ms (20seconds).

Result? I get connected while keeping Jitsi parallel dns resolving enabled, but it takes a REALLY long time to connect to the openfire server. It is like this:
Gets FQDN of openfire server ===wait 10 seconds===>> lookup IPv4 address ===wait 10 seconds===>> lookup IPv6 address ===>> instantly connect to IPv4 address of openfire

OtherPC2-BackupResolverEnabled20secTimeout.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and gets FQDN of openfire server as response (ssdcappp01.ssdcdsi.com)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (165.245.147.163)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (AAA) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (IPv6 address) and then successfully connects to our openfire IPv4 address (165.245.147.163)!
Result: Successfully connects to our openfire server hosted on 165.245.147.163

It is very strange the exact 10 second wait between DNS queries. Our internal DNS server is responding to the queries under 1000ms. What is most strange is my PC is trying to query 10.0.1.1 for the SRV record. I ran a wireshark capture for 10 minutes and surfed the web and did other activities and there was NO TRAFFIC between "OtherPC" and 10.0.1.1. Only when I opened up Jitsi did it try to query it. Again, we don't even had this 10.0.1.1 subnet on our network.

Conclusion: Our workaround will be to disable parallel DNS resolving in Jitsi as we do not need it anyway.

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com<mailto:aaron.dixon@ssdcservices.com>

3

Hey

Are the affected machines laptops by any chance? There's a bug in Java that reports the DNS servers on inactive interfaces as well. So if you've been on a wireless network, got the 10.xyz address as the DNS server on the wireless NIC, then got back to the company network, Java still thinks the 10.xyz nameserver is valid. A restart of Jitsi doesn't help, the bug is caused by the fact that Java reads the DNS servers from the registry instead of using the proper Windows APIs.

If this doesn't apply to your situation, the only other thing that comes to mind would be that 10.xyz is configured as a nameserver on a NIC manually.

The hosts file as mentioned by Jungle is irrelevant for Jitsi, it's not being honored and can be used for A records only anyway.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 30.03.2014 à 00:08, "Aaron Dixon" <Aaron.Dixon@ssdcservices.com> a écrit :

I’ve set Jitsi up on 40 PCs so far without (mostly) issues. But for 3 PCs we are having issues where Jitsi will not connect to the server.

I’ve attached 3 captures using wireshark for DNS traffic when loading up Jitsi (I flushed DNS cache on local pc before each capture). The issue is with “OtherPC”

MyPC2-BackupResolverEnabled.pcapng
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
My PC (165.245.158.170) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverEnabled.pcapng
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record for backup-resolver.jitsi.net and receives response (8.8.8.8 & 8.8.4.4)
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries the Jitsi backup resolver DNS (8.8.4.4) for the SRV record for ssdcservices.com and gets “no such name” response
Other PC (165.245.158.209) queries 10.1.1 and 8.8.4.4 for the Host (A) record for ssdcservices.com and gets a result (207.243.17.83)
Other PC (165.245.158.209) Jitsi tries to connect to 207.243.17.83 and fails the connection (because there is not an XMPP server running on this server)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com gets the resultant openfire server (165.245.147.163) but does not try to connect.
Result: Never connects to our openfire server hosted on 165.245.147.163

OtherPC2-BackupResolverDisabled.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and connects to the resultant openfire server (165.245.147.163)
Result: Successfully connects to our openfire server hosted on 165.245.147.163

Okay, I’ve done some more testing…. I did not flush the dns cache on the local client pc before running this wireshark capture. I merely set the Advanced à DNS à Start backup resolver after à 20,000 ms (20seconds).

Result? I get connected while keeping Jitsi parallel dns resolving enabled, but it takes a REALLY long time to connect to the openfire server. It is like this:
Gets FQDN of openfire server ===wait 10 seconds===>> lookup IPv4 address ===wait 10 seconds===>> lookup IPv6 address ===>> instantly connect to IPv4 address of openfire

OtherPC2-BackupResolverEnabled20secTimeout.pcapng
Other PC (165.245.158.209) queries an IP address that does not exist on our network (10.0.1.1) for SRV record for ssdcservices.com and does not get a response (because 10.0.1.1 does not exist)
Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the SRV record for ssdcservices.com and gets FQDN of openfire server as response (ssdcappp01.ssdcdsi.com)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (A) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (165.245.147.163)
10 seconds later, Other PC (165.245.158.209) queries our internal DNS server (165.245.147.151) for the Host (AAA) record of the FQDN of openfire server (ssdcappp01.ssdcdsi.com) and gets response (IPv6 address) and then successfully connects to our openfire IPv4 address (165.245.147.163)!
Result: Successfully connects to our openfire server hosted on 165.245.147.163

It is very strange the exact 10 second wait between DNS queries. Our internal DNS server is responding to the queries under 1000ms. What is most strange is my PC is trying to query 10.0.1.1 for the SRV record. I ran a wireshark capture for 10 minutes and surfed the web and did other activities and there was NO TRAFFIC between “OtherPC” and 10.0.1.1. Only when I opened up Jitsi did it try to query it. Again, we don’t even had this 10.0.1.1 subnet on our network.

Conclusion: Our workaround will be to disable parallel DNS resolving in Jitsi as we do not need it anyway.

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

<OtherPC-2014-03-29@17.37.26-logs.zip>
<MyPC-2014-03-29@17.31.59-logs.zip>
<OtherPC-20secondtimeout-2014-03-29@18.52.17-logs.zip>
<OtherPC2-BackupResolverDisabled.pcapng>
<OtherPC2-BackupResolverEnabled20secTimeout.pcapng>
<OtherPC2-BackupResolverEnabled.pcapng>
<MyPC2-BackupResolverEnabled.pcapng>
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

4

Hi Aaron,

Re-cap is that the afflicted PCs are trying to do DNS query against

10.0.1.1 for the XMPP SRV record when Jitsi starts up.

This is interesting as the other 40 machines, evidently, do not have this
issue so this would look like some kind of issue on those particular
computers/OS. Have you checked your host and resolv files to make sure they
match the other unaffected machines?

Admittedly, I have not reviewed the attachments in your previous letter.

Best,
Jungle

···

On 29 March 2014 16:13, Aaron Dixon <Aaron.Dixon@ssdcservices.com> wrote:

The bug report I just submitted may be too much to read. If so…

Re-cap is that the afflicted PCs are trying to do DNS query against
10.0.1.1 for the XMPP SRV record when Jitsi starts up. This is taking too
long and the Jitsi backup resolver is being used. Eventually, the host (A)
record is resolved using jitsi backup resolver but there is no openfire
server hosted there so Jitsi never connects.

What should be happening is the XMPP SRV record should be resolved from
our internal DNS server. I think there is some bug in Jitsi which is
causing the PC to look at 10.0.1.1 for dns lookup. This 10.0.1.1 does not
exist on our network and is not hard coded as DNS server for the network
interface on the pc so I do not know why it is being queried. Wireshark
capture shows no traffic to 10.0.1.1 until Jitsi is loaded.

Sorry for long winded last msg. Hopefully this is better. Logs and
captures attached to last post.

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

5

Hi,

The hosts file as mentioned by Jungle is irrelevant for Jitsi, it's not

being honored and can be used for A records only anyway.

Very true except that I also mentioned resolv.conf (probably doesn't exist
on windows, though).

Also, good to know about jitsi + windows +laptops.

Freundliche Grüsse,
J

···

On 29 March 2014 17:21, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey

Are the affected machines laptops by any chance? There's a bug in Java
that reports the DNS servers on inactive interfaces as well. So if you've
been on a wireless network, got the 10.xyz address as the DNS server on the
wireless NIC, then got back to the company network, Java still thinks the
10.xyz nameserver is valid. A restart of Jitsi doesn't help, the bug is
caused by the fact that Java reads the DNS servers from the registry
instead of using the proper Windows APIs.

If this doesn't apply to your situation, the only other thing that comes
to mind would be that 10.xyz is configured as a nameserver on a NIC
manually.

The hosts file as mentioned by Jungle is irrelevant for Jitsi, it's not
being honored and can be used for A records only anyway.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

6

Hosts file is clean.

Flushed DNS cache.

Ingo, you may be spot on with your java bug theory. These three are laptops that traverse outside the corporate intranet which are affected.

A restart your of Jitsi, a reinistall, deleting all Jitsi appdata does not resolve the issue.

I will need to do research on this java bug to see where in the registry this DNS nameserver is being pulled from to see if I can clear it.

Hi,

The hosts file as mentioned by Jungle is irrelevant for Jitsi, it's not being honored and can be used for A records only anyway.

Very true except that I also mentioned resolv.conf (probably doesn't exist on windows, though).

Also, good to know about jitsi + windows +laptops.

Freundliche Gr?sse,
J

···

Sent from Divide
On Mar 29, 2014 9:17:24 PM, jungleboogie0 <jungleboogie0@gmail.com> wrote:

On 29 March 2014 17:21, Ingo Bauersachs <ingo@jitsi.org<mailto:ingo@jitsi.org>> wrote:
Hey

Are the affected machines laptops by any chance? There's a bug in Java that reports the DNS servers on inactive interfaces as well. So if you've been on a wireless network, got the 10.xyz address as the DNS server on the wireless NIC, then got back to the company network, Java still thinks the 10.xyz nameserver is valid. A restart of Jitsi doesn't help, the bug is caused by the fact that Java reads the DNS servers from the registry instead of using the proper Windows APIs.

If this doesn't apply to your situation, the only other thing that comes to mind would be that 10.xyz is configured as a nameserver on a NIC manually.

The hosts file as mentioned by Jungle is irrelevant for Jitsi, it's not being honored and can be used for A records only anyway.

Freundliche Gr?sse,
Ingo Bauersachs

-- sent from my mobile

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info<mailto:jungleboogie@sip2sip.info>
xmpp: jungle-boogie@jit.si<mailto:jungle-boogie@jit.si>

7

I will need to do research on this java bug to see where in the registry

this

DNS nameserver is being pulled from to see if I can clear it.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7006496

As with all Java bugs, don't expect to get it fixed by Oracle in the next
millennium.

Sent from Divide

Ingo

8

This appears to be the culprit. The registry key determining what DNS server Jitsi tries first appears to be under the HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Paramaeters\Interfaces\{GUID}

Turning off parallel DNS processing worked on the one laptop because the DNS pulled from the registry was an unreachable IP. So when Jitsi could not reach it, Jitsi immediately started using the corporate DNS.

On another laptop... the DNS pulled from the registry was 8.8.8.8. So what do I do?!?!?! My only options (other than scrap rolling out Jitsi and continue using spark) was to add the SRV and Host(A) record (for the target in the SRV record) to our public DNS so that is resolves on 8.8.8.8.

So, now I'm going to check to see if this public DNS will fix the issue for all PCs or if I will need to

Not an ideal workaround from a security perspective I don't reckon. But now I should be able to get by without disabling parallel DNS processing (not that it hurts anything).

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

···

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Sunday, March 30, 2014 7:14 AM
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

I will need to do research on this java bug to see where in the
registry

this

DNS nameserver is being pulled from to see if I can clear it.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7006496

As with all Java bugs, don't expect to get it fixed by Oracle in the next millennium.

Sent from Divide

Ingo

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

9

Is it possible for Jitsi developers to use the workaround mentioned in the bug report linked by Ingo?

I am surprised this issue has not been raised before unless simply there are not many folks using Jitsi [on roaming windows OS laptops] to communicate on private XMPP servers.

This was really quite a doosey to figure out a workaround for.

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

···

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Aaron Dixon
Sent: Tuesday, April 1, 2014 6:10 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

This appears to be the culprit. The registry key determining what DNS server Jitsi tries first appears to be under the HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Paramaeters\Interfaces\{GUID}

Turning off parallel DNS processing worked on the one laptop because the DNS pulled from the registry was an unreachable IP. So when Jitsi could not reach it, Jitsi immediately started using the corporate DNS.

On another laptop... the DNS pulled from the registry was 8.8.8.8. So what do I do?!?!?! My only options (other than scrap rolling out Jitsi and continue using spark) was to add the SRV and Host(A) record (for the target in the SRV record) to our public DNS so that is resolves on 8.8.8.8.

So, now I'm going to check to see if this public DNS will fix the issue for all PCs or if I will need to

Not an ideal workaround from a security perspective I don't reckon. But now I should be able to get by without disabling parallel DNS processing (not that it hurts anything).

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Sunday, March 30, 2014 7:14 AM
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

I will need to do research on this java bug to see where in the
registry

this

DNS nameserver is being pulled from to see if I can clear it.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7006496

As with all Java bugs, don't expect to get it fixed by Oracle in the next millennium.

Sent from Divide

Ingo

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

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

10

What workaround are you talking about? The bug report at Oracle is from me and doesn't contain one.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 02.04.2014 à 21:31, "Aaron Dixon" <Aaron.Dixon@ssdcservices.com> a écrit :

Is it possible for Jitsi developers to use the workaround mentioned in the bug report linked by Ingo?

I am surprised this issue has not been raised before unless simply there are not many folks using Jitsi [on roaming windows OS laptops] to communicate on private XMPP servers.

This was really quite a doosey to figure out a workaround for.

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Aaron Dixon
Sent: Tuesday, April 1, 2014 6:10 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

This appears to be the culprit. The registry key determining what DNS server Jitsi tries first appears to be under the HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Paramaeters\Interfaces\{GUID}

Turning off parallel DNS processing worked on the one laptop because the DNS pulled from the registry was an unreachable IP. So when Jitsi could not reach it, Jitsi immediately started using the corporate DNS.

On another laptop... the DNS pulled from the registry was 8.8.8.8. So what do I do?!?!?! My only options (other than scrap rolling out Jitsi and continue using spark) was to add the SRV and Host(A) record (for the target in the SRV record) to our public DNS so that is resolves on 8.8.8.8.

So, now I'm going to check to see if this public DNS will fix the issue for all PCs or if I will need to

Not an ideal workaround from a security perspective I don't reckon. But now I should be able to get by without disabling parallel DNS processing (not that it hurts anything).

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Sunday, March 30, 2014 7:14 AM
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

I will need to do research on this java bug to see where in the
registry

this

DNS nameserver is being pulled from to see if I can clear it.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7006496

As with all Java bugs, don't expect to get it fixed by Oracle in the next millennium.

Sent from Divide

Ingo

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

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

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

11

You are right, there is none. I misread your "Customer Submitted Workaround"

My public DNS workaround appears to be working well. I saw this problem crop up on a 4th laptop (that didn’t have the issue when first installed) before I created the DNS records.

Thanks for all your help Ingo. I did not suspect that was your bug report... awesome!

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 | aaron.dixon@ssdcservices.com

···

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Wednesday, April 2, 2014 4:03 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 & 2.5.5114) on Windows 8

What workaround are you talking about? The bug report at Oracle is from me and doesn't contain one.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

Le 02.04.2014 à 21:31, "Aaron Dixon" <Aaron.Dixon@ssdcservices.com> a écrit :

Is it possible for Jitsi developers to use the workaround mentioned in the bug report linked by Ingo?

I am surprised this issue has not been raised before unless simply there are not many folks using Jitsi [on roaming windows OS laptops] to communicate on private XMPP servers.

This was really quite a doosey to figure out a workaround for.

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 |
aaron.dixon@ssdcservices.com

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf
Of Aaron Dixon
Sent: Tuesday, April 1, 2014 6:10 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 &
2.5.5114) on Windows 8

This appears to be the culprit. The registry key determining what DNS
server Jitsi tries first appears to be under the
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Paramaeters\Interfaces\{G
UID}

Turning off parallel DNS processing worked on the one laptop because the DNS pulled from the registry was an unreachable IP. So when Jitsi could not reach it, Jitsi immediately started using the corporate DNS.

On another laptop... the DNS pulled from the registry was 8.8.8.8. So what do I do?!?!?! My only options (other than scrap rolling out Jitsi and continue using spark) was to add the SRV and Host(A) record (for the target in the SRV record) to our public DNS so that is resolves on 8.8.8.8.

So, now I'm going to check to see if this public DNS will fix the
issue for all PCs or if I will need to

Not an ideal workaround from a security perspective I don't reckon. But now I should be able to get by without disabling parallel DNS processing (not that it hurts anything).

Aaron Dixon | IT Specialist | SSDC Services
Office: 248-277-9304 | Cell: 248-935-7353 |
aaron.dixon@ssdcservices.com

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf
Of Ingo Bauersachs
Sent: Sunday, March 30, 2014 7:14 AM
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] DNS Resolver Issue with Jitsi (2.5.5165 &
2.5.5114) on Windows 8

I will need to do research on this java bug to see where in the
registry

this

DNS nameserver is being pulled from to see if I can clear it.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7006496

As with all Java bugs, don't expect to get it fixed by Oracle in the next millennium.

Sent from Divide

Ingo

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

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

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

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