Logcat errors in DNS translateDestinationAdress (negative byte error)

[nyanpasu64]

I'm getting Logcat errors due to a DNS66 sign error. https://gist.github.com/jimbo1qaz/180fb2c48566b1d88bbfe9f64804eec7

handleDnsRequest: Cannot handle packets to192.0.2.255
java.lang.ArrayIndexOutOfBoundsException: length=10; index=-3
	at java.util.ArrayList.get(ArrayList.java:413)
at org.jak_linux.dns66.vpn.DnsPacketProxy.translateDestinationAdress(DnsPacketProxy.java:214)

https://github.com/julian-klode/dns66/blob/600f6cbe7d65cf64c7f2fb1ba6ee5eca215ec9ef/app/src/main/java/org/jak_linux/dns66/vpn/DnsPacketProxy.java#L211

If addr[addr.length - 1] >= 128, index is negative.

• IDK, maybe index &= 0xff??
• Or you could do index = (addr[addr.length - 1] - 2) & 0xff? The cast is unnecessary due to int promotion on - and &.

---

Also your error message is missing a space between "to" and the IP: Log.e(TAG, "handleDnsRequest: Cannot handle packets to" + parsedPacket.getHeader().getDstAddr().getHostAddress(), e);

Also "catch exception e" seems like bad programming practice that near-silently swallows these kinds of errors (except Logcat).

Is this intentional behavior? Why exactly are you picking DNS servers based on the IP's last digit?

[julian-klode]

Oh, but that's not really a bug, you surely don't have 254 DNS servers configured, or well, more then 128. So the packet would be rejected anyway.

Catching all exceptions is very important as I don't want to crash DNS66 just because it does not understand one packet.

It creates the IP addresses to map to upstream DNS servers and indexes by the last byte because that really should be enough DNS servers for everyone and we can just stuff it into an array and avoid a map.

[julian-klode]

So, I'll do &0xFF somewhere to allow more than 128 DNS servers, as it does not hurt, but I don't think it will be all that useful in practice :)

[nyanpasu64]

What causes the exception to enter Logcat, despite being caught?

What causes requests to 192.0.2.255 and ff12::8384, is this normal behavior to get caught by the DNS filter? Maybe it's working as intended, a quirk? Hopefully it has no negative impacts.

[julian-klode]

Well, it's in logcat because it's explicitly logged so we know the reason why we could not forward. And I guess you are seeing multicast packets to those ip addresses.

We add routes for /24 IPv4 (192.0.2/24, 198.51.100/24, 203.0.113/24), and /120 IPv6 subnets (2001:db8::/120), as things IIRC did not work when just routing the individual server addresses. (And those addresses are actually reserved for documentation purposes, so, um, dns66 is a bad bad program, but it was the best way to avoid overlapping with real routes).