fetchmail-users

[fetchmail-users] query state=2 (SOCKET)

[Roberto M. <rob...@gm...>]

Hi,

I translated the error message in the subject of this mail from
spanish, I don't know if it shows exactly like this in other systems.

I'm running processes for each user from crontabs. I get error
messages, not always, not always from the same user's cron job. I'm
running Debian Sarge with fetchmail: 6.2.5.

I'm stuck. I've tried IMAP and POP3 and didn't find much difference.
Fetchmail is connecting to Courier-IMAP or/and Courier-POP.

Each user has a .fetchmailrc which looks like this:
poll mail.mydomain.com
        protocol POP3
        user "us...@my..."
        pass "pass"
        smtpaddress "mydomain.com"

Each user's cron job (8 at this time) is set to:
*/5 * * * *     fetchmail -vvv 1>> fe.log 2>&1

where fe.log is a log file at user's home directory.

Here the error I found at many fe.log:

fetchmail: 6.2.5 interrogando a mail.mydomain.com (protocolo POP3) en lun 11 s
 iniciada
fetchmail: error `socket' recibiendo de mail.mydomain.com
fetchmail: 6.2.5 interrogando mail.mydomain.com (protocolo POP3) en lun 11 sep
erminada
fetchmail: Estado de la consulta=2 (SOCKET)
fetchmail: terminación normal, estado 2


As a plus, people at this organization is downloading mail using
something calles "mail diamond" for Winbug without problem :-(

I'll appreciate any help. TIA,

-- 
Roberto

Re: [fetchmail-users] query state=2 (SOCKET)

[Rob M. <rob...@gm...>]

On 9/11/06, Roberto Meyer <rob...@gm...> wrote:
> Hi,
>
> I translated the error message in the subject of this mail from
> spanish, I don't know if it shows exactly like this in other systems.
>
> I'm running processes for each user from crontabs. I get error
> messages, not always, not always from the same user's cron job. I'm
> running Debian Sarge with fetchmail: 6.2.5.

Please update to 6.3 (though it probably won't help this particular case).

> I'm stuck. I've tried IMAP and POP3 and didn't find much difference.
> Fetchmail is connecting to Courier-IMAP or/and Courier-POP.

The error relates to fetchmail being unable to communicate with the
remote server.  This is almost always a network issue.

> fetchmail: 6.2.5 interrogando a mail.mydomain.com (protocolo POP3) en lun 11 s
>  iniciada
> fetchmail: error `socket' recibiendo de mail.mydomain.com
> fetchmail: 6.2.5 interrogando mail.mydomain.com (protocolo POP3) en lun 11 sep
> erminada
> fetchmail: Estado de la consulta=2 (SOCKET)
> fetchmail: terminación normal, estado 2
<---SNIP--->
> I'll appreciate any help. TIA,

One test you can try is to see if "telnet mail.mydomain.com 110" works
consistently.  You may find that you've got a number of remote
mailservers and one of them is causing this problem.

Without real domain names for the ISP it's hard to say more.

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] query state=2 (SOCKET)

[Roberto M. <rob...@gm...>]

2006/9/12, Rob MacGregor <rob...@gm...>:

> On 9/11/06, Roberto Meyer <rob...@gm...> wrote:
> > Hi,
> >
> > I translated the error message in the subject of this mail from
> > spanish, I don't know if it shows exactly like this in other systems.
> The error relates to fetchmail being unable to communicate with the
> remote server.  This is almost always a network issue.

[snip]

Still having problems with it, I decided to put tcpdump in action. The
problem is I don't really know much about it. I read the man pages and
understood a little about flags, etc. but don't know a lot of tcp/ip.

I've attached the output of two connections triggered at the same time
for two different users through cron jobs. One of them was successful,
the other one failed with a socket, status=2 result.

The command I issued was:
"tcpdump -v -s1500 -i eth0 -n tcp port 110 -w /tmp/tcpdump.raw"

