kernel and multicast udp traffic

zeebu · 05-30-2007, 06:49 PM

hi guys,

i've got two hosts with different hardware specs where i'm trying to run a given app (Vulture). There's nothing i can do about the hardware, but, as a result, we've had to use slightly different builds (builds are specified by our internal unix engineering team, but they're based on 2.4.21-47.0.1.ELsmp).

Vulture is nothing more than a glorified multicast UDP listener. It works fine on host A, but not on host B. My observations follow:

host A: no issues
host B: fails to pick up even a single packet. however, running tcpdump shows exactly the same traffic flowing into this host as soon as i start up Vulture as what host A is picking up. netstat -gn shows that the correct interface is being used to join the multicast group, and /var/log/messages assures me that everything is at 100/FD. So, to my (i guess untrained?) eye, it looks as though the interface is getting the data, but the kernel is somehow stopping Vulture from seeing any of the data. i've removed ip_tables, and can't really think of what else to do (the only IP related software installed is apparently iputils-20020927-11.30.5 and iproute-2.4.7-11.30E.1)

any help would be greatly appreciated

thanks

Z

FMC · 05-31-2007, 01:39 PM

Try to check if the app is realy listening the port, example:

Code:

# fuser -v 53/udp

                     USER        PID ACCESS COMMAND
53/udp:              root      10862 F.... named

You can try strace to debug the app, but its something not so easy to do!

Post the result here after, then I can try to help you more!

[]´s, FMC!

zeebu · 06-01-2007, 12:04 AM

hi, thanks FMC,

as i explained, this app is already working fine on another machine, but, just for the sake of it, here's the fuser output:

/sbin/fuser -v 18891/udp

USER PID ACCESS COMMAND
18891/udp astjplo 17802 f.... Vulture

and here's some of the packets that tcpdump is picking up:

14:03:44.305357 10.6.61.66.18891 > 239.192.3.1.18891: udp 823 [tos 0x68]
14:03:44.305663 10.6.61.66.18891 > 239.192.3.1.18891: udp 477 [tos 0x68]
14:03:44.305682 10.6.61.66.18891 > 239.192.3.1.18891: udp 137 [tos 0x68]

thanks for your help... NB: strace just throws the socket thread waiting for data to come in

any ideas??

FMC · 06-01-2007, 11:24 AM

Quote:

Originally Posted by zeebu

14:03:44.305357 10.6.61.66.18891 > 239.192.3.1.18891: udp 823 [tos 0x68]
14:03:44.305663 10.6.61.66.18891 > 239.192.3.1.18891: udp 477 [tos 0x68]
14:03:44.305682 10.6.61.66.18891 > 239.192.3.1.18891: udp 137 [tos 0x68]

The machine that the app do not work is 10.6.61.66 or 239.192.3.1??

It looks like the udp traffic is outgoing and not incomming, am I right?

You said that the app is a UDP multcast LISTENER, so, there is nothing to listen if the packages are just outgoing! lol

[]´s, FMC!

zeebu · 06-02-2007, 02:27 AM

Quote:

Originally Posted by FMC

The machine that the app do not work is 10.6.61.66 or 239.192.3.1??

It looks like the udp traffic is outgoing and not incomming, am I right?

You said that the app is a UDP multcast LISTENER, so, there is nothing to listen if the packages are just outgoing! lol

[]´s, FMC!

no no no!

i'm not that stupid!

10.6.61.66 is the udp publisher (another machine)
239.192.3.1 is the udp address to which the publisher is sending messages (on port 18891)

my app is a LISTENER running on a host with a completely different IP address

trust me, the problem is with the kernel not passing on the messages to applications (since tcpdump reads the data straight off the interface without going through the kernel)

thanks!

FMC · 06-02-2007, 09:22 AM

Well, this version of the kernel is realy old for me, usualy I have 2.6.x installed on my servers, that can be a problem.

As we have seen, the app is listening the port without problems, so, there is the possibility that the kernel is doing something wrong.

Flush all iptables rules, try another port and everything, but in this case I cant help you a lot!

[]'s, FMC!