Hello.
On Mon, Aug 15, 2022 at 07:19:51PM +0300, Evgeniy Berdnikov wrote:
> On Mon, Aug 15, 2022 at 03:20:57PM +, Slavko via Exim-users wrote:
> >
> > The 5.18 kernel is available in debian stable backports repo [1], IMO
> > best will be to try it first, if it has this fix and if it fixes t
Dňa 15. augusta 2022 16:19:51 UTC používateľ Evgeniy Berdnikov via Exim-users
napísal:
> patch was presented in April (12.04.2022), but only 12.08.2022 (3 days ago)
> has been pushed to git-master.
Oh, i miss that it was pushed only 3 days ago. You are right, it will not be in
debian
yet (IMO n
On Mon, Aug 15, 2022 at 03:20:57PM +, Slavko via Exim-users wrote:
> Dňa 15. augusta 2022 13:49:37 UTC používateľ Jeremy Harris via Exim-users
> napísal:
>
> >Marc, the best route will be for you to open a Debian bug including the
> >above. According to https://www.debian.org/Bugs/Reporting
Dňa 15. augusta 2022 13:49:37 UTC používateľ Jeremy Harris via Exim-users
napísal:
>Marc, the best route will be for you to open a Debian bug including the
>above. According to https://www.debian.org/Bugs/Reporting there is a utility
>"reportbug" to use.
The 5.18 kernel is available in debian
On 15/08/2022 14:31, Viktor Dukhovni via Exim-users wrote:
I strongly suspect this is a known issue with interactions between
Exim and TFO causing machines to ignore packets, which was reported
in this thread:
https://lore.kernel.org/lkml/E1nZMdl-0006nG-0J@plastiekpoot/
On Fri, Aug 12, 2022 at 12:31:16PM -0400, Viktor Dukhovni via Exim-users wrote:
> If the problem persists with as much as possible of the hardware assist
> disabled, then it sure looks like Linux TCP is the culprit.
Unsurprisingly, this is indeed a Linux bug. Neal Cardwell from Google
shared the
On Fri, Aug 12, 2022 at 08:31:37AM +0100, Graeme Coates via Exim-users wrote:
> I repeated the test with tso off in the NIC. Process as follows:
>
> 1. Stop Exim, remove fastopen exclusion in transport conf.
> 2. ethtool -K eth0 tso off; ethtool -K eth0 tx off
> 3. Restart exim, retest.
>
> Stil
On 11/08/2022 22:23, Graeme Coates via Exim-users wrote:
No problem - here's a link to the pcap file filtered down by port 44884.
https://www.chromosphere.co.uk/wp-content/blogs.dir/1/files/2022/08/tfo.zip
Attached is the time-sequence plot for that. I agree with Viktor:
this is a problem in
On 12/08/2022 08:31, Graeme Coates via Exim-users wrote:
generic-segmentation-offload: on
This might still be enabling transmit using >MTU from the kernel to the NIC.
Get a pcap to check; any >1500 byte packets being sent?
I agree with Viktor though - it's a
I repeated the test with tso off in the NIC. Process as follows:
1. Stop Exim, remove fastopen exclusion in transport conf.
2. ethtool -K eth0 tso off; ethtool -K eth0 tx off
3. Restart exim, retest.
Still experiencing timeouts in a similar fashion much as before - tshark
summary:
https://www.chr
On Fri, Aug 12, 2022 at 06:30:21AM +0100, Andrew C Aitchison via Exim-users
wrote:
> > It looks *strongly* like an interoperability problem between the Linux
> > kernel TCP implementation and the Google TCP/TLS termination front-ends,
> > unless all the Exim users who lately somewhat regularly sh
On Wed, 10 Aug 2022, Viktor Dukhovni via Exim-users wrote:
On Wed, Aug 10, 2022 at 04:00:51PM -0700, Marc MERLIN wrote:
I've also reached out to the Gmail team. They're aware. Which is not
to say that there's a quick fix in the works, the front-end connection
termination devices are both non
On Thu, Aug 11, 2022 at 10:23:47PM +0100, Graeme Coates via Exim-users wrote:
> > At this point it would be useful to see the full PCAP file for just the
> > traffic involving client port "44884".
> >
> > $ tcpdump -s0 -r /some/file.pcap -w /tmp/tfo.pcap tcp port 44884
> >
> > The tshark summa
On Thu, 11 Aug 2022 at 17:21, Viktor Dukhovni via Exim-users <
exim-users@exim.org> wrote:
>
> At this point it would be useful to see the full PCAP file for just the
> traffic involving client port "44884".
>
> $ tcpdump -s0 -r /some/file.pcap -w /tmp/tfo.pcap tcp port 44884
>
> The tshark su
On Thu, Aug 11, 2022 at 09:06:28PM +0100, Mike Tubby via Exim-users wrote:
> I have experienced the same... seems to happen one every 2-3 weeks and I
> think it depends on which actual server in Google's cluster you get
> connected to.
>
> Google's implementation of SMTP seems to be very poor a
Mark,
I have experienced the same... seems to happen one every 2-3 weeks and I
think it depends on which actual server in Google's cluster you get
connected to.
Google's implementation of SMTP seems to be very poor at reporting
actual problems, rather it either accepts delivery (and presumab
On Thu, Aug 11, 2022 at 02:55:51PM +0100, Graeme Coates via Exim-users wrote:
> > Can you post a "tshark" decode of a full capture of a failed delivery?
> >
> > # tcpdump -s0 -w /some/file.pcap ...
> > # tshark -nr /some/file
> >
> > [ Keep the PCAP file, more questions may arise once the
On Thu, 11 Aug 2022 at 00:51, Viktor Dukhovni via Exim-users <
exim-users@exim.org> wrote:
>
> Can you post a "tshark" decode of a full capture of a failed delivery?
>
> # tcpdump -s0 -w /some/file.pcap ...
> # tshark -nr /some/file
>
> [ Keep the PCAP file, more questions may arise once t
Dňa 10. augusta 2022 23:39:08 UTC používateľ Viktor Dukhovni via Exim-users
napísal:
>It would perhaps be useful to also see any reports of success sending
>sufficiently large messages to Gmail from the reported Exim builds and
>Linux versions. If some users are not seeing any issues, then it w
On Wed, Aug 10, 2022 at 04:00:51PM -0700, Marc MERLIN wrote:
> > I've also reached out to the Gmail team. They're aware. Which is not
> > to say that there's a quick fix in the works, the front-end connection
> > termination devices are both non-trivial and critical, so changes will
> > happen c
On Wed, Aug 10, 2022 at 06:46:16PM -0400, Viktor Dukhovni via Exim-users wrote:
> On Wed, Aug 10, 2022 at 11:17:43PM +0100, Andrew C Aitchison via Exim-users
> wrote:
>
> > On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
> >
> > > On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris vi
On Wed, Aug 10, 2022 at 11:17:43PM +0100, Andrew C Aitchison via Exim-users
wrote:
> On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
>
> > On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users
> > wrote:
> >> That's extremwly weird. I can't see a logical connection betwe
On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users wrote:
That's extremwly weird. I can't see a logical connection between the
TCP startup detail and a problem that late in the SMTP conversation.
That was my thought to
On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users wrote:
> That's extremwly weird. I can't see a logical connection between the
> TCP startup detail and a problem that late in the SMTP conversation.
That was my thought too, I don't get it.
> I'd love to hear from someone at
On 10 August 2022 17:12:55 BST, Marc MERLIN via Exim-users
wrote:
>> hosts_try_fastopen = !*.l.google.com
>>
>> into /etc/exim4/conf.d/transports/30_exim4-config_remote_smtp (or
>whichever
>> config the remote transport is in depending on how you have installed
>Exim
>> on Debian).
>
>Thank you
On Wed, Aug 10, 2022 at 11:21:31AM +0100, Graeme Coates via Exim-users wrote:
> This does sound something like this issue I blogged about:
> https://www.chromosphere.co.uk/2022/06/01/googles-tcp-fast-open-breaks-exim-
> delivery/
>
> The workround I have (so far!) successfully implemented with the
@exim.org
Subject: [exim] Some Emails to gmail now hang
This started about a week ago, exim 4.94.2 on debian.
I tried disabling chunking ( hosts_try_chunking = ) and it didn't help
Some Emails to gmail get here, some don't. It seems content dependent. It
could be as if gmail is actually te
On 2022-08-09 at 20:20:36 UTC-0400 (Wed, 10 Aug 2022 01:20:36 +0100)
Jeremy Harris via Exim-users
is rumored to have said:
Tricky to guess at. Turn off more features, I guess.
You already tried chunking. Next would be fastopen, then pipelining.
However, given it was right after all the data (
Tricky to guess at. Turn off more features, I guess.
You already tried chunking. Next would be fastopen, then pipelining.
However, given it was right after all the data (even in non-chunking)
one has to wonder if it's a content-check of theirs going wrong.
Does a given failing message get throu
This started about a week ago, exim 4.94.2 on debian.
I tried disabling chunking ( hosts_try_chunking = ) and it didn't help
Some Emails to gmail get here, some don't. It seems content dependent. It could
be as if gmail
is actually teergrubbing me :)
Connecting to gmail-smtp-in.l.google.com [26
30 matches
Mail list logo
