On May 15, 2011, at 1:14 AM, Frank Bonnet wrote:
Le 15/05/2011 02:42, jason hirsh a écrit :
On May 14, 2011, at 2:20 PM, Victor Duchovni wrote:
On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote:
I have also tried running the server with the IPFW turned off and
still
have the issue with some gmail and mindspring.com users
I would like to suggest that further posts in this threat are moot,
and should cease, unless and until jason is able to record TCP
sessions
between Gmail (or another "problem" systems) and his server, and
make
at least one such recordings available. Isolate a single session
that
fails along the lines of:
C: TCP SYN (one or more if server response is delayed)
S: TCP SYN ACK or TCP RST or silence
C: TCP ACK
S: SMTP 4XX banner or 5XX or timeout
C: SMTP EHLO
S: 4XX response or 5XX response or timeout
Save a binary packet capture not decoded packets:
# tcpdump -s0 -w /some/file tcp port 25
then decode with "tcpdump -s0 -r /some/file" and find the source
host/port
of the failed connection, isolate that with:
# tcpdump -s0 -r /some/file -w /some/other-file tcp and \
host <addr> and tcp port <port>
then make the final binary file containing just the failed session
available.
this is the record of the exchange.. it does not appear to be what you
expected though
08:40:31.036997 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0
08:40:34.037857 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972298960 ecr 0,nop,wscale 6], length 0
08:40:40.036791 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972304960 ecr 0,nop,wscale 6], length 0
08:40:50.037758 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972314960 ecr 0,nop,wscale 6], length 0
08:41:00.037805 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972324960 ecr 0,nop,wscale 6], length 0
08:41:10.037831 IP mail-iy0-f182.google.com.51101 >
tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720,
options [mss 1430,sackOK,TS val 2972334960 ecr 0,nop,wscale 6], length 0
--
That makes sense
I hall attempt to do that
Viktor.
It seems you are using FreeBSD, could you type the following command
then send back the result ?
sysctl -a | grep tcp
net.inet.tcp.rfc1323: 1
net.inet.tcp.mssdflt: 512
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
net.inet.tcp.keepinit: 75000
net.inet.tcp.delacktime: 100
net.inet.tcp.v6mssdflt: 1024
net.inet.tcp.hostcache.purge: 0
net.inet.tcp.hostcache.prune: 300
net.inet.tcp.hostcache.expire: 3600
net.inet.tcp.hostcache.count: 25
net.inet.tcp.hostcache.bucketlimit: 30
net.inet.tcp.hostcache.hashsize: 512
net.inet.tcp.hostcache.cachelimit: 15360
net.inet.tcp.read_locking: 1
net.inet.tcp.recvbuf_max: 262144
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.recvbuf_auto: 1
net.inet.tcp.insecure_rst: 0
net.inet.tcp.ecn.maxretries: 1
net.inet.tcp.ecn.enable: 0
net.inet.tcp.abc_l_var: 2
net.inet.tcp.rfc3465: 1
net.inet.tcp.rfc3390: 1
net.inet.tcp.rfc3042: 1
net.inet.tcp.drop_synfin: 0
net.inet.tcp.delayed_ack: 1
net.inet.tcp.blackhole: 0
net.inet.tcp.log_in_vain: 0
net.inet.tcp.sendbuf_max: 262144
net.inet.tcp.sendbuf_inc: 8192
net.inet.tcp.sendbuf_auto: 1
net.inet.tcp.tso: 1
net.inet.tcp.newreno: 1
net.inet.tcp.local_slowstart_flightsize: 4
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.reass.overflows: 50
net.inet.tcp.reass.maxqlen: 48
net.inet.tcp.reass.cursegments: 0
net.inet.tcp.reass.maxsegments: 1600
net.inet.tcp.sack.globalholes: 0
net.inet.tcp.sack.globalmaxholes: 65536
net.inet.tcp.sack.maxholes: 128
net.inet.tcp.sack.enable: 1
net.inet.tcp.inflight.stab: 20
net.inet.tcp.inflight.max: 1073725440
net.inet.tcp.inflight.min: 6144
net.inet.tcp.inflight.rttthresh: 10
net.inet.tcp.inflight.debug: 0
net.inet.tcp.inflight.enable: 1
net.inet.tcp.isn_reseed_interval: 0
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.pcbcount: 44
net.inet.tcp.do_tcpdrain: 1
net.inet.tcp.tcbhashsize: 512
net.inet.tcp.log_debug: 0
net.inet.tcp.minmss: 216
net.inet.tcp.syncache.rst_on_sock_fail: 1
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.count: 0
net.inet.tcp.syncache.cachelimit: 15360
net.inet.tcp.syncache.bucketlimit: 30
net.inet.tcp.syncookies_only: 0
net.inet.tcp.syncookies: 1
net.inet.tcp.timer_race: 0
net.inet.tcp.finwait2_timeout: 60000
net.inet.tcp.fast_finwait2_recycle: 0
net.inet.tcp.always_keepalive: 1
net.inet.tcp.rexmit_slop: 200
net.inet.tcp.rexmit_min: 30
net.inet.tcp.msl: 30000
net.inet.tcp.nolocaltimewait: 0
net.inet.tcp.maxtcptw: 5120
net.inet.flowtable.tcp_expire: 86400
Is BPF enabled in the kernel machine ?
aooarently yes
What is the FreeBSD version ( I had troubles with 8.2 )
8.1
In fact the problem seems to be OS related and NOT a Postfix/
sendmail/exim problem.
I will give that a shot
thank you
I would suggest to post your request into freebsd-us...@freebsd.org
mailing list or look at
http://lists.freebsd.org/mailman/listinfo
to find a more fine grained list
