Don't suppose you could be slightly more specific on that experimental thing for someone who doesn't have any history with vcs cli...
Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA Network Engineer Direct Voice: 443.541.1518 Facebook<https://www.facebook.com/heliontech?ref=hl> | Twitter<https://twitter.com/HelionTech> | LinkedIn<https://www.linkedin.com/company/helion-technologies?trk=top_nav_home> | G+<https://plus.google.com/+Heliontechnologies/posts> From: cisco-voip [mailto:[email protected]] On Behalf Of Ryan Ratliff (rratliff) Sent: Friday, February 27, 2015 4:06 PM To: Justin Steinberg Cc: cisco-voip voyp list Subject: Re: [cisco-voip] Jabber, MRA, and Free Public WiFi CSCup73547 is of interest here. While you are playing with this check out the experimental section of xconfig. -Ryan On Feb 27, 2015, at 3:31 PM, Justin Steinberg <[email protected]<mailto:[email protected]>> wrote: good write up. I wonder what would happen if the _collab-edge._tls SRV returned port 443 with an internet firewall in front of Expressway translating 443 to 8443. I wonder whether the Jabber clients read the port from the SRV or whether they have 8443 hardcoded. I'll try to test that on my next deployment. On Fri, Feb 27, 2015 at 2:02 PM, Anthony Holloway <[email protected]<mailto:[email protected]>> wrote: All, Just a heads up to my fellow techs, I am at Caribou Coffee today and my Jabber will not sign in. The user experience is as follows: Jabber discovers MRA successfully, but when trying to authenticate it sends an auth request to: https://collab-edge.company.com:8443/oauthcb The logs show that an HTTP timeout occurs: (Found in C:\Users\<you>\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Logs\csf-unified.log) 2015-02-27 09:14:40,081 INFO [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1163)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - *-----* Making HTTP request to: https://collab-edge.company.com:8443/oauthcb [3] 2015-02-27 09:14:40,081 INFO [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1738)] [csf.httpclient] [http::CurlHeaders::CurlHeaders] - Number of Request Headers : 1 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1345)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Checking for proxy information for request [3] ... 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [ts\csf-netutils\src\http\Request.cpp(83)] [csf.httpclient] [http::Request::getProxy] - No Proxy will be used per configuration of this request 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1429)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - No proxy information available [3]. 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1502)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Setting connect timeout value in milliseconds to : 10000 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1511)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Setting transfer timeout value in milliseconds to : 30000 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1514)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - HTTP Request Configured. 2015-02-27 09:14:40,081 DEBUG [0x00000af0] [ls\src\http\BasicHttpClientImpl.cpp(482)] [csf.httpclient] [http::performCurlRequest] - About to perform curl connection request... 2015-02-27 09:14:40,096 DEBUG [0x00000af0] [netutils\src\http\CurlHttpUtils.cpp(307)] [csf.httpclient] [http::CurlHttpUtils::logPhaseData] - Pre connect phase. Resolved IP: 23.23.23.23 2015-02-27 09:14:50,079 DEBUG [0x00000af0] [etutils\src\http\CurlHttpUtils.cpp(1679)] [csf.httpclient] [http::CurlHttpUtils::logOperationTiming] - Network IO timestamps: [name lookup = 0.016 ; connect = 0 ; ssl connect = 0 ; pre-transfer = 0 ; start-transfer = 0 ; total = 10 ; redirect = 0] 2015-02-27 09:14:50,079 INFO [0x00000af0] [ls\src\http\CurlAnswerEvaluator.cpp(117)] [csf.httpclient] [http::CurlAnswerEvaluator::curlCodeToResult] - curlCode=[28] error message=[Connection timed out after 10000 milliseconds] result=[CONNECTION_TIMEOUT_ERROR] fips enabled=[false] 2015-02-27 09:14:50,079 INFO [0x00000af0] [ls\src\http\BasicHttpClientImpl.cpp(410)] [csf.httpclient] [http::executeImpl] - *-----* HTTP response from: https://collab-edge.company.com:8443/oauthcb [3] -> 0. 2015-02-27 09:14:50,079 ERROR [0x00000af0] [ls\src\http\BasicHttpClientImpl.cpp(414)] [csf.httpclient] [http::executeImpl] - There was an issue performing the call to curl_easy_perform: CONNECTION_TIMEOUT_ERROR 2015-02-27 09:14:50,079 DEBUG [0x00000af0] [etutils\src\http\HttpRequestData.cpp(90)] [csf.httpclient] [http::HttpRequestData::returnEasyCURLConnection] - Returning borrowed EasyCURLConnection from request : 3 2015-02-27 09:14:50,079 DEBUG [0x00000af0] [utils\adapters\EdgeUtilsAdapter.cpp(255)] [csf.netutils.adapters] [netutils::adapters::EdgeUtilsAdapter::isRequestTransformed] - isRequestTransformed: result:0. originalPath: '/oauthcb' pathFromUrlUsed: '/oauthcb'. 2015-02-27 09:14:50,079 DEBUG [0x00000af0] [tutils\src\http\HttpRequestData.cpp(105)] [csf.httpclient] [http::HttpRequestData::~HttpRequestData] - Destroying instance of Request data, with request: 3 And then I get the message in Jabber which says "Cannot Communicate with the Server" <image.png> It turns out that if I try to telnet to collab-edge.company.com<http://collab-edge.company.com/> on port 8443, it fails: <image.png> And a Wireshark reveals that the TCP three way handshake never happens, with two TCP SYN re-transmits, before finally timing out. <image.png> Interestingly, this free WiFi network does not prevent me from accessing the standard HTTPS port of 443, and I can actually login to the collab-edge.company.com<http://collab-edge.company.com/> web interface and login. So, it would seem like they are treating non-standard ports differently here. If I knew of a non standard HTTP port (E.g., 8080, 8088, etc.) to attempt to connect to on the public internet...wait a minute: http://portquiz.net/ Yes! This site was setup for exactly what I need: validating my theory, and I was right. You cannot hit this website on any port other than the standard HTTP/HTTPS ports from here at Caribou Coffee. Also, just to be thorough, I've ruled out my PC, my Jabber client, our MRA solution, our enterprise network, basically everything, by simply flipping over to my mobile hotspot on my iPhone and it works immediately. Here are the logs from the same process as above while using my mobile hotspot: 2015-02-27 09:25:01,991 INFO [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1163)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - *-----* Making HTTP request to: https://collab-edge.company.com:8443/oauthcb [7] 2015-02-27 09:25:01,991 INFO [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1738)] [csf.httpclient] [http::CurlHeaders::CurlHeaders] - Number of Request Headers : 1 2015-02-27 09:25:01,991 DEBUG [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1345)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Checking for proxy information for request [7] ... 2015-02-27 09:25:01,991 DEBUG [0x00000798] [ts\csf-netutils\src\http\Request.cpp(83)] [csf.httpclient] [http::Request::getProxy] - No Proxy will be used per configuration of this request 2015-02-27 09:25:01,991 DEBUG [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1429)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - No proxy information available [7]. 2015-02-27 09:25:01,991 DEBUG [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1502)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Setting connect timeout value in milliseconds to : 10000 2015-02-27 09:25:01,991 DEBUG [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1511)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - Setting transfer timeout value in milliseconds to : 30000 2015-02-27 09:25:01,991 DEBUG [0x00000798] [etutils\src\http\CurlHttpUtils.cpp(1514)] [csf.httpclient] [http::CurlHttpUtils::configureEasyRequest] - HTTP Request Configured. 2015-02-27 09:25:01,991 DEBUG [0x00000798] [ls\src\http\BasicHttpClientImpl.cpp(482)] [csf.httpclient] [http::performCurlRequest] - About to perform curl connection request... 2015-02-27 09:25:02,007 DEBUG [0x00000798] [netutils\src\http\CurlHttpUtils.cpp(307)] [csf.httpclient] [http::CurlHttpUtils::logPhaseData] - Pre connect phase. Resolved IP: 23.23.23.23 2015-02-27 09:25:02,101 DEBUG [0x00000798] [netutils\src\http\CurlHttpUtils.cpp(316)] [csf.httpclient] [http::CurlHttpUtils::logPhaseData] - Connection established 2015-02-27 09:25:02,101 DEBUG [0x00000798] [netutils\src\http\OpenSSLOptions.cpp(29)] [csf.httpclient] [http::OpenSSLOptions::getOptions] - OpenSSL Options: SSL_OP_NO_SSLv2 SSL_OP_NO_SSLv3 2015-02-27 09:25:02,101 DEBUG [0x00000798] [netutils\src\http\CurlHttpUtils.cpp(564)] [csf.httpclient] [http::CurlHttpUtils::curlSSLCallback] - fqdn : collab-edge.company.com<http://collab-edge.company.com/> 2015-02-27 09:25:02,101 DEBUG [0x00000798] [netutils\src\http\CurlHttpUtils.cpp(323)] [csf.httpclient] [http::CurlHttpUtils::logPhaseData] - SSL handshake phase. SSL version : SSLv3 There are two lessons here for me: 1. MRA has the potential to fail from free public WiFi networks (Hotels, Coffee Shops, Airplanes, Submarines, Virgin Galactic, etc.), and potentially any network, where there is some sort of traffic filtering going on. In fact, this public WiFi and filtering traffic is pretty common and people have been proxying their traffic through their own servers to bypass this limitation. Case in point.<http://rogueleaderr.com/post/29855576743/never-again-be-thwarted-by-restrictive-guest> So, I wonder, is there a Cisco solution, or a commonly used solution to proxy the MRA traffic (which itself is a proxy of sorts for FW traversal), to ensure a great user experience no matter the network they join? 2. I learned how to troubleshoot and identify the problem which all started from a very unhelpful error message in Jabber "Cannot communicate with the server" It would be swell if Cisco could use standard ports (E.g., 443). If that's just not possible for some developer reason, then another suggestion would be to wait for the HTTP timeout, then connect to the edge server on a standard port to validate reach-ability. If this was possible, then they could raise a warning which states "The network you are on is blocking port 8443 traffic. Contact your network Administrator for further assistance." At least then users would be prompted to move off that network, or attempt an alternative connection method, such as a mobile hotspot. I look forward to your thoughts on the matter. Have a nice weekend all. PS Fake names and IP addresses were used to protect the identity of the real network. All errors and messages are consistent with the real tests. _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
