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 [jan@xxxxxxxxxxxxxx] Sent: Wednesday, January 09, 2013 23:40 To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: 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 [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 -- Jan Willamowius, jan@xxxxxxxxxxxxxx, 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/ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 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_122412 _______________________________________________________ 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/
