Milter-greylist

Hello,

I have three MX servers and am trying to get mx sync to work between them. Two of the servers are syncing, but the third is logging the following error in the maillog:

milter-greylist: cannon start MX sync, bind failed: Address already in use.

I just saw the post for 1.5.1 and tried it, but I get the same result.

If I do a netstat -lnp, the port 5252 does not show in use. On all the other servers, it shows the port bound to milter-greylist. There is only on ethernet adapter in the box with a single ip address. One other note, this box is a Redhat 8.0. The two boxes that are working are Fedora 1.

If anyone has some suggestions, I would greatly appreciate it.

Brian Snead

Brian Snead <BSnead@...> wrote:

> I have three MX servers and am trying to get mx sync to work between them.
> Two of the servers are syncing, but the third is logging the following
> error in the maillog:
> 
> milter-greylist: cannon start MX sync, bind failed: Address already in
> use.
> 
> I just saw the post for 1.5.1 and tried it, but I get the same result.

When you say the third fails, it's always the same machine, or it's the
last machine where you start milter-greylist?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

manu@... wrote:

>Brian Snead <BSnead@...> wrote:
>
>  
>
>>I have three MX servers and am trying to get mx sync to work between them.
>>Two of the servers are syncing, but the third is logging the following
>>error in the maillog:
>>
>>milter-greylist: cannon start MX sync, bind failed: Address already in
>>use.
>>
>>I just saw the post for 1.5.1 and tried it, but I get the same result.
>>    
>>
>
>When you say the third fails, it's always the same machine, or it's the
>last machine where you start milter-greylist?
>
>  
>
It is only the Redhat 8.0 system that fails with the cannot start MX 
sync error. All the other systems load fine. What is really strange is 
the error states that the address is already in use. I can't imagine 
what would be causing milter-greylist to think this.

Thanks
Brian.

brian Snead <BSnead@...> wrote:

> It is only the Redhat 8.0 system that fails with the cannot start MX 
> sync error. All the other systems load fine. What is really strange is
> the error states that the address is already in use. I can't imagine 
> what would be causing milter-greylist to think this.

And rebooting the machine changes nothing?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Hello,

> It is only the Redhat 8.0 system that fails with the cannot start MX 
> sync error. All the other systems load fine. What is really strange is 
> the error states that the address is already in use. I can't imagine 
> what would be causing milter-greylist to think this.

I attach a patch that you can apply to the code. This surely not solve your
problem
but may give some hints where the problem might be.
God knows what else can be broken. At least we will be sure that you try to
bind to port 5252.

On the other hand if you are running as non-privileged user the
milter-greylist
please try it out as root.

Bests,
Attila

I am happy to report that the patch allowed me to find the problem and all is well now. However, this brings up two additional things I saw while troubleshooting. I am not an expert at using the /etc/services, xinetd and iptables, but here is what was causing the problem.

When I originally installed the software, I couldn't connect. So I suspected the port was being blocked, so I added the mxglsync  5252/tcp to the services file. I then created a mxglsync file in the xinetd.d directory. This didn't work, so I deleted the file in xinetd.d and messed with the iptables. This allowed me to get mxsync working on the two Fedora boxes. 

On the Redhat 8 box, I had left the entry in the services file. It seems if you put this entry in the file, mxsync tries to use port 33300. The patch identified the port and I realized this behavior from yesterday.

On other observation, whenever I execute "make install" the /var/milter-greylist directory gets chowned to root.smmsp. I can never get milter-greylist to work without re-chowning this to smmsp.smmsp. Am I doing something wrong?

Thank you for your help and this is a great product.

Brian.

-----Original Message-----
From: attila.bruncsak@itu.int [mailto:attila.bruncsak@...]
Sent: Thursday, June 17, 2004 6:20 AM
To: milter-greylist@yahoogroups.com
Subject: RE: [milter-greylist] MX sync bind failed - Address in use


Hello,

> It is only the Redhat 8.0 system that fails with the cannot start MX 
> sync error. All the other systems load fine. What is really strange is 
> the error states that the address is already in use. I can't imagine 
> what would be causing milter-greylist to think this.

I attach a patch that you can apply to the code. This surely not solve your
problem
but may give some hints where the problem might be.
God knows what else can be broken. At least we will be sure that you try to
bind to port 5252.

