Hello Immo, Have you tried setting the vcs traversal server protocoll to assent, it seems to be working on some vcs x-versions.
xConfiguration Zones Zone 2 TraversalServer H323 Protocol: Assent I have manage to get it to work by doing so, few month back when i was testing same scenario. Rgs Egil Hasting On 14. jan. 2013, at 11:34, Immo Wehrenberg <[email protected]> wrote: > 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 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:[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/ > > > > ------------------------------------------------------------------------------ > 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:[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/ ------------------------------------------------------------------------------ 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:[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/
