3 Replies Latest reply on Jul 9, 2013 6:31 AM by flmmaas

    Difference Cirrus vs AMS wrt Symmetric NAT

    flmmaas

      Hi,

       

      I'm still debugging rtmfp-via-ams-server as fallback in case Symmetric NAT blocks direct peer-to-peer.

      Looking into tcpdumps on server as well as client I am a bit surprised to see that AMS is already sending a packet from the allocated port ( say 19351 ) to client before client has sent a packet out to the server. I thought the hole punching idea was to let the client send out a packet, thereby creating the hole, after which the other end could send something back in.

      When I look into Cirrus behaviour I see it always waits for the client to send something, and only then it will send out a packet from the new port. In case of Cirrus I can always create a connection to obtains a peer id. With my own AMS 5 server this does not work. The initial NetConnection fails in most cases.

       

      Server is not behind a NAT. I nevertheless specified tight hostport configuration to be sure we are using correct ip's, which we appear to do.

       

      This is tcpdump on the AMS 5 server:

      21:45:44.646944 IP 86.90.7.99.59486 > 46.22.183.164.1935: UDP, length 84

      21:45:44.647229 IP 46.22.183.164.1935 > 86.90.7.99.59486: UDP, length 36

      21:45:44.647458 IP 46.22.183.164.19351 > 86.90.7.99.59486: UDP, length 36    << to my opinion this one is premature

       

      And this is tcpdump on the client in the Symmetric NAT network:

      21:45:44.637198 IP 192.168.2.8.59486 > 46.22.183.164.1935: UDP, length 84

      21:45:44.649048 IP 46.22.183.164.1935 > 192.168.2.8.59486: UDP, length 36

      21:45:44.649165 IP 192.168.2.8.59486 > 46.22.183.164.19351: UDP, length 84   << as long as this one hasn't arrived

       

      Wouldn't it be possible that some NAT's don't like this unsolicited ( premature ) input and just close the door?

       

      Here is client side Cirrus traffic from the same Symmetric NAT network:

      21:39:15.168443 IP 192.168.2.8.54168 > 50.57.90.134.1935: UDP, length 68

      21:39:15.168479 IP 192.168.2.8.54168 > 50.57.90.201.1935: UDP, length 68

      21:39:15.321611 IP 50.57.90.134.1935 > 192.168.2.8.54168: UDP, length 52

      21:39:15.321740 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 68

      21:39:15.321802 IP 192.168.2.8.54168 > 50.56.33.122.10007: UDP, length 68

      21:39:15.326992 IP 50.57.90.201.1935 > 192.168.2.8.54168: UDP, length 52

      21:39:15.327097 IP 192.168.2.8.54168 > 50.56.33.168.10004: UDP, length 68

      21:39:15.434747 IP 50.56.33.171.10004 > 192.168.2.8.54168: UDP, length 180

      21:39:15.434934 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 308

      21:39:15.472333 IP 50.56.33.122.10007 > 192.168.2.8.54168: UDP, length 180

      21:39:15.474656 IP 50.56.33.168.10004 > 192.168.2.8.54168: UDP, length 180

      21:39:15.543541 IP 50.56.33.171.10004 > 192.168.2.8.54168: UDP, length 164

      21:39:15.545248 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 404

      21:39:15.653017 IP 50.56.33.171.10004 > 192.168.2.8.54168: UDP, length 180

      21:39:15.653122 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 20

      21:39:15.734895 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 68

      21:39:15.842737 IP 50.56.33.171.10004 > 192.168.2.8.54168: UDP, length 52

      21:39:16.043925 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 20

      21:39:25.970343 IP 192.168.2.8.54168 > 50.56.33.171.10004: UDP, length 20

       

      The message from server port 10004 does come AFTER the outbound request to that port.

       

      Hope this makes sense.

       

      Regards,

      Frans

        • 1. Re: Difference Cirrus vs AMS wrt Symmetric NAT
          Michael Thornburgh Adobe Employee

          cirrus also tries to send that first RHello from the new server/port, but it is a different physical computer than the initial redirector, so there might be a higher delay than in the case of your AMS.

           

          certain defective NATs may block UDP traffic even after an outbound packet should open a hole, if the first packet came in unsolicited from a different address/port.   this NAT behavior is wrong. i haven't seen this reported in quite some time. the last time i saw it, a firmware update on the NAT to a current firmware revision resolved the problem.

           

          you can disable this unsolicited first RHello packet by changing the "ForwardIHelloMode" element in Adaptor.xml from "rhello" to "ignore". see if that clears up your problem.  see also the comments in that xml file around that element.

          • 2. Re: Difference Cirrus vs AMS wrt Symmetric NAT
            flmmaas Level 1

            Hi Michael,

             

            Yes, it seems to clear up my problem, at least on first sight.

            I tested it with one client.

            It even does not trigger fallback to server solution anymore, as the session appears peer-to-peer.

             

            Further testing with other clients scheduled for monday and tuesday.

             

            Question: assuming that ForwardIHelloMode servers a purpose, what impact could this change have; for instance, could it break other situations?

             

            The box is a VGV7519, labeled as KPN Experia Box v8.

            This box is being rolled out as part of glassfiber initiatives in many cities in The Netherlands.

            Firmware upgrade is not an option, given the large number of clients that are affected, and we do not control there private infrastructure.

             

            Still I would comment that sending out unsolicited packets from ports that aren't punched open yet is against the whole idea behind NAT traversal. I tend to report it as a bug. Would like to have your opnion on this.

             

            Regards,

            Frans

            • 3. Re: Difference Cirrus vs AMS wrt Symmetric NAT
              flmmaas Level 1

              Further testing with two more clients with the same KPN Experia Box v8 has proven successful.

              In both of these cases though, different from the test with the first user last week, the fallback has kicked in, but with good results, and rtmfp streaming via the AMS.