I've attached the 'text' version of it which I rescued through
"tcpdump -r /tmp/tcpdump.raw"

I know this is a bit off-topic but as this thread started with
fetchmail maybe someone knows help:

TIA,

PD: the mail server is only one and always the same, at least it
resolves always to a single IP.

-- 
Roberto

Re: [fetchmail-users] query state=2 (SOCKET)

[Rob M. <rob...@gm...>]

On 9/12/06, Roberto Meyer <rob...@gm...> wrote:
>
> Still having problems with it, I decided to put tcpdump in action. The
> problem is I don't really know much about it. I read the man pages and
> understood a little about flags, etc. but don't know a lot of tcp/ip.
>
> I've attached the output of two connections triggered at the same time
> for two different users through cron jobs. One of them was successful,
> the other one failed with a socket, status=2 result.
>
> The command I issued was:
> "tcpdump -v -s1500 -i eth0 -n tcp port 110 -w /tmp/tcpdump.raw"
>
> I've attached the 'text' version of it which I rescued through
> "tcpdump -r /tmp/tcpdump.raw"

Separating the 2 is, sadly, not possible.  If you could capture one
working run and one failed run then I *may* be able to help work out
what's going wrong.  It would help to have the binary pcap of the
failed run, though obviously you'd need to change passwords
immediately afterwards (or before and after) for security reasons.

I still think you'll get some information from a simple telnet.  That
at least will confirm that it's not fetchmail that's at fault.  Worth
noting that things like ECN can cause problems with remote mail
servers.

Can you provide the output of "ifconfig eth0" (feel free to mangle MAC
and IP addresses) and "cat /proc/sys/net/ipv4/tcp_ecn"?

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] query state=2 (SOCKET)

[Roberto M. <rob...@gm...>]

2006/9/13, Rob MacGregor <rob...@gm...>:

> On 9/12/06, Roberto Meyer <rob...@gm...> wrote:
> >
> > Still having problems with it, I decided to put tcpdump in action. The
> > problem is I don't really know much about it. I read the man pages and
> > understood a little about flags, etc. but don't know a lot of tcp/ip.
> >
> > I've attached the output of two connections triggered at the same time
> > for two different users through cron jobs. One of them was successful,
> > the other one failed with a socket, status=2 result.
> >
> > The command I issued was:
> > "tcpdump -v -s1500 -i eth0 -n tcp port 110 -w /tmp/tcpdump.raw"
> >
> > I've attached the 'text' version of it which I rescued through
> > "tcpdump -r /tmp/tcpdump.raw"
>
> Separating the 2 is, sadly, not possible.  If you could capture one
> working run and one failed run then I *may* be able to help work out
> what's going wrong.  It would help to have the binary pcap of the
> failed run, though obviously you'd need to change passwords
> immediately afterwards (or before and after) for security reasons.

Finally I got a couple of errors with single connections.

I've attached a .tgz file with the logs of fetchmail and tcpdump at
the moment of the errors, and both logs for a well done connection
too.


> Can you provide the output of "ifconfig eth0" (feel free to mangle MAC
> and IP addresses) and "cat /proc/sys/net/ipv4/tcp_ecn"?

"cat /proc/sys/net/ipv4/tcp_ecn" returns "0" (zero)

"ifconfig eth0" returns:

eth0    Link encap:Ethernet  HWaddr 11:50:24:64:09:BE
          inet addr:201.65.9.43  Bcast:201.65.9.255  Mask:255.255.255.224
                                                   ^^^^^^^^^^^^^^^^
I noticed here broadcast address is wrong... could this be hurting
packets or fetchmail connections? It should be 201.65.9.63 because of
the netmask...

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1240552 errors:34 dropped:0 overruns:0 frame:34
          TX packets:636714 errors:0 dropped:0 overruns:0 carrier:105
          collisions:0 txqueuelen:1000
          RX bytes:397976183 (379.5 MiB)  TX bytes:78105812 (74.4 MiB)
          Interrupt:14 Base address:0xdc00

