What should you do when:
- you write for the fourth time the same post because of a Wordpress I-don’t-know-what-except-that-the-more-I-look-at-its-internal-the-less-I-like-it ;
- you find in the sources of a quite spread, sectorial commercial software this software protection:
GetPrivateProfileString "GENERAL", "Reg", "", strREG, Len(strREG), IniFile
strREG2 = Left(strREG, 9)
If strREG2 = "something like this” Then
ExistsHASP4 = True
Else
ask for registration
Posted by mattia as code at 3:43 PM CET
No Comments »
Ok, first of all, my usual rant about something working badly.
I understand that, since IPv4 address space is considered a subset of IPv6 one (e.g., 192.168.0.3 becomes [::ffff:192.168.0.3]), when I bind on port 1234 using IPv6 wildcard address ([::], the equivalent of IPv4’s 0.0.0.0), I take control of port 1234 also for IPv4; so, when someone tries to connect via IPv4 to my server at port 1234, I get it.
But WHY, if I use IPv4 wildcard, I get the same result? Better, I get a mixed result under my debian etch: IPv6 connections are refused (and this is quite correct), but I cannot bind to the same port on the IPv6 address space, neither using the wildcard (and this too is correct, because the IPv6 wildcard would imply also all the IPv4 address space, which is instead already taken) nor using a specific IPv6 address, and this is what makes me crazy. I mean, everything solved for me by forcing the server which took the IPv4 wildcard to be someone more selective, and take only a specific IPv4 address, but the doubt remains.
And now, why did you do this? Well, my dear amavis, as I already told you, does not bind to IPv6 addresses. So I wrote a little TCP tunnel which does only and exactly this: bring connections and datas from one address to another one; in this case, listen on the IPv6 address and forward it to the IPv4. A sort of TCP router, I’d say. In attachment, the code.
BEWARE: using the TCP tunnel, there’s a slight change of semantic for refused connection. If the destination address refuse a connection, the tunnel instead accept it and immediatly drop it. Sorry, this shouldn’t cause any problem for common uses.
Posted by mattia as ipv6 at 3:04 PM CET
No Comments »