On the other hand if you are running as non-privileged user the
milter-greylist
please try it out as root.

Bests,
Attila





 
Yahoo! Groups Links

On Thu, Jun 17, 2004 at 08:38:05AM -0400, Brian Snead wrote:
> When I originally installed the software, I couldn't connect. So I suspected the port was being blocked, so I added the mxglsync  5252/tcp to the services file. I then created a mxglsync file in the xinetd.d directory. This didn't work, so I deleted the file in xinetd.d and messed with the iptables. This allowed me to get mxsync working on the two Fedora boxes. 

xinetd has nothing to do here. You should just need it in /etc/services

> On the Redhat 8 box, I had left the entry in the services file. It seems if you put this entry in the file, mxsync tries to use port 33300. The patch identified the port and I realized this behavior from yesterday.

Is it really 33000? Not 33812? (33812 is 5252 in reverse-endian display)

> On other observation, whenever I execute "make install" the /var/milter-greylist directory gets chowned to root.smmsp. I can never get milter-greylist to work without re-chowning this to smmsp.smmsp. Am I doing something wrong?

Here is the revelant line in Makefile.in
${INSTALL} -d -m 755 -o ${USER} /var/milter-greylist

What -o means on your system?

-- 
Emmanuel Dreyfus
manu@...

Emmanuel,

I think you are right about me stating the port wrong. However, I have never been able to get the mxsync to work if I have the following entry in my /etc/services.

mxglsync		5252/tcp			# mxsync port

When I perform a packet capture, the mxsync doesn't talk on port 5252. I actually tries to talk on the 33812 port. Is this correct? Because the 33812 port is not open in iptables. I opened 5252.

Like I said, I am new with the iptables, etc., but the packet capture seems correct.

Here is an attached ethereal dump file. First is the attempt with the services entry, second without. The second is successful. Any ideas?

-----Original Message-----
From: Emmanuel Dreyfus [mailto:manu@...]
Sent: Thursday, June 17, 2004 9:03 AM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] MX sync bind failed - Address in use


On Thu, Jun 17, 2004 at 08:38:05AM -0400, Brian Snead wrote:
> When I originally installed the software, I couldn't connect. So I suspected the port was being blocked, so I added the mxglsync  5252/tcp to the services file. I then created a mxglsync file in the xinetd.d directory. This didn't work, so I deleted the file in xinetd.d and messed with the iptables. This allowed me to get mxsync working on the two Fedora boxes. 

xinetd has nothing to do here. You should just need it in /etc/services

> On the Redhat 8 box, I had left the entry in the services file. It seems if you put this entry in the file, mxsync tries to use port 33300. The patch identified the port and I realized this behavior from yesterday.

Is it really 33000? Not 33812? (33812 is 5252 in reverse-endian display)

> On other observation, whenever I execute "make install" the /var/milter-greylist directory gets chowned to root.smmsp. I can never get milter-greylist to work without re-chowning this to smmsp.smmsp. Am I doing something wrong?

Here is the revelant line in Makefile.in
${INSTALL} -d -m 755 -o ${USER} /var/milter-greylist

What -o means on your system?

-- 
Emmanuel Dreyfus
manu@...



 
Yahoo! Groups Links

Brian Snead <BSnead@...> wrote:

> When I perform a packet capture, the mxsync doesn't talk on port 5252. I
> actually tries to talk on the 33812 port. Is this correct? Because the
> 33812 port is not open in iptables. I opened 5252.

It's a little endian problem:
5252 = 0x1484
33812 = 0x8414

Can you try the following test program?

#include <stdio.h>
#include <sys/types.h>
 
int
main(argc, argv)  
        int argc;
        char **argv;
{
        printf("htons(0x1234) = 0x%x\n", htons(0x1234));
        
        return 0;
}

On a little endian machine (such as i386), you should get 0x3412. If you
get 0x1234, then something is buggy on your system.

It's on an i386, right?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

I ran the program and got 0x3412.

Brian.

-----Original Message-----
From: manu@... [mailto:manu@...]
Sent: Thursday, June 17, 2004 4:10 PM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] MX sync bind failed - Address in use


Brian Snead <BSnead@...> wrote:

> When I perform a packet capture, the mxsync doesn't talk on port 5252. I
> actually tries to talk on the 33812 port. Is this correct? Because the
> 33812 port is not open in iptables. I opened 5252.

