0

I have been using https://github.com/ottomata/multicast-tester to configure one host to listen to multicast traffic, so that I can capture it with tcpdump. This was the easy part:

ip route add 224.0.0.0/4 dev eth0
multicast-receiver -g 239.255.0.2 -p 5568

tcpdump -A -X -veni wlan0 dst host 239.255.0.2
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:12.879565 10:dd:b1:99:16:45 > 12:42:99:5a:b9:c1, ethertype IPv4 (0x0800), length 680: (tos 0x0, ttl 32, id 7747, offset 0, flags [none], proto UDP (17), length 666)
    192.168.1.71.60230 > 239.255.0.2.5568: UDP, length 638
        0x0000:  4500 029a 1e43 0000 2011 c81f c0a8 0147  E....C.........G
        0x0010:  efff 0002 eb46 15c0 0286 de35 0010 0000  .....F.....5....
        0x0020:  4153 432d 4531 2e31 3700 0000 726e 0000  ASC-E1.17...rn..
        0x0030:  0004 9ecf d3c6 1b01 7547 a506 37c0 6c96  ........uG..7.l.
        0x0040:  7e12 7258 0000 0002 4d2d 5365 7269 6573  ~.rX....M-Series
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0080:  0000 0000 0000 0000 6400 00a1 0000 0272  ........d......r
        0x0090:  0b02 a100 0000 0102 0100 0000 0000 0000  ................
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0100:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0110:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0120:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0130:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0140:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0150:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0160:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0170:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0180:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0190:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0200:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0210:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0220:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0230:  0000 0000 0000 0000 0000 0000 0000 000e  ................
        0x0240:  ff00 000e ff00 0000 0000 0000 0000 0000  ................
        0x0250:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0260:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0270:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0280:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0290:  0000 0000 0000 0000 0000            

Now, I would like to replay this frame, in loop, forever. I know that I will need to reconfigre the host as a multicast source; but this should do it:

multicast-sender -g 239.255.0.2 -p 5568

So now, how do I replay my frame ?

I don't think multicast-sender will be able to handle the huge bunch of null chars; but nc should be able to do it. After fixing some details in the frame headers about src and dst fields.

For the curious people: this is ASC-E1.17 protocol for DMX over ethernet; the most recent devices use E1.31 or E1.37. This IP is universe 2. Port 5568 seems fixed by the norm, and I believe that the DMX slots are sent inline inside the frame (here I am sending a rotating color on slots 421-425, around 0x0240). My purpose is to check if it's easy to polluate the ACN norm, and study if someone having access to my network could mess with my work ... and how I should protect my network against problems. But, buying a second ACN source would be more expansive, and less flexible than forging a frame with nc ...

I have an other computer in the network to check if the parasite frame have been properly injected (and transmitted by the switch).

If this test fails, I will need to buy an other ACN source.

1 Answers1

0

So, I have found a solution:

Record a frame:

ip route add 224.0.0.0/4 dev wlan0
/root/multicast-tester/bash/multicast-receiver -g 239.255.0.1 -p 556
# start playing a sequence from an ACN master
# and from an other console:
tcpdump -veni wlan0 -c 10 -w /tmp/recc dst host 239.255.0.1

Now, replay the frame. The following project is a fork from tcpreplay: https://github.com/rigtorp/udpreplay after installation, just replay the frame in a loop:

while true ; do ./udpreplay -i wlan0 /tmp/recc ; done

and you will see your DMX client jitter between various orders.

tcpreplay is included in debian; udpreplay is not (yet).

My problem earlier was that I was listening on the wrong (DMX) universe (2 instead of 1).

This method could also be used to record and replay some DMX sequences; or be a starting point for a home written DMX master.

It's probably possible to have fun with other ACN devices with this method.