Carrier error were due to a cable unplug a week ago.

As far as I checked, frame errors don't seem to be directly related to
fetchmail problems.

I'll change broadcast setup, though I didn't write it in
/etc/init.d/interfaces, I only specified address, network and
gateway... I'm surprised Linux didn't calculate it well...

Thanx a lot for your help.

-- 
Roberto

Re: [fetchmail-users] query state=2 (SOCKET)

[Rob M. <rob...@gm...>]

On 9/13/06, Roberto Meyer <rob...@gm...> wrote:
>
> Finally I got a couple of errors with single connections.
>
> I've attached a .tgz file with the logs of fetchmail and tcpdump at
> the moment of the errors, and both logs for a well done connection
> too.

A quick scan of the logs show what I'd expect for a networking
problem.  I'll have a look at the text outputs from tcpdump later,
though a quick scan doesn't show anything obvious right now.

> "cat /proc/sys/net/ipv4/tcp_ecn" returns "0" (zero)

Ok, so ECN isn't on so can't be the source of the problem (which is a
confirmation of what I already suspected).

> "ifconfig eth0" returns:
>
> eth0    Link encap:Ethernet  HWaddr 11:50:24:64:09:BE
>           inet addr:201.65.9.43  Bcast:201.65.9.255  Mask:255.255.255.224
>                                                    ^^^^^^^^^^^^^^^^
> I noticed here broadcast address is wrong... could this be hurting
> packets or fetchmail connections? It should be 201.65.9.63 because of
> the netmask...

Well, that won't matter to fetchmail.  It'll only matter when
something does a broadcast (like DHCP).

> Thanx a lot for your help.

So far, everything seems to point to intermittent network problems
somewhere in the path from your host to the remote POP server.  It
could be that the other software doesn't report these errors, or it
could be that something about the network topology means they take a
different route...

Once I've had the time to take a better look at the tcpdump output
I'll get back to you.

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] query state=2 (SOCKET)

[Roberto M. <rob...@gm...>]

2006/9/14, Rob MacGregor <rob...@gm...>:
> On 9/13/06, Roberto Meyer <rob...@gm...> wrote:
> >
> > Finally I got a couple of errors with single connections.
> >
> > I've attached a .tgz file with the logs of fetchmail and tcpdump at
> > the moment of the errors, and both logs for a well done connection
> > too.
>
> A quick scan of the logs show what I'd expect for a networking
> problem.  I'll have a look at the text outputs from tcpdump later,
> though a quick scan doesn't show anything obvious right now.

[snip]

Yep, I think it's somewhat prooved. I tested this options:

1- server 1 -> ISP 1 -> actual hosting = socket error
2- server 1 -> ISP 1 -> another server = socket error
3- server 2 -> ISP 2 -> actual hosting = ok!!!

Both server 1 and 2 have the same fetchmail setup. It's an ISP problem!

As you said (and I read over the Internet) people who had this problem
solved it when they changed their ISP. ie: problems from work, when
they went home and fetched mail they had no problem at all.

There's almost 24hs I'm testing every 5' without trouble :-)

HTH someone else.

Thanx a lot for your help.

-
Roberto

Re: [fetchmail-users] query state=2 (SOCKET)

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

"Roberto Meyer" <rob...@gm...> writes:

