Hi, did you use the pre-compiled executables from gnugk.org on Windows and Linux to compare or did you compile it yourself ? If you compiled yourself, which PTLib version did you use ? (Its printed when GnuGk starts.)
Regards, Jan Immo Wehrenberg wrote: > Hi, > I have done testing with the new version. Unfortunately, it came out without > any difference at first. However, with the very same VCS and > GnuGk-configuration, it works with GnuGk-3.2 *for Windows*. > > I have again compared packet dumps. The good thing is that I can now rule out > that the sequence number is the issue as GnuGk on Windows also starts with > sequence number 1. > > This narrows it down to a bug in the md5 hash creation on at least Linux, > maybe other platforms as well. > > I'm happy to help with the debugging. However, my C++ is not good enough to > create a patch on my own. > > Any help appreciated, > > Immo > ________________________________________ > From: Immo Wehrenberg [[email protected]] > Sent: Monday, January 14, 2013 11:34 > To: GNU Gatekeeper Users > Subject: Re: [Openh323gk-users] Problem registering GnuGk to VCS Expressway > as traversal client > > Hi, > thanks for clarification. > I think the packet dump indicates that this is the case. Just to be sure, > here is the relevant configuration of GnuGk and the VCS: > > GnuGk: > | [RoutedMode] > | GKRouted=1 > | H245Routed=1 > | CallSignalPort=1720 > | CallSignalHandlerNumber=4 > | AcceptNeighborsCalls=0 > | AcceptUnregisteredCalls=0 > | RemoveH245AddressOnTunneling=1 > | RemoveCallOnDRQ=0 > | DropCallsByReleaseComplete=1 > | SendReleaseCompleteOnDRQ=1 > | SupportNATedEndpoints=1 > | ForwardOnFacility=1 > | EnableH46018=1 > | > | [RasSrv::Neighbors] > | VCSServer=GnuGk > | > | [Neighbor::VCSServer] > | ;;from unknown IP > | Host=xx.15.xx.112:6123 > | SendPrefixes=* > | AcceptPrefixes=* > | H46018Client=1 > | H46018Server=0 > | SendAuthUser=test > | SendPassword=test > > and configuration of the traversal zone on the VCS: > > | *c xConfiguration Zones Zone 2 Name: "test-gnugk" > | *c xConfiguration Zones Zone 2 HopCount: 15 > | *c xConfiguration Zones Zone 2 H323 Mode: On > | *c xConfiguration Zones Zone 2 SIP Mode: Off > | *c xConfiguration Zones Zone 2 Type: TraversalServer > | *c xConfiguration Zones Zone 2 TraversalServer Authentication Mode: > DoNotCheckCredentials > | *c xConfiguration Zones Zone 2 TraversalServer Authentication UserName: > "test" > | *c xConfiguration Zones Zone 2 TraversalServer Registrations: Allow > | *c xConfiguration Zones Zone 2 TraversalServer UDPProbe RetryInterval: 2 > | *c xConfiguration Zones Zone 2 TraversalServer UDPProbe RetryCount: 5 > | *c xConfiguration Zones Zone 2 TraversalServer UDPProbe KeepAliveInterval: > 20 > | *c xConfiguration Zones Zone 2 TraversalServer TCPProbe RetryInterval: 2 > | *c xConfiguration Zones Zone 2 TraversalServer TCPProbe RetryCount: 5 > | *c xConfiguration Zones Zone 2 TraversalServer TCPProbe KeepAliveInterval: > 20 > | *c xConfiguration Zones Zone 2 TraversalServer H323 Protocol: H46018 > | *c xConfiguration Zones Zone 2 TraversalServer H323 H46019 Demultiplexing > Mode: On > | *c xConfiguration Zones Zone 2 TraversalServer H323 Port: 6123 > | *c xConfiguration Zones Zone 2 TraversalServer SIP Protocol: Assent > | *c xConfiguration Zones Zone 2 TraversalServer SIP Port: 7003 > | *c xConfiguration Zones Zone 2 TraversalServer SIP Transport: TLS > | *c xConfiguration Zones Zone 2 TraversalServer SIP TLS Verify Mode: Off > | *c xConfiguration Zones Zone 2 TraversalServer SIP TLS Verify Subject Name: > "" > | *c xConfiguration Zones Zone 2 TraversalServer SIP Poison Mode: Off > | *c xConfiguration Zones Zone 2 TraversalServer SIP Media Encryption Mode: > Auto > > Does anything in here look incorrect? > > Unfortunately my C++ kung-foo isn't sufficient to figure out how the md5 hash > is generated. Since this is beside of the sequence number the only thing that > is different to the VCS dump, I suspect this as a potential source of the > problem. Just to be sure: can someone point me to the location in the source > to change the initial value of the sequence number from '1' to something > "random" (would change the constant to some number that appears to be random, > just to make sure that this is not the cause of the problem). > > Thanks for all your help, > > Immo > ________________________________________ > From: Jan Willamowius [[email protected]] > Sent: Wednesday, January 09, 2013 23:40 > To: [email protected] > Subject: Re: [Openh323gk-users] Problem registering GnuGk to VCS Expressway > as traversal client > > Hi, > > the _endpoint_ registration is different from the traversal zone > neighbor registration. A VCS should send a similar SCI than GnuGk when > neighboring. > > To the best of my knowledge, the generation of the MD5 hash is not > documented in any H.235 standard (even so its the most popular and > interoperable hash in use). GnuGk does it like the old OpenH323 code > did it and so far the hash always matched. The code is my only > reference. > > Regards, > Jan > > Immo Wehrenberg wrote: > > Hi Jan, > > thanks for your fast reply. What exactly do you mean by "different in > > structure"? The idea is to replace the second VCS by the GnuGk as neighbor > > to the VCS-Expressway in the traversal zone. The dump from the VCS packet > > was taken when it connected to the very same traversal zone as the one I > > tried to connect the GnuGk to. > > > > I therefore assume that the VCS is configured correctly (as it works with > > another VCS instead of the GnuGk). It also matches the configuration > > suggested by the manual you quoted. I also assume that the configuration of > > the GnuGk is correct, as the SCI looks similar. Still, I'm happy to play > > with configuration settings if anyone suggests alternative settings. > > > > I'd agree with you that it sounds unlikely, that the VCS refuses to play > > with the GnuGk because it starts with sequence number 1 instead of a random > > one. However, the packet trace indicates that this is one of the two > > relevant differences between a working and a non-working SCI for > > registration. > > > > I would also be happy to verify that the VCS and the GnuGk are generating > > the md5-password-hashes properly if someone gives me information on how the > > hashes are generated (i.e. what format does the time stamp have in the > > hash. how is the password appended to the time stamp, are there any > > separators in the format) as this is the other possible issue that I see > > from the packet dump. > > > > Best regards, > > > > Immo > > ________________________________________ > > From: Jan Willamowius [[email protected]] > > Sent: Tuesday, January 08, 2013 22:10 > > To: [email protected] > > Subject: Re: [Openh323gk-users] Problem registering GnuGk to VCS Expressway > > as traversal client > > > > Hi Immo, > > > > the SCIs must be different in structure, because neighbors establish a > > traversal zone slighly different from endpoint registrations. > > Did you configure GnuGk as traversal zone in the VCS ? > > > > The GnuGk manual has a section on configuring the VCS: > > http://www.gnugk.org/gnugk-manual-10.html#ss10.5 > > > > I really don't think the VCS is rejecting the neighbor because we start > > sequence numbers at 1. > > > > Regards, > > Jan > > > > -- > > Jan Willamowius, Founder of the GNU Gatekeeper Project > > EMail : [email protected] > > Website: http://www.gnugk.org > > Support: http://www.willamowius.com/gnugk-support.html > > > > > > Immo Wehrenberg wrote: > > > Dear List, > > > I'm trying to connect a GnuGk to a Cisco VCS Expressway as traversal > > > client using a sligthly adopted version of the example configuration > > > in the manual (http://www.gnugk.org/gnugk-manual-10.html). > > > > > > Unfortunately, the GnuGk is unable to register at the Cisco VCS. > > > > > > I have done a detailed analysis of that behaviour: > > > > > > As expected, the GnuGk sends a H.225 SCI to the VCS Expresway. A > > > packet decoding with Wireshark looks as follows: > > > > > > Frame 12: 101 bytes on wire (808 bits), 101 bytes captured (808 bits) > > > Ethernet II, Src: CadmusCo_xx:22:xx (08:22:27:xx:22:xx), Dst: > > > Cisco_xx:78:xx (c4:7d:4f:xx:78:xx) > > > Internet Protocol Version 4, Src: 192.168.77.72 (192.168.77.72), Dst: > > > xx.15.130.112 (xx.15.130.112) > > > User Datagram Protocol, Src Port: h323gatestat (1719), Dst Port: > > > backup-express (6123) > > > H.225.0 RAS > > > RasMessage: serviceControlIndication (30) > > > serviceControlIndication > > > requestSeqNum: 1 > > > serviceControl: 1 item > > > Item 0 > > > ServiceControlSession > > > sessionId: 0 > > > reason: open (0) > > > open: NULL > > > cryptoTokens: 1 item > > > Item 0 > > > CryptoH323Token: cryptoGKPwdHash (1) > > > cryptoGKPwdHash > > > gatekeeperId: test > > > timeStamp: Jan 7, 2013 21:06:34.000000000 CET > > > token > > > algorithmOID: 1.2.840.113549.2.5 (md5) > > > paramS > > > hash: 3101089b79e22f2609507fbcb2174772 > > > [bit length 128] > > > featureSet > > > .... 0... replacementFeatureSet: False > > > supportedFeatures: 1 item > > > Item 0: Signalling Traversal > > > FeatureDescriptor > > > id: standard (0) > > > standard: 18 - Signalling Traversal > > > > > > The VCS Answers (Ethernet/IP/UDP headers ommitted) > > > > > > H.225.0 RAS > > > RasMessage: serviceControlResponse (31) > > > serviceControlResponse > > > requestSeqNum: 1 > > > result: failed (1) > > > failed: NULL > > > > > > To compare that with a working configuration, I registered another Cisco > > > VCS > > > as traversal client and have again decoded a packet dump of the > > > registration > > > with wireshark: > > > > > > H.225.0 RAS > > > RasMessage: serviceControlIndication (30) > > > serviceControlIndication > > > requestSeqNum: 57923 > > > serviceControl: 1 item > > > Item 0 > > > ServiceControlSession > > > sessionId: 0 > > > reason: open (0) > > > open: NULL > > > cryptoTokens: 1 item > > > Item 0 > > > CryptoH323Token: cryptoGKPwdHash (1) > > > cryptoGKPwdHash > > > gatekeeperId: test > > > timeStamp: Jan 8, 2013 12:24:40.000000000 CET > > > token > > > algorithmOID: 1.2.840.113549.2.5 (md5) > > > paramS > > > hash: 54a3c3fe4fa909743b38bd940b882ed4 > > > [bit length 128] > > > featureSet > > > .... 0... replacementFeatureSet: False > > > supportedFeatures: 1 item > > > Item 0: Signalling Traversal > > > FeatureDescriptor > > > id: standard (0) > > > standard: 18 - Signalling Traversal > > > > > > > > > which leads to a successful registration: > > > > > > H.225.0 RAS > > > RasMessage: serviceControlResponse (31) > > > serviceControlResponse > > > requestSeqNum: 57923 > > > result: started (0) > > > started: NULL > > > featureSet > > > 0... .... replacementFeatureSet: False > > > supportedFeatures: 1 item > > > Item 0: Signalling Traversal > > > FeatureDescriptor > > > id: standard (0) > > > standard: 18 - Signalling Traversal > > > genericData: 2 items > > > Item 0: Signalling Traversal > > > GenericData > > > id: standard (0) > > > standard: 18 - Signalling Traversal > > > parameters: 1 item > > > Item 1 > > > GenericData > > > id: nonStandard (2) > > > nonStandard: > > > c2f2d2a2-1527-11dd-a123-0fc456d89593 > > > parameters: 1 item > > > > > > Time is synchronized by ntp on the VCS and the GnuGk. The time is the > > > same on the Expressway and the GnuGk-Host > > > > > > In the packet dump, I see only three differences from which I only see > > > two of them as a > > > > > > 1) requestSeqNum is appearantly random on the VCS and 1 on the GnuGk. > > > A randomly chosen requestSeqNum makes IP spoofing much more difficult, so > > > that may be a security measurement of the VCS to reject messages using > > > 1 as sequence number. It should be fairly easy to exchange the 1 with > > > some unpredictable random number though (maybe using openssls RAND_* > > > funktions?). Unfortunately, GnuGk is real C++ code which is not one > > > of the languages i'm able to write. > > > 2) The timestamp differs > > > Which is not surprising as the snapshots where taken at different > > > time. > > > That one is obvious and should not be a source of the problem > > > 3) The hash differs. > > > That is as well obvious, as the timestamp is part of the hash. However, I > > > was not able to figure out how that hash is created exactly so i could > > > not verify wether the hash is created equally on both systems. > > > (In particular, my C++ is not good enough to identify the correct part > > > of the code in GnuGk and I have either not found or not understood how > > > to create that hash correctly in the standard. Any pointer to a > > > reasonably simple to understand description would be appreciated.) > > > > > > Have I missed something? Any Ideas? > > > > > > Thanks in advance, > > > > > > Immo -- Jan Willamowius, [email protected], http://www.gnugk.org/ ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________________ Posting: mailto:[email protected] Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
