MA3 1.9.7 OSC Send bug: source port same as destination port, preventing local OSC sends

BECOME PART OF THE COMMUNITY - Sign up here
  • So when using OSC send, GrandMA3 1.9.7 does a highly atypical (buggy/bad practice) thing that cripples local OSC sending: it uses destination ports as source ports. This prevents sending to a receiver on the same PC without doing some kernel-level interception and routing.

    Expected behavior:

    1. Send/SendCMD (but not Receive*) is used, destination 127.0.0.1:12345.

    2. onPC picks a random, available/unbound source port for sending its outgoing packets (e.g., 31337).

    3. onPC sends to destination port 12345 with source port 31337.

    4. OSC SEND works regardless of destination.

    What actually happens:

    1. Send/SendCMD (but not Receive*) is used, destination 127.0.0.1:12345.

    2. onPC picks the exact same source port as the destination port and errors if it's already bound by a listening server.

    3. onPC sends to destination port 12345 via source port 12345. (*)

    4. OSC SEND only works when sending to remote machines (or sending to itself, presumably).

    I've included a screenshot of the problem. In this instance, it's UDP port 8013. Notice how the gma3 process uses 8013 for its local port despite not having any form of receiving enabled on that socket.

    Thanks for looking into it, and cheers =)

    -Kurt

    (*) actually I didn't confirm this with a packet dump, so double check. Either way, the problematic behavior is in binding the source port, so it's irrelevant; with UDP the actual packet can even be source-port 0.

  • Based on the provided screenshot, you haven't selected a network interface. Therefore, the first step would be to choose one, save the configuration, and then restart ma3.

    I'm attaching how it looks on my end for comparison.

    Copying this and restarting, the same behavior is observed; onPC still seems to use the destination port as the source port (and bind), even when the destination is a broadcast, and, as before, there is no real reason to be receiving on the socket.

    edit: also added unresolved addresses to clarify what's going on.... even when an interface *is* selected, it doesn't bind on that interface, either... it goes global with 0.0.0.0.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!