Re: Ris: AWS timeout

2019-05-15 Thread @lbutlr
On 14 May 2019, at 21:35, Ron Wheeler wrote: > If people knew how much of the email travels over the internet as a result of > his work, he would be a tech star. I really doubt he is interested in notoriety. -- 'You're your own worst enemy, Rincewind,' said the sword. Rincewind looked up at th

Re: Ris: AWS timeout

2019-05-14 Thread Ron Wheeler
ible. John Messaggio originale Oggetto: Re: AWS timeout Da: Frank Hare A: John Fawcett CC: postfix-users@postfix.org <mailto:postfix-users@postfix.org> John, Wow, good one dude! Turning off tcp timestamps on the client instantly f

Re: Ris: AWS timeout

2019-05-14 Thread Durga Prasad Malyala
> reproducible. > > John > > > Messaggio originale ---- > Oggetto: Re: AWS timeout > Da: Frank Hare > A: John Fawcett > CC: postfix-users@postfix.org > > > John, > > Wow, good one dude! Turning off tcp timestamps on the client instantly >

Re: Ris: AWS timeout

2019-05-14 Thread Frank Hare
oducible. > > John > > > Messaggio originale ---- > Oggetto: Re: AWS timeout > Da: Frank Hare > A: John Fawcett > CC: postfix-users@postfix.org > > > John, > > Wow, good one dude! Turning off tcp timestamps on the client instantly > fixed it.

Ris: AWS timeout

2019-05-14 Thread j...@voipsupport.it
FrankCredit to Weitse who noticed the strange TSval in the pcap.It does look like an issue with Checkpoint. Good thing is this is reproducible. John Messaggio originale Oggetto: Re: AWS timeoutDa: Frank Hare A: John Fawcett CC: postfix-users@postfix.orgJohn,Wow, good one dude! Turn

Re: AWS timeout

2019-05-14 Thread Frank Hare
John, Wow, good one dude! Turning off tcp timestamps on the client instantly fixed it. So I guess I bring this to Checkpoint Support and see what they say, THAT should be fun. Thanks! On Tue, May 14, 2019 at 3:02 AM John Fawcett wrote: > On 14/05/2019 01:27, Wietse Venema wrote: > > Wietse Ven

Re: AWS timeout

2019-05-14 Thread John Fawcett
On 14/05/2019 01:27, Wietse Venema wrote: > Wietse Venema: >> If you look at the non-VPN captures, then you will see the following: >> >> - In one trace, we see a client ACK 138, followed by a client packet >> with "." (data 443:446, ACK 138, and a timestamp field >> tht is unlike those of al o

Re: AWS timeout

2019-05-13 Thread John Fawcett
On 14/05/2019 01:27, Wietse Venema wrote: > Wietse Venema: >> If you look at the non-VPN captures, then you will see the following: >> >> - In one trace, we see a client ACK 138, followed by a client packet >> with "." (data 443:446, ACK 138, and a timestamp field >> tht is unlike those of al o

Re: AWS timeout

2019-05-13 Thread Wietse Venema
Wietse Venema: > If you look at the non-VPN captures, then you will see the following: > > - In one trace, we see a client ACK 138, followed by a client packet > with "." (data 443:446, ACK 138, and a timestamp field > tht is unlike those of al other packets in the stream). > > - In the other

Re: AWS timeout

2019-05-13 Thread Wietse Venema
Wietse Venema: > fhare: > > Hello list, > > > > Bit of a weird one here. I have hosts at AWS sending mail across a > > Checkpoint VPN to my main private relay server (it basically serves to relay > > mail to O365 for in house applications). The problem is that the sending > > client never receive

Re: AWS timeout

2019-05-13 Thread Wietse Venema
fhare: > Hello list, > > Bit of a weird one here. I have hosts at AWS sending mail across a > Checkpoint VPN to my main private relay server (it basically serves to relay > mail to O365 for in house applications). The problem is that the sending > client never receives BYE from server after QUIT.

AWS timeout

2019-05-13 Thread fhare
Hello list, Bit of a weird one here. I have hosts at AWS sending mail across a Checkpoint VPN to my main private relay server (it basically serves to relay mail to O365 for in house applications). The problem is that the sending client never receives BYE from server after QUIT. The mail goes thro