VirtualCdj sees itself as an "invader"

[Zippy1970]

            VirtualCdj virtualCdj = VirtualCdj.getInstance();
            virtualCdj.setUseStandardPlayerNumber( false );
            virtualCdj.setDeviceNumber( (byte) 0 ); // If set to zero, will attempt to claim any free device number
            virtualCdj.start();
            log.info("Auto-selected VirtualCdj device number {}", virtualCdj.getDeviceNumber());

This is pretty much all I do in my test program, but as soon as the VirtualCdj is started, I get these messages:

[main] INFO org.deepsymmetry.beatlink.VirtualCdj - Found matching network interface RD9700 USB2.0 To Fast Ethernet Adapter #3 (ethernet_32779), will use address /169.254.49.138/16 [/169.254.255.255]
Auto-selected VirtualCdj device number 7
[beat-link DeviceFinder receiver] INFO org.deepsymmetry.beatlink.VirtualCdj - Sending device number defense packet to invader at address 0:0:0:0:0:ffff:a9fe:318a%70, port 50000
[beat-link DeviceFinder receiver] WARN org.deepsymmetry.beatlink.VirtualCdj - Another device has claimed it owns our device number, shutting down.

I can pick any arbitrary number as device number - the result is always the same. This is on a system with two NICs. One is connected to my home network, the other is APIPA connected to a CDJ-2000NXS2. So what's going on?

PS: I've also tried my main NIC - no difference. Nothing else besides the CDJ-2000NXS2 is connected.

[Zippy1970]

Looking at the message, I think it's a IPv4/IPv6 conflict. VirtualCdj uses 169.254.49.138 as local address and announces itself on the network. It then receives its own announcement, but coming from 0:0:0:0:0:ffff:a9fe:318a, which is just the IPv6 mapping of 169.254.49.138. It then sends a defense packet to itself, which it honors and shuts itself down.

So yeah, I think this is a bug which could be fixed if beat-link normalized IP addresses.

[brunchboy]

This sounds like a network configuration problem. Please see the network troubleshooting section of the Beat Link Trigger user guide and make sure that you don’t have any loops in your network that cause broadcast packets to be received again. Also, if you can, it is better to discuss things in the Zulip community and make sure there is a consensus that something is an issue worth opening on GitHub before doing so.

[Zippy1970]

It's not a network problem. Tested it with different NICs, on a closed network - even a direct cable to the CDJ - all with the same results.

I do think this is a bug because even if there was a loop in my network (which there obviously isn't) it should ignore it's own broadcasts. And the messages it returns clearly shows it is comparing an IPv4 address with an IPv6 address.

[brunchboy]

As I mentioned above, GitHub is not the place for exploratory discussions like this. It is a network problem because if there was not a loop, then the broadcast being sent by Beat Link on its IPv4 interface would not be coming back to it on an IPv6 network address. You’ll want to configure your operating system to not do that, or run Java with a command line option to ignore IPv6 networks, since they can’t participate in Pro DJ Link networks anyway.

[Zippy1970]

With all due respect, I don't think this is a network configuration problem, because that's not how loops work. A layer-2 loop causes packet duplication at the Ethernet level, not address translation between IPv4 and IPv6. The address 0:0:0:0:0:ffff:a9fe:318a is an IPv4-mapped IPv6 address, it's literally 169.254.49.138 in IPv6 format.

As a matter of fact, a network loop is physically impossible when using a direct cable connection between my PC and the CDJ, which is one of the configurations I tested. There are no switches, no bridges, no possible path for a packet to loop back through the physical network.

What's happening is the OS's dual-stack networking is presenting the same broadcast packet through both IPv4 and IPv6 protocol stacks, and Beat Link is treating these as two different devices because it's comparing an IPv4 address to an IPv4-mapped IPv6 address without normalization.

The solution is proper address canonicalization in Beat Link's device number defense logic; normalize IPv4-mapped IPv6 addresses to their IPv4 equivalents before comparison, or simply ignore packets originating from the local machine's own IP addresses.

So maybe it's not a bug per se, but it's most certainly an oversight in Beat Link and what you are suggesting is a workaround - not a solution.

[brunchboy]

You are of course entitled to your opinions, but the place to discuss them is in the Zulip discussion community. The time to open an issue is once that community has agreed to, not before.

My opinion is that you are proposing I add a workaround to Beat Link to cope with the fact that your network has a loop at the OS level. The thousands of people who are successfully using Beat Link Trigger on a wide variety of operating systems tells me there are practical ways to solve this at the network level.

That said, if you are aware of clean, efficient Java code to implement what you are proposing, I would certainly entertain a PR. It does sound like a harmless way to protect against this particular network misconfiguration as long as it does not add too much processor overhead or code complexity.

[brunchboy]

As a matter of fact, a network loop is physically impossible when using a direct cable connection between my PC and the CDJ, which is one of the configurations I tested. There are no switches, no bridges, no possible path for a packet to loop back through the physical network.

There is all kinds of bridging, routing, and copying that can happen within the operating system, which is what seems to be causing the trouble in your case.

[brunchboy]

I have come up with some code that I think might work around this situation, to be called within the DeviceFinder’s isAddressIgnored() method:

    /**
     * Checks whether the supplied address is an IPV6 address that represents a wrapped IPV4 address. If so,
     * returns the IPV4 version of the address.
     *
     * @param address an address to potentially unwrap
     *
     * @return either the original address, or the IPV4 equivalent, if one exists.
     */
    public InetAddress unwrapV6mappedV4address(InetAddress address) {
        if (address instanceof Inet6Address) {
            Inet6Address wrapper = (Inet6Address) address;
            try {
                if (wrapper.isIPv4CompatibleAddress()) {
                    byte[] addressBytes = wrapper.getAddress();
                    // Extract the last 4 bytes, which hold the wrapped IPv4 address.
                    byte[] v4bytes = new byte[4];
                    System.arraycopy(addressBytes, addressBytes.length - 4, v4bytes, 0, 4);
                    return InetAddress.getByAddress(v4bytes);
                }
             } catch (UnknownHostException e) {
                logger.warn("Problem trying to unwrap potential IPV4 address from IPV6 address", e);
            }
        }
        return address;
    }

So I might push a snapshot of the library for you to try with, but before doing that I wanted to do some manual testing on my own, and I can’t even understand how you are getting these addresses. Java seems aggressively to return Inet4Address instances when you try to construct them as wrapped Inet6Addresses:

beat-link-trigger.core> (java.net.InetAddress/getByName "::ffff:192.168.1.1")
#object[java.net.Inet4Address 0xdeb9040 "/192.168.1.1"]

beat-link-trigger.core> (java.net.Inet6Address/getByName "::ffff:192.168.1.1")
#object[java.net.Inet4Address 0x67af1f05 "/192.168.1.1"]

So this is even further evidence that there is something uniquely strange happening on your system, which is why we are not seeing tons of BLT users running into this problem. Could we please, please, please move this discussion to Zulip where it has belonged all along?

[brunchboy]

Well, since I can’t test it locally, I have deployed a new snapshot release so you can see if it works around the issue for you. Could you try with a fresh copy of the 8.1.0-SNAPSHOT build of Beat Link?

[Zippy1970]

I'm so very sorry I haven't been able to test it yet. I have been extremely busy but will test it next week when work calms down a bit. :) But thank you for your attention in this matter!

[brunchboy]

No worries, thanks for sharing what you have seen, and I look forward to hearing whenever you do have time to try it.