Hi Jan:
On Thu, Jul 23, 2015 at 3:24 PM, Jan Willamowius jan@willamowius.de wrote:
Hi Jose, thanks for finding that bug. Do you have a patch I can apply to the CVS ?
Jose Uceda is my next-table colleague. We've been working on this together.
He put on a patch which solved the problem for us:
--- h323plus.orig/src/transports.cxx 2015-07-21 10:10:18.422143019 +0200 +++ h323plus/src/transports.cxx 2015-07-21 10:11:38.655442814 +0200 @@ -2066,5 +2066,5 @@
#if PTLIB_VER >= 2110 - canGetInterface = binding.IsAny(); + canGetInterface = FALSE; // juceda - disable bogus canGetInterface code #else canGetInterface = (binding.IsAny()) && udp->SetCaptureReceiveToAddress();
But we fear this may not be correct. To explain it I need to elaborate a little bit. Some of the things I'm writting have been deducted doing VC bisections and may not be acurate, so if someone is wronly named it's my fault. I'm going to explain the process.
When upgrading ptlib to 2.12 we lost gatekeeper operation, and traced it to the bug reported by Jose. Succintly, the RRQ packet got the IP part of the rasAddress transport address from the SOURCE of the GCF packet instead of the destination, so our gatekeeper sent a security denial RRJ due to the ACLs.
Then we traced the problem to the offending code, one of the variations of:
#if PTLIB_VER >= 2110 if (canGetInterface) { WORD notused; // TODO: verify that this actually does the same as the pre 2.11.x version socket->GetLastReceiveAddress(lastReceivedInterface, notused); } #else if (canGetInterface) lastReceivedInterface = socket->GetLastReceiveToAddress(); #endif
Pre 2.11 PTLIB had a method to capture and get the destination (local) address of a received packet, aptly named getLastReceived*To*Address, to distinguish it from the ( also present ) method GetLastReceiveAddress ( no To, it could have been named from ) which gets the source ( remote ) address of the received packet.
At some point in the 2.11 development socket code was changed. We think it was by Craig Southern, in case he reads this and wants to chip in. In this change the *TO* variation of the functions was removed. Near this time we think it was Craig too who changed transports.cxx to use the other function. We think that change is incorrect as instead of doing lastReceivedInterface=local destination address of received packet it sets it to remote source address. In facts two lines after the #if the same function is called again and it's result is assigned to remoteAddress.
After poking a bit we found that setting canGetInterface to false solves our problems, works FOR US. But I fear it works because none of our sockets are bound to INADDR_ANY, or something like this.
With my limited knowledge of h323+/ptlib it seems h323+ uses received address of the ras packet to refine its workings. And that it does it conditioned on the canGetInterface flag which, pre 2.11, was intialized to udp->SetCaptureReceiveToAddress(), as the binding.isAny() part is more a 'should get local address from the packet as I'm bound to INADDR_ANY'.
If this is acurate, as ptlib 2.12 has not a method to get the local destination address, I think the code for ptlib > 1.10 must be supressed, as using the REMOTE address instead of the local one is incorrect, and we think it's never going to do good. It may work with GK which do not use the rasAdress field on the RRQ for security / whatever and instead use the RRQ source address, but in this case anything will work, and will harm the ones like ours, and IIRC yours too, which do use it. If ptlib 2.11+ has a method to get it it must be used, but we were unable to find it, it seems its gone for good.
OTOH, given udp->SetCaptureReceiveToAddress() can fail ( I suppose because the socket library has no method to give it ), we feel our patch is not that bad, but also feel it works because it makes H323TransportUDP::ReadPDU(PBYTEArray & pdu) leave lastReceivedInterface empty. And we are nto knowledgeable enough to assert it, hence we will need some help.
The PTLib >= 2.11.x code didn't gte the same amount of testing as the older code. Thats why I still use PTLib 2.10.x for GnuGk.
We are doing the same presently, but as the h323+ page recomends 2.12.8 with 1.26.5 we tested it, as we do periodically, to peek the assorted bugfixes and new functionality which normally come with new releases, although 1.26 is giving us a hard time.
Regards. Francisco Olarte.