It's a little endian problem:
5252 = 0x1484
33812 = 0x8414

Can you try the following test program?

#include <stdio.h>
#include <sys/types.h>
 
int
main(argc, argv)  
        int argc;
        char **argv;
{
        printf("htons(0x1234) = 0x%x\n", htons(0x1234));
        
        return 0;
}

On a little endian machine (such as i386), you should get 0x3412. If you
get 0x1234, then something is buggy on your system.

It's on an i386, right?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...



 
Yahoo! Groups Links

"Brian Snead" <BSnead@...> writes:

> I ran the program and got 0x3412.

I believe the bug is in sync.c where the service number returned by
getservbyname() is assigned using htons() which reverts the byte order.

Cyril Guibourg <cg+milter-greylist@...> wrote:

> I believe the bug is in sync.c where the service number returned by
> getservbyname() is assigned using htons() which reverts the byte order.

Yes, you are right. From the man page:
s_port     The port number at which the service resides.  Port numbers
           must be given and are returned in network byte order.

I did not noticed that bug since both my MX are big endian machines.

Here is a patch that should fix it:

Index: sync.c
===================================================================
RCS file: /cvsroot/milter-greylist/sync.c,v
retrieving revision 1.45
diff -r1.45 sync.c
299c299
<               service = MXGLSYNC_PORT;
---
>               service = htons(MXGLSYNC_PORT);
324c324
<       raddr.sin_port = htons(service);
---
>       raddr.sin_port = service;
442c442
<               service = MXGLSYNC_PORT;
---
>               service = htons(MXGLSYNC_PORT);
465c465
<       laddr.sin_port = htons(service);
---
>       laddr.sin_port = service;

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

I am having trouble applying this patch to my sync.c file. I didn't have 
any trouble with the previous diff file you sent. Is there a different 
way this one needs to be applied? I could manually apply the changes, 
but I figured I should learn something new about Diffs.

Thanks for you patience.

Brian

manu@... wrote:

>Cyril Guibourg <cg+milter-greylist@...> wrote:
>
>  
>
>>I believe the bug is in sync.c where the service number returned by
>>getservbyname() is assigned using htons() which reverts the byte order.
>>    
>>
>
>Yes, you are right. From the man page:
>s_port     The port number at which the service resides.  Port numbers
>           must be given and are returned in network byte order.
>
>I did not noticed that bug since both my MX are big endian machines.
>
>Here is a patch that should fix it:
>
>Index: sync.c
>===================================================================
>RCS file: /cvsroot/milter-greylist/sync.c,v
>retrieving revision 1.45
>diff -r1.45 sync.c
>299c299
><               service = MXGLSYNC_PORT;
>---
>  
>
>>              service = htons(MXGLSYNC_PORT);
>>    
>>
>324c324
><       raddr.sin_port = htons(service);
>---
>  
>
>>      raddr.sin_port = service;
>>    
>>
>442c442
><               service = MXGLSYNC_PORT;
>---
>  
>
>>              service = htons(MXGLSYNC_PORT);
>>    
>>
>465c465
><       laddr.sin_port = htons(service);
>---
>  
>
>>      laddr.sin_port = service;
>>    
>>
>
>  
>

brian Snead <BSnead@...> wrote:

> I am having trouble applying this patch to my sync.c file. I didn't have
> any trouble with the previous diff file you sent. Is there a different
> way this one needs to be applied? I could manually apply the changes,
> but I figured I should learn something new about Diffs.

It seems the tabs turned into space when I copy/pasted. I should have
made an attachement.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Here is the diff as an attachment for anyone else experiencing the problem with adding the 5252 mxglsync service to the services file.

The fix is working flawlessly.

Thank you Emmanuel.

Brian.

-----Original Message-----
From: manu@... [mailto:manu@...]
Sent: Friday, June 18, 2004 2:11 AM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] MX sync bind failed - Address in use


brian Snead <BSnead@infosysnetworks.com> wrote:

> I am having trouble applying this patch to my sync.c file. I didn't have
> any trouble with the previous diff file you sent. Is there a different
> way this one needs to be applied? I could manually apply the changes,
> but I figured I should learn something new about Diffs.

It seems the tabs turned into space when I copy/pasted. I should have
made an attachement.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org



 
Yahoo! Groups Links