> 2006/9/13, Rob MacGregor <rob...@gm...>:
>
>> On 9/12/06, Roberto Meyer <rob...@gm...> wrote:
>> >
>> > Still having problems with it, I decided to put tcpdump in action. The
>> > problem is I don't really know much about it. I read the man pages and
>> > understood a little about flags, etc. but don't know a lot of tcp/ip.
>> >
>> > I've attached the output of two connections triggered at the same time
>> > for two different users through cron jobs. One of them was successful,
>> > the other one failed with a socket, status=2 result.
>> >
>> > The command I issued was:
>> > "tcpdump -v -s1500 -i eth0 -n tcp port 110 -w /tmp/tcpdump.raw"
>> >
>> > I've attached the 'text' version of it which I rescued through
>> > "tcpdump -r /tmp/tcpdump.raw"
>>
>> Separating the 2 is, sadly, not possible.  If you could capture one
>> working run and one failed run then I *may* be able to help work out
>> what's going wrong.  It would help to have the binary pcap of the
>> failed run, though obviously you'd need to change passwords
>> immediately afterwards (or before and after) for security reasons.
>
> Finally I got a couple of errors with single connections.

Please update fetchmail (newer versions have fewer bugs and better error
reporting) and if the problem persists, run:

env LC_ALL=C fetchmail -vvv --nodetach --nosyslog -d0

to obtain a more detailed log. However, it still looks like the problem
is outside fetchmail to me.

-- 
Matthias Andree

Re: [fetchmail-users] query state=2 (SOCKET)

[Roberto M. <rob...@gm...>]

2006/9/14, Matthias Andree <mat...@gm...>:

[snip]

> > Finally I got a couple of errors with single connections.
>
> Please update fetchmail (newer versions have fewer bugs and better error
> reporting) and if the problem persists, run:
>
> env LC_ALL=C fetchmail -vvv --nodetach --nosyslog -d0
>
> to obtain a more detailed log. However, it still looks like the problem
> is outside fetchmail to me.

Beacause it's a random error I agree with that.

I thought about fetching e-mails from a different place, over a
different ISP to figure out if the problem could be related to the ISP
or the hosting service instead.

Today I did an 'mtr' of 600 pings. Below you'll find the results
which, BTW, I think are reasonable.

HOST: myfetchmachine    Loss%   Snt   Last  Avg  Best  Wrst StDev
1. host.200.55.19.330        0.0%   600   25.4  40.0  21.3 307.8  32.1
2. 201.10.19.45                  0.0%   600   21.4  46.8  20.6 841.2  62.2
3. 201.10.19.41                  0.0%   600   36.3  49.4  21.3 876.4  65.9
4. 201.15.63.207                0.0%   600   56.5  77.6  38.9 806.1  74.6
5. mng-ats.impsat.net.ar   0.0%   600   41.6  68.7  38.7 659.6  71.5
6. remotemailserver.com   8.8%   600   46.3  72.8  42.8 669.9  64.5

I'm really tired about it... I think I'll put my effort in testing the
ISP and hosting service... fetchmail has a rock solid reputation and I
think it's not fair for it to be the first suspect of this mistery ;-)

Thanks a lot for your kind answers.

-- 
Roberto

Re: [fetchmail-users] query state=2 (SOCKET)

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

"Roberto Meyer" <rob...@gm...> writes:

> I'm really tired about it... I think I'll put my effort in testing the
> ISP and hosting service... fetchmail has a rock solid reputation and I
> think it's not fair for it to be the first suspect of this mistery ;-)

Well, you aren't the first, Wikipedia used to link several critics of
fetchmail, and some of them have, although exaggerated, a reasonable
amount of truth in them -- some of the shortcomings have been resolved
since those articles appeared though, or are at least on the plan --
I do not agree with some of the decisions ESR made, but I cannot change
everything over night. One reason is the lack of time, another that
fetchmail is stable code that cannot change radically with patchlevel
releases... and the 6.4 round hasn't really opened yet.

There IS 6.4 stuff on the trunk but I think I'll ditch that and copy 6.3
later, probably a while after 6.3.5 if no new problems crop up with
6.3.5 (which is also a few more weeks out probably) since redoing the
few 6.3.0 -> 6.4 changes will probably be easier than porting 6.3.5 back
onto the trunk... Subversion isn't too good at picking cherries.

-- 
Matthias Andree