SMTP problem with WRT54GL

Question

I've seen similar issues here but haven't seen a solution yet. Whenever I send an email there is a 30 second delay. This is true for all computers on my network, windows or linux and for two different SMTP servers at different locations. Also Thunderbird and Outlook show the same problem, the router seems to be the common element.
I used Wireshark to capture the transaction and found a consistent problem. The TCP/IP connection gets created very quickly (SYN/SYN-ACK/ACK) and then there is a 30 second delay before receiving the first SMTP 220 packet.
My theory is that the first packet returned from the SMTP server is getting blocked by the router, causing it to time out and retry. To test this idea I put one of my systems in the DMZ and the message got sent right away.
Now, here's where it gets a little more interesting. I had expected only the DMZ machine to be helped but *all* of the systems worked correctly with this one machine in the DMZ. I even tried putting an embedded linux based NAS server as the DMZ machine and again the situation improved. I also tried setting the DMZ to an unused IP address in the subnet and that did not make the problem go away, otherwise I might just have left it at that, but I don't want to have any real machines in DMZ.
I am only seeing this problem with SMTP packets, and then it's only the first one that comes back from the server. HTTP, SSH, everything is fine.
BTW, firewall on the router is disabled as well as on the clients. The router is at firmware revision 4.30.5 which is the most recent that I found on the Linksys site.
Any clues, things to try? I can provide any details for network captures if it will help.
Thanks in advance,
Joe Meadows

Answer 1

Well, 30 seconds sounds like something tries to connect to a "stealth" port and retries until it times out. This usually happens, when you have a SMTP, POP or IMAP server running on Unix which still uses the identd service on port 113. With ident the server asks the client about the username which is trying to connect. This service is pretty useless in the internet because it is totally unsecure and thus no server can rely on this anymore, but some libraries still have it built-in.
The problem arises when the client computer or the gateway in front of the client is "stealth"ing ports. If a port is closed (because no service is running on port 113) the computer would immediately reply to that no connection can be established. However, people think it is better when the port is "stealth" meaning: the computer does not answer at all, thinking the computer would be invisible (which it is not because a computer that is not answering is obviously there...)
The standard IP procedure for the server is to wait for the answer until it times out. Then retry 2 or 3 times. Quickly you have 30 seconds until the server gives up on the identd and continues.
However, you say you have the firewall disabled on your router. That would mean that the ident port should be properly reported closed and is not stealth. You could test with a port scan in the internet whether your internet ports are really reported closed or "stealth"ed. It should be closed if the firewall is off. (By the way, firewall off means access to the web-based management from the internet is possible...)
Many routers have the option to filter ident in the security settings. Usually you would turn off that option if you experience this problem. It should be off with the firewall turned off. However, all the symptoms you describe would fit.
If you put a host into DMZ which is not running a firewall and thus does not keep port 113 stealth it obviously helps any client that connects: the ident request is always sent to the DMZ and the DMZ reports the port closed and immediately the connection continues.
I used to forward port 113 on a different router to my network printer because it has a static IP address and it does not have a firewall thus reports 113 closed.
You could try to remove the DMZ and only forward port 113 to that computer.
You could also install a packet sniffer on the DMZ to see what packets arrive when you try to connect with a client to the SMTP server. Then you should see that a ident SYN on port 113 arrives (or something else if it is not ident...)