[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 <per@opensuse.org> wrote:
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 <per@opensuse.org>:
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 <per@opensuse.org>:
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 <per@opensuse.org> wrote:
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:<Roland.Krebs@richard-schiess.ch> SIZE=5308 250 2.1.0 Ok RCPT TO:<thomas.koellner@walo.ch> 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 -- P. J. O'Rourke - "Never wear anything that panics the cat." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
medwinz wrote:
RCPT TO:<thomas.koellner@walo.ch>
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 <per@opensuse.org> wrote:
medwinz wrote:
RCPT TO:<thomas.koellner@walo.ch>
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 <suse-linux-e@japantest.homelinux.com>:
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 <nop,nop,timestamp 3247067002 1162153702> 0x0000: 4500 0157 b0ad 4000 4006 efe6 3e0c 83b6 E..W.. at . at ...>... 0x0010: c3ba 1390 f565 0019 c006 5b8c 4e5d b7a6 .....e....[.N].. 0x0020: 8018 ffff 9a56 0000 0101 080a c18a 4f7a .....V........Oz 0x0030: 4545 0ee6 5253 4554 0d0a 4d41 494c 2046 EE..RSET..MAIL.F 0x0040: 524f 4d3a 3c77 6572 6b73 7461 7474 4066 ROM:<xxx at f 0x0050: 656d 6e65 742e 6368 3e20 5349 5a45 3d33 emnet.ch>.SIZE=3 0x0060: 3730 340d 0a52 4350 5420 544f 3a3c 636f 704..RCPT.TO:<co 0x0070: 7269 6e6e 6573 6965 6766 7269 6564 4062 xxx at b 0x0080: 6c75 6577 696e 2e63 683e 0d0a 5243 5054 luewin.ch>..RCPT 0x0090: 2054 4f3a 3c62 7269 6769 7474 652e 686f .TO:<xxx.xx 0x00a0: 6573 6c69 4062 6c75 6577 696e 2e63 683e esli at bluewin.ch> 0x00b0: 0d0a 5243 5054 2054 4f3a 3c77 6172 746f ..RCPT.TO:<xxx 0x00c0: 7474 6940 626c 7565 7769 6e2e 6368 3e0d tti at bluewin.ch>. 0x00d0: 0a52 4350 5420 544f 3a3c 6769 7573 796d .RCPT.TO:<xxxxx 0x00e0: 4062 6c75 6577 696e 2e63 683e 0d0a 5243 at bluewin.ch>..RC 0x00f0: 5054 2054 4f3a 3c73 7461 6c64 6572 2e77 PT.TO:<xxxxxxx.x 0x0100: 6f68 6c65 6e40 626c 7565 7769 6e2e 6368 ohlen at bluewin.ch 0x0110: 3e0d 0a52 4350 5420 544f 3a3c 616d 6475 >..RCPT.TO:<xxxx 0x0120: 6572 7240 626c 7565 7769 6e2e 6368 3e0d xxx at bluewin.ch>. 0x0130: 0a52 4350 5420 544f 3a3c 646f 7269 7368 .RCPT.TO:<xxxxxx 0x0140: 6573 7340 626c 7565 7769 6e2e 6368 3e0d ess at bluewin.ch>. 0x0150: 0a44 4154 410d 0a .DATA.. ------------------------- Instead of seeing ---------------- from_remote > Request 1 your_server > Answer 1 from_remote > Request 2 your_server > Answer 2 .... .. --------------- Maybe there's a broken firewall/NAT setup on the other side? Regards, Ciro
participants (5)
-
Boris Epstein -
Ciro Iriarte -
medwinz -
Per Jessen -
Sandy Drobic