Am 15.05.2015 um 18:17 schrieb Gordon Messmer <gordon.messmer at gmail.com>:> On 05/15/2015 09:02 AM, Leon Fauster wrote: >> >> I have a public peer system (yy.yy.yy.yy) that is reachable >> via my home uplink (xx.xx.xx.xxx). >> >> 15:59:30.244199 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0 >> 15:59:30.281931 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 0 >> 15:59:30.281945 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0 >> 15:59:30.305020 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 105 >> 15:59:30.344004 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 1412 >> 15:59:30.344013 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0 >> 15:59:30.344016 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 23 >> >> At the office we have a EL5 based router that can not reach the >> mentioned system. It does not give any hint about the problem. >> >> 15:57:51.751591 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> 15:57:54.750834 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> 15:58:00.749351 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> 15:58:12.746408 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> 15:58:36.740454 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> 15:59:24.728605 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0 >> >> I tried to connect with a removed ecn bit [1] >> >> [1] https://en.wikipedia.org/wiki/Explicit_Congestion_Notification >> >> but this was not the solution. >> >> Any ideas? > > That's not much information to go on. Can you run > tcpdump on the "public peer system"? Does it receive > the SYN packets from your office?Well, the destination is not in my realm (different provider). Before contacting them I want to be sure that my system is not causing this. So far i just see a "tcp retransmission" while trying to establish a https connection (captured on our router): office -> destination: TCP 66 54487?443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=8 office -> destination: TCP 66 [TCP Retransmission] 54487?443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=8 from my home and office, I can see via traceroute that for the destination the entry hop is the same. So, the destination is not responding with SYN,ACK when the connection passes our router. But as I said it is reachable from my home, and this is confusing. Thanks, LF
On 17/05/15 03:23, Leon Fauster wrote:> Am 15.05.2015 um 18:17 schrieb Gordon Messmer <gordon.messmer at gmail.com>: >> On 05/15/2015 09:02 AM, Leon Fauster wrote: >>> So, the destination is not responding with SYN,ACK when the connection passes >>> our router. But as I said it is reachable from my home, and this is confusing. >>> >>>In such situations, I use HPING in the following manner: hping3 -n -T -S -p 443 yy.yy.yy.yy Breakdown: -n - do not do DNS resolution -T - traceroute mode -S - send SYN packet (you should see flags=SA in the output for a reachable machine) -p - the destination port - 443 in this case You can a -t ## to start off with a larger tty than the default 0. Cheers, ak.
On 05/16/2015 10:23 AM, Leon Fauster wrote:> Well, the destination is not in my realm (different provider). Before > contacting them I want to be sure that my system is not causing this. > So far i just see a "tcp retransmission" while trying to establish > a https connection (captured on our router):That can be difficult to establish. If you're getting no response, the most likely problems are either a bad route or a firewall rule somewhere along the path. The problem could exist at anywhere along the path, and they'll typically both look the same according to tests at your host. As Anthony pointed out, you can use hping3 in TCP traceroute mode to determine where along the path the problem probably exists. The first host to not respond should be the host with the problem. Hopefully you have access to a host that has access and a similar path to the host you can't reach. If so, the same hping3 command should give you the complete traceroute path, and from there you can find the host that didn't respond in the first test.
Am 18.05.2015 um 18:25 schrieb Gordon Messmer <gordon.messmer at gmail.com>:> On 05/16/2015 10:23 AM, Leon Fauster wrote: >> Well, the destination is not in my realm (different provider). Before >> contacting them I want to be sure that my system is not causing this. >> So far i just see a "tcp retransmission" while trying to establish >> a https connection (captured on our router): > > That can be difficult to establish. If you're getting no response, the most likely problems > are either a bad route or a firewall rule somewhere along the path. The problem could exist > at anywhere along the path, and they'll typically both look the same according to tests at your host. > > As Anthony pointed out, you can use hping3 in TCP traceroute mode to determine where along > the path the problem probably exists. The first host to not respond should be the host with > the problem. Hopefully you have access to a host that has access and a similar path to the > host you can't reach. If so, the same hping3 command should give you the complete traceroute > path, and from there you can find the host that didn't respond in the first test.I could determine that the problem didn't sits on our systems now. The carrier of the endpoint has a ticket open now and I'm betting with my colleagues how fast they will be :-) Thanks for the pointers! -- LF