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 [jan@xxxxxxxxxxxxxx] Sent: Tuesday, January 08, 2013 22:10 To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: 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 : jan@xxxxxxxxxxxxxx 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 ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ 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_122512 _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx 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/ ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx 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/
