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

    Difference Cirrus vs AMS wrt Symmetric NAT




      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 > UDP, length 84

      21:45:44.647229 IP > UDP, length 36

      21:45:44.647458 IP > 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 > UDP, length 84

      21:45:44.649048 IP > UDP, length 36

      21:45:44.649165 IP > 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 > UDP, length 68

      21:39:15.168479 IP > UDP, length 68

      21:39:15.321611 IP > UDP, length 52

      21:39:15.321740 IP > UDP, length 68

      21:39:15.321802 IP > UDP, length 68

      21:39:15.326992 IP > UDP, length 52

      21:39:15.327097 IP > UDP, length 68

      21:39:15.434747 IP > UDP, length 180

      21:39:15.434934 IP > UDP, length 308

      21:39:15.472333 IP > UDP, length 180

      21:39:15.474656 IP > UDP, length 180

      21:39:15.543541 IP > UDP, length 164

      21:39:15.545248 IP > UDP, length 404

      21:39:15.653017 IP > UDP, length 180

      21:39:15.653122 IP > UDP, length 20

      21:39:15.734895 IP > UDP, length 68

      21:39:15.842737 IP > UDP, length 52

      21:39:16.043925 IP > UDP, length 20

      21:39:25.970343 IP > UDP, length 20


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


      Hope this makes sense.




        • 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.




            • 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.