Hello Michal!
It seems that beginning with Gnugk 2.2.3 all NetMeeting endpoints have
this problem, not being able to register to GnuGk. We have checked the
NetMeeting RRQ packet and there is no indication of a "broadcasted"
request. After all, we have explicitly specified the IP of the
gatekeeper on the NetMeeting side, the target port of the RRQ is 1719
(not 1718) and as far as we can tell, NetMeeting, does not support
gatekeeper discovery. We include the packet dump of the NetMeeting RRQ
below:
Frame 6 (156 bytes on wire, 156 bytes captured)
Arrival Time: Sep 16, 2005 09:57:01.627251000
Time delta from previous packet: 4.999981000 seconds
Time since reference or first frame: 14.992013000 seconds
Frame Number: 6
Packet Length: 156 bytes
Capture Length: 156 bytes
Protocols in frame: eth:ip:udp:h225
Ethernet II, Src: Intel_fd:7f:13 (00:03:47:fd:7f:13), Dst: Cisco_b4:a5:c0 (00:0b:45:b4:a5:c0)
Destination: Cisco_b4:a5:c0 (00:0b:45:b4:a5:c0)
Source: Intel_fd:7f:13 (00:03:47:fd:7f:13)
Type: IP (0x0800)
Internet Protocol, Src: 155.207.200.15 (155.207.200.15), Dst: 155.207.1.32 (155.207.1.32)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 142
Identification: 0x0683 (1667)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x330e [correct]
Source: 155.207.200.15 (155.207.200.15)
Destination: 155.207.1.32 (155.207.1.32)
User Datagram Protocol, Src Port: 1225 (1225), Dst Port: 1719 (1719)
Source port: 1225 (1225)
Destination port: 1719 (1719)
Length: 122
Checksum: 0x6ab5 [correct]
H.225.0 RAS
RasMessage
RasMessage: registrationRequest (3)
registrationRequest
requestSeqNum: 1
protocolIdentifier: 0.0.8.2250.0.2 (itu-t(0) recommendation(0) h(8) h225-0(2250) version(0) 2)
0... .... discoveryComplete: False
callSignalAddress: 1 item
Item 0
TransportAddress
Item: ipAddress (0)
ipAddress
ip: 155.207.200.15 (155.207.200.15)
port: 1720
rasAddress: 1 item
Item 0
TransportAddress
Item: ipAddress (0)
ipAddress
ip: 155.207.200.15 (155.207.200.15)
port: 1225
terminalType
terminal
.0.. .... mc: False
..0. .... undefinedNode: False
terminalAlias: 2 items
Item 0
AliasAddress
Item: h323-ID (1)
h323-ID: dimitris@xxxxxxxxxxx
Item 1
AliasAddress
Item: dialedDigits (0)
dialedDigits: 5310996666
endpointVendor
vendor
t35CountryCode: United States (181)
t35Extension: 0
manufacturerCode: 21324
H.221 Manufacturer: Microsoft (0xb500534c)
productId: Microsoft\256 NetMeeting\256
versionId: 3.0
We have also tried to disable the GnuGk BroadcastListener (port 1718),
as you showed, but there was no change in the behavior of the endpoint.
Could it be that the latest version of GnuGk introduced a problem in
parsing RRQ's and misinterprets the NetMeeting RRQ as a "broadcast"
request? NetMeeting was able to register in all previous versions of
GnuGK, with no such problems. Is there anybody else that has run into
this problem, or are there users of NetMeeting successful in working
with Gnugk 2.2.3?
Thanks to all for your help.
On 17 Σεπ 2005, at 12:05 μμ, Zygmuntowicz Michal wrote:
Your problem is that your endpoint tries to broadcast RRQ.
The 2.2.3 does not support broadcast RRQ. Only GRQ and LRQ
are valid for broadcast. Try to either enable gatekeeper discovery
or set the gatekeeper address manually in your endpoint.
----- Original Message ----- From: "Apostolos Karakousis"
<ktolis@xxxxxxxxxxx>
Sent: Friday, September 16, 2005 10:05 AM
I created he following setup with gnugk-2.0.9 by compiling it
manually from
sources.
I am using NetMeeting 3.0 to register with the Gatekeeper. I set up a
mechanism
using freeradius.
All is working fine without a problem.
I now want to change from 2.0.9 to 2.2.3. I installed it from portage
( I am
using gentoo) and modified the configuration file accordingly. I
am now having problems registering with the Gatekeeper and it show
this on the
debug output:
2005/09/16 09:56:50.855 6 yasocket.cxx(798) GkStatus
waiting...
2005/09/16 09:56:51.857 6 yasocket.cxx(798) GkStatus
waiting...
2005/09/16 09:56:52.859 6 yasocket.cxx(798) GkStatus
waiting...
2005/09/16 09:56:53.861 6 yasocket.cxx(798) GkStatus
waiting...
2005/09/16 09:56:54.833 5 yasocket.cxx(739) RasSrv 1
sockets
selected from 3, total 3/0
2005/09/16 09:56:54.833 4 RasSrv.cxx(211) RAS
Receiving on
0.0.0.0:1719(Bcast)
2005/09/16 09:56:54.833 2 RasSrv.cxx(173) RAS Read
from
155.207.200.15:1225
2005/09/16 09:56:54.833 1 RasSrv.cxx(301) RAS
Unknown
broadcasted RAS message tag 3
2005/09/16 09:56:54.864 6 yasocket.cxx(798) GkStatus
waiting...
2005/09/16 09:56:55.866 6 yasocket.cxx(798) GkStatus
waiting...
The gnugk machine is using a firewall but has port 1719 open for tcp
and udp.
I am attaching the ethereal capture (.pcap compatible), some text
version of it
and the log and configuration file
Netmeeting reports a timeout from the gatekeeper after the 5th attept
to join.
Why is this happening? Has anyone seen this before? Any suggestions?
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very
own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe:
http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
Apostolos Karakoussis
