[opensuse] need help deciphering a tcpdump
I've got a problem with an SMTP session between two mailservers (of which one is ours). The initial conversation works fine right up until the RCPT TO. We respond with '250 2.1.5 Ok' after which nothing else happens until we time out. I've captured the whole thing with tcpdump, and I've got a suspicion, but I'd like somebody else to have a look: http://jessen.ch/files/cellere-tcpdump We are the 88-address, the other side is the 195-ditto. If someone would care to take a peek at the above, and explain to me what's going on, I'd much appreciate it. thanks Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
I've captured the whole thing with tcpdump, and I've got a suspicion, but I'd like somebody else to have a look:
I can see 195 sending me a RST, which aborts the TCP session, but can anyone suggest why? thanks Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Nov 21, 2008 at 11:06 AM, Per Jessen
I've got a problem with an SMTP session between two mailservers (of which one is ours). The initial conversation works fine right up until the RCPT TO. We respond with '250 2.1.5 Ok' after which nothing else happens until we time out.
I've captured the whole thing with tcpdump, and I've got a suspicion, but I'd like somebody else to have a look:
http://jessen.ch/files/cellere-tcpdump
We are the 88-address, the other side is the 195-ditto. If someone would care to take a peek at the above, and explain to me what's going on, I'd much appreciate it.
thanks Per
-- /Per Jessen, Zürich
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sorry to be brief (no time to really delve into this right now) but have you tried utilities that run on top of tcpdump, Wireshark being one, that allow you to filter the data and get it in a more readable format. Good luck! Boris. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2008/11/21 Per Jessen
I've got a problem with an SMTP session between two mailservers (of which one is ours). The initial conversation works fine right up until the RCPT TO. We respond with '250 2.1.5 Ok' after which nothing else happens until we time out.
I've captured the whole thing with tcpdump, and I've got a suspicion, but I'd like somebody else to have a look:
http://jessen.ch/files/cellere-tcpdump
We are the 88-address, the other side is the 195-ditto. If someone would care to take a peek at the above, and explain to me what's going on, I'd much appreciate it.
thanks Per
-- /Per Jessen, Zürich
Try with: "tcpdump -v -i <interface> -X -s 0 port 25" or use Wireshark. Regards, Ciro N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�Z+i�b�*'jW(�f�vǦj)h���Ǿ��i����� ��
Ciro Iriarte wrote:
Try with: "tcpdump -v -i <interface> -X -s 0 port 25" or use Wireshark.
Hi Ciro I tried your suggestion: http://jessen.ch/files/cellere-tcpdump2 It doesn't tell me much more - the RST occurs right after I've sent the '250'. -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2008/11/21 Per Jessen
Ciro Iriarte wrote:
Try with: "tcpdump -v -i <interface> -X -s 0 port 25" or use Wireshark.
Hi Ciro
I tried your suggestion:
http://jessen.ch/files/cellere-tcpdump2
It doesn't tell me much more - the RST occurs right after I've sent the '250'.
-- /Per Jessen, Zürich
--
Post tcpdump.dmp generated by "tcpdump -w /tmp/tcpdump.dmp -s 0 -i <interface> port 25", that can be analyzed with wireshark. If there's no response at all, would be nice to take a look at the logs from remote site (assuming it's a friendly site :D)... Regards, Ciro
Ciro Iriarte wrote:
Post tcpdump.dmp generated by "tcpdump -w /tmp/tcpdump.dmp -s 0 -i <interface> port 25", that can be analyzed with wireshark.
I ran this yesterday: tcpdump -n -i eth0 -s 1500 -w file host 195.65.248.162 http://jessen.ch/files/cellere-tcpdump-full-fe1 http://jessen.ch/files/cellere-tcpdump-full-fe2
If there's no response at all, would be nice to take a look at the logs from remote site (assuming it's a friendly site :D)...
Well, for starters I'd like to ascertain that it's not my side creating the problem. I have not yet been able to establish contact to the other side, and chances are it's a Windows site ... -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Nov 22, 2008 at 4:27 PM, Per Jessen
Ciro Iriarte wrote:
Post tcpdump.dmp generated by "tcpdump -w /tmp/tcpdump.dmp -s 0 -i <interface> port 25", that can be analyzed with wireshark.
I ran this yesterday:
tcpdump -n -i eth0 -s 1500 -w file host 195.65.248.162
http://jessen.ch/files/cellere-tcpdump-full-fe1 http://jessen.ch/files/cellere-tcpdump-full-fe2
If there's no response at all, would be nice to take a look at the logs from remote site (assuming it's a friendly site :D)...
Well, for starters I'd like to ascertain that it's not my side creating the problem. I have not yet been able to establish contact to the other side, and chances are it's a Windows site ...
-- /Per Jessen, Zürich
the smtp session is
220 inbound.spamchek.net ESMTP Postfix (louiswu7 via aluminium)
EHLO CV-TM1.cvsg.local
250-inbound.spamchek.net
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:
medwinz wrote:
RCPT TO:
250 2.1.5 Ok
421 4.4.2 inbound.spamchek.net Error: timeout exceeded
So there is a timeout on inbound.spamcheck.net
regards, medwinz
Medwinz, thanks - I'm having a HARD time time refraining from unnecessary sarcasm here .... yes of course there is a timeout on inbound - that's because the other side isn't doing anything! inbound sends the last "250 OK" in response to the "RCPT TO", but the other side has already begun closing the conenction. The key question is - WHY is the other side closing the connection and is it due to something my side is doing? -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Nov 22, 2008 at 6:45 PM, Per Jessen
medwinz wrote:
RCPT TO:
250 2.1.5 Ok
421 4.4.2 inbound.spamchek.net Error: timeout exceeded
So there is a timeout on inbound.spamcheck.net
regards, medwinz
Medwinz, thanks - I'm having a HARD time time refraining from unnecessary sarcasm here .... yes of course there is a timeout on inbound - that's because the other side isn't doing anything!
inbound sends the last "250 OK" in response to the "RCPT TO", but the other side has already begun closing the conenction. The key question is - WHY is the other side closing the connection and is it due to something my side is doing?
-- /Per Jessen, Zürich
Check your mail server log and also if possible ask the other side too regarding the session to make sure (hope they have another mail address that you can send). For example some email server restrict the envelope or do reverse checking and unintentionally reject the good email. regards, medwinz -- Rodney Dangerfield - "I looked up my family tree and found out I was the sap." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
medwinz wrote:
Medwinz, thanks - I'm having a HARD time time refraining from unnecessary sarcasm here .... yes of course there is a timeout on inbound - that's because the other side isn't doing anything!
inbound sends the last "250 OK" in response to the "RCPT TO", but the other side has already begun closing the conenction. The key question is - WHY is the other side closing the connection and is it due to something my side is doing?
-- /Per Jessen, Zürich
Check your mail server log
Medwinz, I know you're trying to be helpful, but do you really think I have not done so already? I have (obviously) checked the log, I'm running full debug on that particular client and I've captured tcpdump for further analysis.
For example some email server restrict the envelope or do reverse checking and unintentionally reject the good email.
In which case I would have a perfectly good SMTP-level error message, and I would have had no reason to start looking at the tcp level data. cheers Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Medwinz, I know you're trying to be helpful, but do you really think I have not done so already? I have (obviously) checked the log, I'm running full debug on that particular client and I've captured tcpdump for further analysis.
For example some email server restrict the envelope or do reverse checking and unintentionally reject the good email.
In which case I would have a perfectly good SMTP-level error message, and I would have had no reason to start looking at the tcp level data.
From what I saw in the dump your server resent the last "200 2.1.5" message sereval times after the rcpt to. It seems as if the protocol went out of sync.
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly. /etc/postfix/main.cf: smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/dumb_down_idiots /etc/postfix/dumb_down_idiots: 195.65.248.162 pipelining, silent-discard If have little hope that you will find a competent admin on the other end if the system uses an internal name for helo. Good luck! -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
From what I saw in the dump your server resent the last "200 2.1.5" message sereval times after the rcpt to. It seems as if the protocol went out of sync.
Yeah, that's I what suspect too.
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly.
Thanks, very interesting suggestion. Will definitely try it.
If have little hope that you will find a competent admin on the other end if the system uses an internal name for helo.
My thinking too, which is why I started lining up my ducks (and why I asked here first). -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly.
Thanks, very interesting suggestion. Will definitely try it.
OK, have had it disabled all weekend, but the first 2-3 SMTP attempts this morning failed in the same way. I hope I'll be able to get hold of the other side today. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly. Thanks, very interesting suggestion. Will definitely try it.
OK, have had it disabled all weekend, but the first 2-3 SMTP attempts this morning failed in the same way. I hope I'll be able to get hold of the other side today.
I guess you'll get to know how much joy a combination of the most expensive software with the most certifications with apes in front of the keyboard is. I share your pain... The most probable reason is a firewall problem. Does this problem also appear if you are the sending side? If you can't solve it with the other side you might try the english postfix mailing list. There are very knowledgeable people on the list, not the least Wietse himself. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
I guess you'll get to know how much joy a combination of the most expensive software with the most certifications with apes in front of the keyboard is. I share your pain...
Well, I got hold of someone and they've know been looking at the problem for about two working days. I'll keep you posted.
The most probable reason is a firewall problem. Does this problem also appear if you are the sending side?
They have two different servers - the outbound is being sent from a different place. Nothing really unusual in that, but ....
If you can't solve it with the other side you might try the english postfix mailing list. There are very knowledgeable people on the list, not the least Wietse himself.
Yeah, that might be the next step. I'll wait till tomorrow before I call up again. -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Sandy Drobic wrote:
I guess you'll get to know how much joy a combination of the most expensive software with the most certifications with apes in front of the keyboard is. I share your pain...
Well, I got hold of someone and they've know been looking at the problem for about two working days. I'll keep you posted.
Update: so far the other side has spent about two weeks before they involved the local product support who in turn passed the issue to the vendor. -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
Sandy Drobic wrote:
I guess you'll get to know how much joy a combination of the most expensive software with the most certifications with apes in front of the keyboard is. I share your pain... Well, I got hold of someone and they've know been looking at the problem for about two working days. I'll keep you posted.
Update: so far the other side has spent about two weeks before they involved the local product support who in turn passed the issue to the vendor.
Okay, now it's getting interesting. (^-^) -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2008/11/22 Sandy Drobic
Per Jessen wrote:
Medwinz, I know you're trying to be helpful, but do you really think I have not done so already? I have (obviously) checked the log, I'm running full debug on that particular client and I've captured tcpdump for further analysis.
For example some email server restrict the envelope or do reverse checking and unintentionally reject the good email.
In which case I would have a perfectly good SMTP-level error message, and I would have had no reason to start looking at the tcp level data.
From what I saw in the dump your server resent the last "200 2.1.5" message sereval times after the rcpt to. It seems as if the protocol went out of sync.
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly.
/etc/postfix/main.cf: smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/dumb_down_idiots
/etc/postfix/dumb_down_idiots: 195.65.248.162 pipelining, silent-discard
If have little hope that you will find a competent admin on the other end if the system uses an internal name for helo.
Good luck!
-- Sandy
Interesting, taking notes :)
But, If using pipelining, shouldn't we see something like this?:
-------Commands in batch--------
23:01:13.421803 IP mail.udena.ch.62821 > mxzhh.bluewin.ch.smtp: P
141:432(291) ack 375 win 65535
participants (5)
-
Boris Epstein -
Ciro Iriarte -
medwinz -
Per Jessen -
Sandy Drobic