• 1 Post
  • 10 Comments
Joined 2 years ago
cake
Cake day: July 21st, 2023

help-circle
  • this puts a hole in your firewall

    Indeed, thanks, I realized that shortly after posting it.

    dig not supporting mdns

    Yep you both are correct. Looking at it now, the result does actually warn me that I’m trying to send a regular DNS request to mDNS multicast address.

    It just sort of happens to work correctly if you get a single reply

    Yeah I guess it’s a hack. To me it does not really matter because I’m just using it for wireguard, so the worst thing that could happen is that I would try to connect to a wrong host and the key exchange would fail.

    libnss-mdns

    The reason for why I’m doing this whole hack is that nss-mdns package is only available on glibc version of Void but I’m using musl, so it’s really just hacks on top of hacks. I found a final solution though so that’s nice (see final edit of post). Thanks for all your replies!


  • It’s solved now. Basically what’s happening is that I ask a multicast address on UDP port 5353 and get a response from different IP because the original IP was multicast. So my firewall blocks the reply, because it really isn’t a reply like downloading a webpage. I solved it by filtering based on the source port. Meaning the reply has source port 5353 but on my machine it arrives at some random UDP port so I cannot really filter based on the destination port.

    solution

    -A OUTPUT -p udp -m udp --sport 5353 -j ACCEPT
    

    Thanks for your help!



  • Edit 2: Actually dig picks a random port to send the mDNS request from and sends it to 224.0.0.251:5353 (multicast IP). The correct host then replies from port 5353 to the previously picked random port from dig. But I found that you can specify the port with dig -b IP#port so I think that should help. I kinda don’t have the time to try it out currently though.

    end of edit2.

    well I randomly solved it by adding

    -A OUTPUT -p udp -m udp --sport 5353 -j ACCEPT
    

    Which basically means you are right. The destination port is just some randomly picked number (checked wireshark), so I have to filter based on source port, which is 5353.

    Edit: Also thanks for your help!







  • Well the dev said that he does not care about the license. He wanted to create a coreutils alternative with better concurency using Rust as a pet project. He had even stated that he was not interested in the MIT vs GPL drama, yet people here were acting like children over it.

    People think it’s some kind of Canonical evil master plan, yet it’s just some random dude slapping a license on his cool new code, without really thinking about it. Also this conspiracy does not make sense at so many levels. For one Canonical would shoot themselves into their foot if they created their own proprietary coreutils, because admins would not want to deal with non-portable scripts. Also there are already the BSD utils, so if they wanted to create their own fork, they would have already done that by now. They won’t because they prefer free labor from FOSS devs.