Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

Our SBS 2008 server with Exchange 2007 started rejecting some (most) emails starting about 3 or 4 days ago. The return failure message looks something like this:

The error that the other server returned was: 451 451 4.7.0 Timeout waiting for client input (state 18)

I've rebooted our Sonicwall TZ-210 router and that doesn't make any difference. I think this problem has something to do with MTU (packet size) but I don't understand why the problem just started now. We haven't made any changes to our network infrastructure for weeks.

If I ping our SonicWall (DSL connection, bridge mode) forcing unfragmented packets, I start getting packet dropouts at packet size 1320 or so. Maybe this is completely normal, I'm not sure.

I haven't tried rebooting the DSL modem yet because I'm not on site. That's one of the next things I'll try.

share|improve this question
Help me understand this: When you send email from your Exchange 2007 organization to another email domain, the remote mail server sends back an NDR with the 4.7.0 Timeout waiting for client input (state 18). Is that correctly understood? – Mathias R. Jessen Dec 28 '11 at 21:14
Other people on other networks that try to send an email to our server/domain get a return failure from their own email sending service (in my case gmail) and it returns the message I posted above. I'm not sure if our server generates that error message or if it's generated by the remote client's sending server. – HK1 Dec 29 '11 at 2:16

2 Answers

up vote 0 down vote

If it is a routing issue (that's pretty likely, given the error message), try setting the MTU max size on the public interface of your SBS. You can set the package size limit for each individual tcpip interface in the registry.

Check out this guide from Microsoft, the last suggestion "Method 3" walks you through setting MTU max size: http://support.microsoft.com/kb/314825

share|improve this answer
You were real close but it's not really a "routing" issue and neither is the problem located on our server. – HK1 Dec 29 '11 at 2:13
I never said it was located on the server, I simply offered a suggestion that would circumvent the black hole router issue, through a little server configuration ;-) – Mathias R. Jessen Dec 29 '11 at 2:21
up vote 0 down vote

After reading up more online I did some ping tests using the -f switch and found that this particular DSL connection started dropping packets that were in excess of 1300 bytes. Microsoft refers to this as a "black hole router". Basically, something is wrong with that port.

I implemented a work around for this problem by going into the PPoE connection settings inside the SonicWall TZ-210 and changing the MTU to be somewhere in the 1250 range (I don't remember the exact number). Incoming emails started to flow again immediately as well as any other traffic that uses that particular connection. I'll have to contact SonicWall to see if we can have this problem covered under warranty.

Update1
As it turns out, this was apparently a DSL modem problem, not a SonicWall problem. Changing the MTU setting in the PPoE settings on the router did prove to be a sufficient work-around until the modem gets replaced.

Update2
A new DSL modem did not resolve this issue. Still not sure which device or software is causing this problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.