New router blocking incoming mail
Hi Guys
I have a client who have had a BT router installed which is now getting replaced with a Netgear N150. There were no specific ports open or any configuration other than the username and password for the ISP configured, same with the new netgear router.
They are using macs with the email program, entourage and the problem is that emails are no longer coming in but can send emails. I have configured the ports on the new router to see if that is the issue and still have the same problem.
Their email is hosted externally so they are just collecting from their servers, not a local server.
You can see the amount of messages they are to come in and sizes etc but its just not downloading the emails.
The error message that comes up is:
"An operation on the server timed out. The server maybe down, overloaded or there may be too much net traffic.
Could not retrieve mail.
Error - 3259"
Whenever you switch back the BT router, it all works perfectly fine.
Thanks in advance.
I have a client who have had a BT router installed which is now getting replaced with a Netgear N150. There were no specific ports open or any configuration other than the username and password for the ISP configured, same with the new netgear router.
They are using macs with the email program, entourage and the problem is that emails are no longer coming in but can send emails. I have configured the ports on the new router to see if that is the issue and still have the same problem.
Their email is hosted externally so they are just collecting from their servers, not a local server.
You can see the amount of messages they are to come in and sizes etc but its just not downloading the emails.
The error message that comes up is:
"An operation on the server timed out. The server maybe down, overloaded or there may be too much net traffic.
Could not retrieve mail.
Error - 3259"
Whenever you switch back the BT router, it all works perfectly fine.
Thanks in advance.
ASKER
We have tried a similar thing with tracing the packets and both looked identical, can't see any fault occuring on the new router when the test is performed.
Any other suggestions on what I can try?
Any other suggestions on what I can try?
Hmmm...it <b>has</b> to be different somehow.
Did you specify a capture filter when you tested? If for example you captured only packets to/from the email provider, you would have missed things such as DNS lookups. I suggest capturing all packets to/from the client during your short test, then comparing the content of the packets, not just the presence. Maybe some DNS lookup is getting a different result, maybe email retrieval performs some check, ...at this point I'd just be speculating.
--klodefactor
Did you specify a capture filter when you tested? If for example you captured only packets to/from the email provider, you would have missed things such as DNS lookups. I suggest capturing all packets to/from the client during your short test, then comparing the content of the packets, not just the presence. Maybe some DNS lookup is getting a different result, maybe email retrieval performs some check, ...at this point I'd just be speculating.
--klodefactor
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
MTU settings are different from mac and changed this from default to 1500 and emails working fine now
Is it possible that the BT router was acting as the DNS server for the LAN?
Otherwise, are you familiar with Wireshark? It's a network packet sniffer that can be really useful for troubleshooting this type of problem.
Just install it on one of the client PCs, and get a packet capture from a working session (through the BT router), then a second capture from a broken session (through the Netgear router). To simplify analysis, you should have as little network activity as possible on the client. That way your packet captures will be small and you won't have to wade through a bunch of extraneous packets.
I'd start with the capture from the working session, and see what outbound connections the client PC is making successfully.
Then review the capture from the broken session and see what's missing. You may see repeated attempts to make some TCP connection (SYN flag set) without a response (SYN+ACK) from the other side.
BTW a powerful tool is the ability to extract both sides of the conversation from a TCP connection. Just right-click on a relevant TCP packet and choose "Follow TCP Stream".
A very brief introduction is at http://wheelersoftware.com/articles/wireshark-tutorial.html. Otherwise the Wireshark site itself has lots of useful information.
Let me know if you need more information, or this approach isn't suitable for you.
--klodefactor