[Twisted-Python] sniffing multicast traffic
Hello - I wonder if someone can help: We have some status info being sent by various machines using multicast addressed udp packets. I have been attempting to use twisted to write a python script that will passively monitor on the relevant port for any udp packets with the specified multicast address, which I can then parse the payloads of as required. I have been looking at the examples here: http://code.activestate.com/recipes/425975-simple-udp-multicast-client-serve... But I seem to have trouble getting them to receive anything at all. I have managed to use tshark to display the packets : tshark -i eth0 -x -l -f udp so I know the data is there (coming isn on address 224.0.0.4, port 901) Any suggestions? B
Hi Ben, my experience (not with Twisted, but with multicast), is that multicast often fail to be properly routed (this may be a restriction on OS, switch, etc). That you see the multicasts on using tshark is no indication on the routing working properly, as it will catch all information in promiscous mode, whether routed there or not. Two possible solutions (that may or may not be easy to in conjunction with Twisted) are: * Route the multicasts explicitly * Make the listening socket bind explicitly to the network interface where you expect/see the multicast. This is the solution I have used myself, but may require using low level socket functionality. Binding to localhost (all interfaces at once) or similar did not work for me. Best regards, Lars Ivar On Wed, Mar 10, 2010 at 11:35 AM, Ben Barker <ben@bbarker.co.uk> wrote:
Thanks Lars - yes, I am not adamant about using twisted, although it seemed initially to be the best place to stary. I have also been looking at the pcapy module, which I think may do what I want, but also seems very low level. On Wed, Mar 10, 2010 at 10:48 AM, Lars Ivar Igesund <larsivi@gmail.com> wrote:
On 10/03/10 10:35, Ben Barker wrote:
That's a little vague. Does "trouble" mean "it sometimes works" or "never works"?
FYI, the 224.0.0.0/24 group is usually not IGMP snooped, and is effectively therefore broadcast. Conversely, groups outside this range require working IGMP querying / snooping and some help from (usually) a router, so this may be why you chose this range. Broadly speaking, as long as the UDP socket is listening on the right port and you've called joingroup, you should be ok. Can you post a complete example that isn't working for you? When your code is running, have a look "/sbin/ip maddr" to ensure the group has been added to the socket listen filter.
Sorry - yes, it was very vague! Never works. If I run wiresahrk I can see udp packets addressed to 224.0.0.4, port 901, flying past, however when I run my python script it does not appear to ever receive anything. The scritp I am running is almost identical to an exampel I found here: http://code.activestate.com/recipes/425975-simple-udp-multicast-client- server-using-twisted/
That's interesting.... eth1 is the wrong interface! In fact, it isn't connected to anything at all. eth0 is the interface that should be being used. I will try to swap them around, but presumably this is something I can specify somwhere... As I said, the code I am using is taken from the above link, but the exact listing is given below: from twisted.internet.protocol import DatagramProtocol from twisted.internet import reactor from twisted.application.internet import MulticastServer class MulticastServerUDP(DatagramProtocol): def startProtocol(self): print 'Started Listening' # Join a specific multicast group, which is the IP we will respond to self.transport.joinGroup('224.0.0.4') def datagramReceived(self, datagram, address): print "Server Received:" + repr(datagram) reactor.listenMulticast(901, MulticastServerUDP()) reactor.run()
Well that's odd... I changed the interfaces over - used eth1 for the connection to the network I need to sniff... and now /sbin/ip maddr tells me I have joined 224.0.0.4 on eth0 ! Whichever interface is live, the join seems to happen on the other :-p What could there be about my network config that is making this happen :-p On Wed, Mar 10, 2010 at 1:03 PM, Ben Barker <ben@bbarker.co.uk> wrote:
Ah - I have now sorted the interface problem. I run the code I listed earlier, but it sites at the command line saying "listening" without every dumping anything to screen. /sbin/ip maddr now shows: eth1 link 01:00:5e:00:00:04 link 33:33:ff:7a:7e:4e link 01:00:5e:00:00:fb link 01:00:5e:00:00:01 link 33:33:00:00:00:01 inet 224.0.0.4 inet 224.0.0.251 inet 224.0.0.1 inet6 ff02::1:ff7a:7e4e inet6 ff02::1 And this is the same intterface on which I would expect to see the multicast udp packets. On Wed, Mar 10, 2010 at 1:28 PM, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
Hi Ben, my experience (not with Twisted, but with multicast), is that multicast often fail to be properly routed (this may be a restriction on OS, switch, etc). That you see the multicasts on using tshark is no indication on the routing working properly, as it will catch all information in promiscous mode, whether routed there or not. Two possible solutions (that may or may not be easy to in conjunction with Twisted) are: * Route the multicasts explicitly * Make the listening socket bind explicitly to the network interface where you expect/see the multicast. This is the solution I have used myself, but may require using low level socket functionality. Binding to localhost (all interfaces at once) or similar did not work for me. Best regards, Lars Ivar On Wed, Mar 10, 2010 at 11:35 AM, Ben Barker <ben@bbarker.co.uk> wrote:
Thanks Lars - yes, I am not adamant about using twisted, although it seemed initially to be the best place to stary. I have also been looking at the pcapy module, which I think may do what I want, but also seems very low level. On Wed, Mar 10, 2010 at 10:48 AM, Lars Ivar Igesund <larsivi@gmail.com> wrote:
On 10/03/10 10:35, Ben Barker wrote:
That's a little vague. Does "trouble" mean "it sometimes works" or "never works"?
FYI, the 224.0.0.0/24 group is usually not IGMP snooped, and is effectively therefore broadcast. Conversely, groups outside this range require working IGMP querying / snooping and some help from (usually) a router, so this may be why you chose this range. Broadly speaking, as long as the UDP socket is listening on the right port and you've called joingroup, you should be ok. Can you post a complete example that isn't working for you? When your code is running, have a look "/sbin/ip maddr" to ensure the group has been added to the socket listen filter.
Sorry - yes, it was very vague! Never works. If I run wiresahrk I can see udp packets addressed to 224.0.0.4, port 901, flying past, however when I run my python script it does not appear to ever receive anything. The scritp I am running is almost identical to an exampel I found here: http://code.activestate.com/recipes/425975-simple-udp-multicast-client- server-using-twisted/
That's interesting.... eth1 is the wrong interface! In fact, it isn't connected to anything at all. eth0 is the interface that should be being used. I will try to swap them around, but presumably this is something I can specify somwhere... As I said, the code I am using is taken from the above link, but the exact listing is given below: from twisted.internet.protocol import DatagramProtocol from twisted.internet import reactor from twisted.application.internet import MulticastServer class MulticastServerUDP(DatagramProtocol): def startProtocol(self): print 'Started Listening' # Join a specific multicast group, which is the IP we will respond to self.transport.joinGroup('224.0.0.4') def datagramReceived(self, datagram, address): print "Server Received:" + repr(datagram) reactor.listenMulticast(901, MulticastServerUDP()) reactor.run()
Well that's odd... I changed the interfaces over - used eth1 for the connection to the network I need to sniff... and now /sbin/ip maddr tells me I have joined 224.0.0.4 on eth0 ! Whichever interface is live, the join seems to happen on the other :-p What could there be about my network config that is making this happen :-p On Wed, Mar 10, 2010 at 1:03 PM, Ben Barker <ben@bbarker.co.uk> wrote:
Ah - I have now sorted the interface problem. I run the code I listed earlier, but it sites at the command line saying "listening" without every dumping anything to screen. /sbin/ip maddr now shows: eth1 link 01:00:5e:00:00:04 link 33:33:ff:7a:7e:4e link 01:00:5e:00:00:fb link 01:00:5e:00:00:01 link 33:33:00:00:00:01 inet 224.0.0.4 inet 224.0.0.251 inet 224.0.0.1 inet6 ff02::1:ff7a:7e4e inet6 ff02::1 And this is the same intterface on which I would expect to see the multicast udp packets. On Wed, Mar 10, 2010 at 1:28 PM, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
participants (4)
-
Ben Barker -
Itamar Turner-Trauring -
Lars Ivar Igesund -
Phil Mayers