Re: [fetchmail-users] Fetchmail socket error.

[Matthias A. <mat...@gm...>]

Ernst Verhaar <e.v...@vi...> writes:

> fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {375012}
> (375012 body octets)
> ******************.***************.*********************.**********
> **********.***************.***************fetchmail: socket error while
> fetching from vid_dbmanta@212.204.236.251
> fetchmail: 6.3.2 querying 212.204.236.251 (protocol IMAP) at Fri Mar 24
> 16:30:12 2006: poll completed
> fetchmail: Query status=2 (SOCKET)
>
> According to the FAQ, I should set the MTU to 552. This doesn't help.
> I tried fetchmail versions 6.2.5.2 (included in Suse 10) and fetchmail
> 6.3.2 (builded on Suse 10) On the same machine. I also tried fetching
> the same emailbox on a different machine Fedora Core 4 (fetchmail
> 6.2.5.5). And on a Fedora Core 4 machine at a different
> Internetprovider. I get the same error everytime...
>
> Fetchmail 6.2.5 on an very old Slackware distro runs
> perfectly. (different machine, same and different internet provider).

This appears to happen a few kBytes into a larger transfer.

Are you (on the client end) using routers, Linux-based firewalls, other
firewalls along the way? Does the server use such? Or FreeBSD ipfw,
ipfw2, ipfilter?  

Are those devices or filters letting ICMP traffic through between server
and client? What physical network is between server and client?
Modem/PPP, DSL, ...?

Is fetchmail -vvv any more helpful? Perhaps attaching strace?

> The host with is being contacted is a FreeBSD running both dovecot and
>imap-uv (different port).

Which FreeBSD version is the server running?

> Could this be a fetchmail error? Or is it a combination between a
> specific Distribution and a specific fetchmail version?

Theoretically possible, but both unlikely. Socket errors are reported to
fetchmail by the network stack built into your kernel (or kernel
module), and 6.3.2 has been around for a while, if there'd been
systematic incompatibilites, we'd pretty surely see more reports.

Are wireless networks (WLAN, IEEE 802.11*) involved?

On any Linux machine that has troubles, if it runs netfilter (firewalls,
SUSEfirewall for instance), run:
/sbin/sysctl net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1
to work around Linux kernel bugs.

Perhaps running [t]ethereal or tcpdump on either side sheds some light
about the nature of the socket error, if it starves, if it's reset (TCP
RST), shut down (FIN), if it's killed (some ICMP) or what else.

-- 
Matthias Andree