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/
