• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Network test failed
#1
I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
  Reply
#2
(04-13-2020, 02:56 PM)jcmartin3@rocketmail.com Wrote: I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
Well known and much discussed issue (use the search)
Just proceed, it'll be fine. (unless your values are way-off, than you cannot)
  Reply
#3
(04-13-2020, 03:01 PM)Dimitri Muskens Wrote:
(04-13-2020, 02:56 PM)jcmartin3@rocketmail.com Wrote: I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
Well known and much discussed issue (use the search)
Just proceed, it'll be fine. (unless your values are way-off, than you cannot)

I did this because it wasn't working and I wanted to know why. Maybe I need to just get into a session with Wireshark running and see what happens. But I find it odd that the network test doesn't use the same UDP ports that are required for the sessions.
  Reply
#4
Don't make it to technical. It is challenging to get all nerdy into networking issues. I know, I am/do the same Big Grin
Most (a lot!) of people get this working without the slightest knowledge of networking and protocols. Most times it is something 'simple' that causes the service not to function.
The traffic your logging is the app 'calling home' and has no bearing on your p2p connection/session to other jammers.

Can you start a solo session and hear your own audio when local monitoring is switched off?
  Reply
#5
(04-13-2020, 03:28 PM)Dimitri Muskens Wrote: Don't make it to technical. It is challenging to get all nerdy into networking issues. I know, I am/do the same Big Grin
Most (a lot!) of people get this working without the slightest knowledge of networking and protocols. Most times it is something 'simple' that causes the service not to function.
The traffic your logging is the app 'calling home' and has no bearing on your p2p connection/session to other jammers.

Can you start a solo session and hear your own audio when local monitoring is switched off?

Sorry, I'm a network engineer IRL, it's what I do...

When i connect the computer directly to a cable modem, it works. I joined a session with a friend and we could hear and see each other. When I put it behind a firewall, it doesn't. For obvious reasons, I really don't want to leave the computer out there, so I'm trying to configure the firewall to allow the required traffic, and the packet trace of the network test was supposed to tell me what I was missing. Instead it left me with more questions.

It would help if the network test servers were more reliable, but I understand that you are fighting through that issue.
  Reply
#6
It may be so that you are a network engineer

But that is not a argument - that is a circumstance

Good luck - anyway!
  Reply
#7
Forward your UDP ports 12000 to 12010. It's what I've done. I know that it fails GRC.com $elds-up test on this port but hey, I wanna jam and accept the risk (numerous backups of Macs and Windows computers).

What's up with the dollar sign replacing "$..."? It is "$elds-Up".
  Reply
#8
(04-13-2020, 02:56 PM)jcmartin3@rocketmail.com Wrote: I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
This is the only thread so far that mentions STUN.  When I first boot-up my ASUS laptop (2013)  I get a message saying that the STUN test failed.  Sometimes I also get a message that something has not be able to bind with the  UPD port 12000. I do have those set in the router as described above.

How do I determine if "are not changed, and are allowed back in and forwarded to the correct computer."?
How do I grab " a packet capture of a network test"?
Where would I see STUN traffic?--and how do I perform the same test as described above.

I have a Focusrite Scarlett 2i2 Audio Interface

I am no engineer.  I am a professional musician, violinist and other strings, experienced across multiple genre's trying to keep my musical life and that of my students going.  My goal is an online orchestra.  It is desperately needed.  I know it is far away as of yet.  However, I am fearless at trying tech things, and trying to understand them.  I am in the weeds here.  Profoundly.

I would appreciate some encouragement and or advice.  Thanks, LisaJo
  Reply
#9
(07-15-2020, 07:47 PM)LisaJo Borchers Wrote:
(04-13-2020, 02:56 PM)jcmartin3@rocketmail.com Wrote: I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
This is the only thread so far that mentions STUN.  When I first boot-up my ASUS laptop (2013)  I get a message saying that the STUN test failed.  Sometimes I also get a message that something has not be able to bind with the  UPD port 12000. I do have those set in the router as described above.

How do I determine if "are not changed, and are allowed back in and forwarded to the correct computer."?
How do I grab " a packet capture of a network test"?
Where would I see STUN traffic?--and how do I perform the same test as described above.

I have a Focusrite Scarlett 2i2 Audio Interface

I am no engineer.  I am a professional musician, violinist and other strings, experienced across multiple genre's trying to keep my musical life and that of my students going.  My goal is an online orchestra.  It is desperately needed.  I know it is far away as of yet.  However, I am fearless at trying tech things, and trying to understand them.  I am in the weeds here.  Profoundly.

I would appreciate some encouragement and or advice.  Thanks, LisaJo

Hi LisaJo,

If anyone here understands packet captures, they never replied to me saying so. My problem was with my firewall, and my only resolution was to bypass it and plug directly into the cable modem.  I didn't like doing it, but it got me jamming.

John
  Reply
#10
(07-15-2020, 07:59 PM)jcmartin3@rocketmail.com Wrote:
(07-15-2020, 07:47 PM)LisaJo Borchers Wrote:
(04-13-2020, 02:56 PM)jcmartin3@rocketmail.com Wrote: I've set up the network as suggested, making sure UDP ports 12000-12010 (overkill, I know) are not changed, and are allowed back in and forwarded to the correct computer.  I grabbed a packet capture of a network test when I was finally able to run one. I saw no packets going out using this UDP port range. I did, however, see STUN traffic, so I did the same with the standard STUN UDP port, reran the test, and it still failed.  I see STUN traffic going to one server (74.125.192.127) and I'm getting replies. I then see it change to another server (63.114.108.101) and I'm getting ICMP port unreachable messages back from it. It continues to send STUN binding requests to both addresses, still getting binding responses from the first and ICMP port unreachable messages from the second. It then switches to sending TCP traffic to 45.79.61.39, first on port 6767 then on 80 (http). At that point the test ends and I get the failure message.  If you need me to send a copy of the Wireshark packet capture, send me an email and I can forward it along.

Thanks,
John
This is the only thread so far that mentions STUN.  When I first boot-up my ASUS laptop (2013)  I get a message saying that the STUN test failed.  Sometimes I also get a message that something has not be able to bind with the  UPD port 12000. I do have those set in the router as described above.

How do I determine if "are not changed, and are allowed back in and forwarded to the correct computer."?
How do I grab " a packet capture of a network test"?
Where would I see STUN traffic?--and how do I perform the same test as described above.

I have a Focusrite Scarlett 2i2 Audio Interface

I am no engineer.  I am a professional musician, violinist and other strings, experienced across multiple genre's trying to keep my musical life and that of my students going.  My goal is an online orchestra.  It is desperately needed.  I know it is far away as of yet.  However, I am fearless at trying tech things, and trying to understand them.  I am in the weeds here.  Profoundly.

I would appreciate some encouragement and or advice.  Thanks, LisaJo

Hi LisaJo,

If anyone here understands packet captures, they never replied to me saying so. My problem was with my firewall, and my only resolution was to bypass it and plug directly into the cable modem.  I didn't like doing it, but it got me jamming.

John
John, thanks for your reply! Bypass the firewall?  Is this something I have to designate as an exception? What am I plugging directly into the modem, my ethernet cable? My Audio Interface? I need to try this.  I so appreciate your kindness-- LisaJo
  Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)