From Shadow.Hunter at netrek.org Tue Jun 24 10:22:04 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] Re: [META] What makes the metaserver tick? -> 64bit issue In-Reply-To: <3EF839AA.4050900@netrek.org> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> <20030624001606.GA5241@brain.jpl.nasa.gov> <3EF839AA.4050900@netrek.org> Message-ID: <3EF86C9C.6010307@netrek.org> E. Hietbrink wrote: > Carlos Y. Villalpando wrote: > >>> ;-) of course. I'd like to ask for nl.netrek.org to be added, but first >>> I am curious what makes the automates setup fail. David Watson (Volcane) >>> also wondered why eurotwinks.netrek.org didn't get listed a while ago, >>> so it is not just my server. >> >> No clue. I could do a metaserver log and a tcpdump log to find out if >> stuff is getting to my sever to begin with. >> >> Let us know when you want it added. > > Small update. I now know what makes it fail. Now I still need to fix it. > > What I did: First checked if I didn't see any PDUs sent out to any > metaserver. Nothing. Then I started checking the file ERRORS. Ahum. > Should have done that sooner ;-) I got loads and loads of these two > types of messages: > > solicit: udp_attach: unable to bind to desired interface > (this.host.name field): Can't assign requested address > solicit: udp_tx: sendto: Can't assign requested address > > Closer investigation and debugging in solicit.c reveals that somehow > the calls to gethostbyname(m->ours) and gethostbyname(m->host) return > garbage. Wierd. This I need to look into. I seem to have a 64-bit problem. I run a Sun UltraSparc with NetBSD and the Vanilla server code isn't 64-bit safe. Example: changing the pointer copy in solicit.c from: m->address.sin_addr.s_addr = *(long *) hp->h_addr; to: ((char *)&(m->address.sin_addr.s_addr))[0] = hp->h_addr[0]; ((char *)&(m->address.sin_addr.s_addr))[1] = hp->h_addr[1]; ((char *)&(m->address.sin_addr.s_addr))[2] = hp->h_addr[2]; ((char *)&(m->address.sin_addr.s_addr))[3] = hp->h_addr[3]; solved my gethostbyname() issue. I think the ultrasparc is capable of running both 64 as 32 bit binairies concurrently, however I haven't found any compiler flag to enforce 32bit compiles. What's the procedure to follow here? Make the entire server 64-bit safe? > I did see another thing. Namely I run the server on a box behind a > NAT firewall. So my internal addresses won't be the same as the call to > gethostbyname("nl.netrek.org") returns. As a result the bind() call will > fail with (errno = 49 = EADDRNOTAVAIL) and the automated registration > will still fail. > > Is the bind() call really necessary? What if the server simply sends > the raw announcement PDU. Does the metaserver run a check on sender > address with the DNS-lookup-result of the reported serveraddress? That > would still make it `failsafe'. At the moment i'm running with the bind call deleted. Greetx, Erik _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Tue Jun 24 13:46:09 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] Firewalling a netrek server In-Reply-To: <5.2.0.9.0.20030514163201.024edeb8@mailgate.team17.com> References: <5.2.0.9.0.20030514163201.024edeb8@mailgate.team17.com> Message-ID: <3EF89C71.60104@netrek.org> Hi, As a followup on this old thread I'd like to report success in setting up my own server (nl.netrek.org). Unfortunately I could not use a nifty iptable firewall, but was limited to the DSL-built-in NAT-firewall. Very limited indeed. The main problem was that I could not open entire port ranges to the world. Only single port rules. As a result hardly anyone was able to get UDP working in the game ;-) I imagine there will potentially be more people with this issue so I fixed this by patching the file ntserv/socket.c ehb > diff socket.c socket.c_original 2301,2302c2300 < /* Use static range of UDP portnumbers. Easier for opening up firewalls */ < addr.sin_port = 3333 + me->p_no; --- > addr.sin_port = 0; It will now use local port numbers 3333..3348 for players, rather than the random numbers before. What I now have opened for initial INCOMING traffic in my firewall is this: 2591 TCP Player list (can be used by metaserver) 2592 TCP Player game port 2593 TCP Observer game port 4566 TCP Home player INL port (nothing listening now) 4577 TCP Away player INL port (nothing listening now) 4000 TCP Home observer INL port (nothing listening now) 5000 TCP Away observer INL port (nothing listening now) 3333 UDP Netrek Player 0 .. 3348 UDP Netrek Player 15 (observers should be able to live on TCP only. tired of typing) When typing this I just realized that running both INL as pickup will bring myself in problems using this scheme... Ahh well. Fixing that later ;-) Also I have not yet looked into the RSA stuff yet. The ideal solution I would like to have implemented is every client using one and the same UDP port, namely 2592. That portnumber is no nicely reserved for netrek. Clients should send PDU's with an additional 4 byte, server assigned ID which the server uses to distribute stuff among daemonII processes. Relying on source ip address won't be sufficient in all cases. I know it will be hard and there will probably be pitfalls, but i'm bored and like to try. So I ask you vanilla veterans: is there any reason I should not do this? Greetx, Erik David Watson wrote: > > If you are doing NAT then you have to disable RSA, I havnt looked > into that... > > iptables rules are below, you should be able to grab ports from them. > > My servers fail to contact the metaservers > > > the server must be able to do dns (udp and tcp 53) auth (tcp 113) and > whatever game ports that you run on. not my forwarding rule actually > allow all ports over 1024 in an attempt to get metaserver working > (possibly incoming udp connections 1024 + needed for portswap?). These > rules were under construction when I decided - good enough > > Dave > > $IPTABLES -N verify_netrekout_for > $IPTABLES -N verify_netrekin_for > > # Allow serving of game server ports to world > > $IPTABLES -A verify_netrekout_for -p TCP --sport 113 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p TCP --sport 2592 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 2592 -j ACCEPT > $IPTABLES -A verify_netrekout_for -p TCP --sport 2593 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 2593 -j ACCEPT > $IPTABLES -A verify_netrekout_for -p TCP --sport 4566 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 4566 -j ACCEPT > $IPTABLES -A verify_netrekout_for -p TCP --sport 4577 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 4577 -j ACCEPT > $IPTABLES -A verify_netrekout_for -p TCP --sport 4000 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 4000 -j ACCEPT > $IPTABLES -A verify_netrekout_for -p TCP --sport 5000 -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --sport 5000 -j ACCEPT > > # Metaserver and client verification > > $IPTABLES -A verify_netrekout_for -p TCP --dport 1024: -j tcp_verify > $IPTABLES -A verify_netrekout_for -p UDP --dport 1024: -j ACCEPT > > > # Allow serving of game server ports to world > > $IPTABLES -A verify_netrekin_for -p TCP --dport 113 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p TCP --dport 2592 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 2592 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --dport 2593 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 2593 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --dport 4566 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 4566 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --dport 4577 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 4577 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --dport 4000 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 4000 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --dport 5000 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --dport 5000 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p UDP --dport 1024: -j ACCEPT > > # Metaserver > > $IPTABLES -A verify_netrekin_for -p TCP --sport 3521 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --sport 3521 -j ACCEPT > $IPTABLES -A verify_netrekin_for -p TCP --sport 3530 -j tcp_verify > $IPTABLES -A verify_netrekin_for -p UDP --sport 3530 -j ACCEPT > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Wed Jun 25 05:54:14 2003 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:45 2005 Subject: [Vanilla Devel] Firewalling a netrek server In-Reply-To: <3EF89C71.60104@netrek.org> References: <5.2.0.9.0.20030514163201.024edeb8@mailgate.team17.com> <3EF89C71.60104@netrek.org> Message-ID: <20030625105414.GK14329@us.netrek.org> On Tue, Jun 24, 2003 at 08:46:09PM +0200, E. Hietbrink wrote: > Also I have not yet looked into the RSA stuff yet. I thought the RSA client verification used IP addresses as part of the exchange, in order to prevent man in the middle "attacks". > The ideal solution I would like to have implemented is every client using > one and the same UDP port, namely 2592. That portnumber is no nicely > reserved for netrek. Clients should send PDU's with an additional 4 byte, > server assigned ID which the server uses to distribute stuff among daemonII > processes. Relying on source ip address won't be sufficient in all cases. ipv6 is a far better solution than NAT. Why not support build PPTP into the server and the client and just run GRE? ;-) The Netrek protocol was designed in the days when ipv4 was sufficient. > I know it will be hard and there will probably be pitfalls, but i'm bored > and like to try. So I ask you vanilla veterans: is there any reason I > should not do this? No reasons in particular. I'll merge anything with the main code base if it is useful and doesn't hurt comprehension of the code. Of course, I'd be much more enthusiastic if you were doing client side GUI usability and acceptability (eye candy) improvements. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From ahn at orion.netrek.org Tue Jun 17 22:43:51 2003 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] genocide.netrek.org services down Message-ID: <20030618034351.GA28512@orion.netrek.org> Hi, It appears that genocide.netrek.org has been compromised. Some netrek services may be unavailable while this problem is corrected. The lists.netrek.org and ftp.netrek.org resources should remain unaffected. Sorry for the inconvenience. Dave _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From msucka0xff at programmer.net Mon Jun 23 11:57:20 2003 From: msucka0xff at programmer.net (Sos Yer Mom) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] curses.h Message-ID: <20030623165721.8450.qmail@mail.com> when compiling vanila-2.9pl8 under debian linux, i get: showgalaxy.c:16: curses.h: no such file or direcotry needs curses.. im searching thanks (also on netrek channel) thanks, -jay -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From msucka0xff at programmer.net Mon Jun 23 14:08:25 2003 From: msucka0xff at programmer.net (Sos Yer Mom) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] Fw: Re: How to save netrek Message-ID: <20030623190825.114.qmail@mail.com> the solution to ncurses on debian: apt-get install libncurses5 libncurses5-dev Note: forwarded message attached. ----- Original Message ----- From: "E. Hietbrink" Date: Mon, 23 Jun 2003 20:40:09 +0200 To: sosyermom Subject: Re: How to save netrek -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers -------------- next part -------------- An embedded message was scrubbed... From: "E. Hietbrink" Subject: Re: How to save netrek Date: Mon, 23 Jun 2003 20:40:09 +0200 Size: 2291 Url: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20030623/d43d8ee0/attachment.mht From quozl at us.netrek.org Mon Jun 23 17:44:22 2003 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] curses.h In-Reply-To: <20030623165721.8450.qmail@mail.com> References: <20030623165721.8450.qmail@mail.com> Message-ID: <20030623224422.GA14329@us.netrek.org> On Mon, Jun 23, 2003 at 11:57:20AM -0500, Sos Yer Mom wrote: > when compiling vanila-2.9pl8 under debian linux, i get: > showgalaxy.c:16: curses.h: no such file or direcotry > needs curses.. im searching thanks (also on netrek channel) libncurses5-dev. You may need package gmp too, for RSA. Not sure what the current package name is on sarge. showgalaxy isn't exactly necessary. Remove it if you're in a hurry. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From msucka0xff at programmer.net Sun Jun 29 15:27:19 2003 From: msucka0xff at programmer.net (Sos Yer Mom) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] beginning client communication with the server Message-ID: <20030629202719.52157.qmail@mail.com> Hi I am working on creating a java netrek observer. I am able to connect to the server by opening a socket from the applet using the following code: void loadRecording() { ... try { InputStream ins; /* jsc */ stat.setText("Waiting for packet data..."); redraw(); if ( is_socket == true ) { /* recording is a server name */ // thus open the observer socket and start collecting packets String SERVER_HOST_IP = "192.1.1.128"; java.net.SocketPermission p1 = new SocketPermission(SERVER_HOST_IP+":2593", "connect,accept"); Socket s = new Socket(SERVER_HOST_IP, 2593); ins = s.getInputStream(); } else { ... } ...} At this point the socket is open and the input stream has been returned. What client/server, server/client communications needs to happen to get the client authenticated and such? Which vanilla server source code should i investigate ? Thanks, -Jay -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From msucka0xff at programmer.net Sun Jun 29 17:57:24 2003 From: msucka0xff at programmer.net (Sos Yer Mom) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] Re: beginning client communication with the server Message-ID: <20030629225724.30322.qmail@mail.com> ive expanded my code to do the following: if ( is_socket == true ) { /* recording is a server name */ // thus open the observer socket and start collecting packets String SERVER_HOST_IP = "192.1.1.128"; String S_PORT = "2593"; int PORT = 2593; java.net.SocketPermission p1 = new SocketPermission(SERVER_HOST_IP+":"+S_PORT, "connect,accept"); Socket s = new Socket(SERVER_HOST_IP, PORT); // DatagramSocket ds = new DatagramSocket(int port, InetAddress laddr); ins = s.getInputStream(); ous = s.getOutputStream(); int SOCKVERSION = 4; ous.write(SOCKVERSION); } server has responded with the following entries in the log files: logfile: Died while waiting for packet... ERRORS : 1a) read() failed (1, error 38) ntserv/main.c: disconnect waiting for version packet from 192.1.1.1 I am looking at sheldon's client socket.c and the server's socket.c files to determine what bits must be sent to get the packet stream moving. -jay -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From vanillatrek at yahoo.com Mon Jun 30 17:32:34 2003 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] Re: beginning client communication with the server In-Reply-To: <20030629225724.30322.qmail@mail.com> Message-ID: <20030630223234.5092.qmail@web21110.mail.yahoo.com> --- Sos Yer Mom wrote: > > I am looking at sheldon's client socket.c and the Hey Jay, http://sodablue.org/Netrek/Client/Downloads/NetrekXPsrc-Final.zip > server's socket.c files to determine what bits must be > sent to get the packet stream moving. http://vanilla.netrek.org/Vanilla-2.9pl8.tar.gz Will you make your code publicly available when it's done? Why not start a sourceforge.net project to get more people helping? Zach __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From Shadow.Hunter at netrek.org Mon Jun 23 11:19:49 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? Message-ID: <3EF728A5.3030601@netrek.org> Hi ppl, I was wondering if the source of the metaserver is available somewhere (probably yes ;-) so I can take a look how new netrek servers are listed. Or someone could of course explain me why for instance: nl.netrek.org alias shadowhunter.org will not show up in the list. What ports must be opened and what checks are done before it is added to the list? Greetx, Erik _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From unbelver at us.netrek.org Mon Jun 23 14:57:22 2003 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? In-Reply-To: <3EF728A5.3030601@netrek.org> References: <3EF728A5.3030601@netrek.org> Message-ID: <20030623195722.GA4153@brain.jpl.nasa.gov> Quoting E. Hietbrink : > I was wondering if the source of the metaserver is available somewhere > (probably yes ;-) I haven't checked, but it should be on ftp://ftp.netrek.org/pub/netrek somewhere. > What ports must be opened and what checks are done before it is > added to the list? If a random player can get to the list, so can the metaserver. There are two ways to get on the list. 1) You ask us to put you on the list, and we edit our config files. 2) Your netrek server itself adds itself to the lists through a process called metaserver solicitation. In the docs directory on your server, look at the file called sample_metaservers and make a file called .metaservers in the netrek root directory. --Carlos V. _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From Shadow.Hunter at netrek.org Mon Jun 23 15:27:05 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> no Src found In-Reply-To: <20030623195722.GA4153@brain.jpl.nasa.gov> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> Message-ID: <3EF76299.1090209@netrek.org> >>I was wondering if the source of the metaserver is available somewhere >>(probably yes ;-) > > > I haven't checked, but it should be on ftp://ftp.netrek.org/pub/netrek > somewhere. I just walked the entire tree again and could not find it. Maybe i'm blind... >>What ports must be opened and what checks are done before it is >>added to the list? > > > If a random player can get to the list, so can the metaserver. I dont quite understand this statement?! Dou you mean the metaserver attempts to contact my server at TCP port 2591 to request a list of current players? It should be able to do that... > There are two ways to get on the list. > > 1) You ask us to put you on the list, and we edit our config files. ;-) of course. I'd like to ask for nl.netrek.org to be added, but first I am curious what makes the automates setup fail. David Watson (Volcane) also wondered why eurotwinks.netrek.org didn't get listed a while ago, so it is not just my server. > 2) Your netrek server itself adds itself to the lists through a > process called metaserver solicitation. In the docs directory > on your server, look at the file called sample_metaservers and > make a file called .metaservers in the netrek root directory. The file existed and was filled in according to the given example: ehb > cat /usr/local/netrek/.metaservers metaserver.us.netrek.org 3521 60 120 nl.netrek.org B 2592 2593 open metaserver2.us.netrek.org 3521 60 120 nl.netrek.org B 2592 2593 open metaserver.eu.netrek.org 3521 60 120 nl.netrek.org B 2592 2593 open I'm running Vanilla-2.9pl8 on Sparc64 NetBSD 1.6.1. What I wanted to check in the metaserver code was if maybe it does a DNS lookup and checks that against the given server address? In my case that would fail since it yields different results: ehb > nslookup nl.netrek.org Non-authoritative answer: Name: www.shadowhunter.org Address: 62.21.236.245 Aliases: nl.netrek.org ehb > nslookup 62.21.236.245 Name: 062-021-236-245.ADSL-ECON.PN.NL Address: 62.21.236.245 Help me out here plz. Greetx, Erik _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From unbelver at us.netrek.org Mon Jun 23 19:16:06 2003 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> no Src found In-Reply-To: <3EF76299.1090209@netrek.org> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> Message-ID: <20030624001606.GA5241@brain.jpl.nasa.gov> Quoting E. Hietbrink : > >I haven't checked, but it should be on ftp://ftp.netrek.org/pub/netrek > >somewhere. > > I just walked the entire tree again and could not find it. Maybe i'm > blind... I can't seem to find it either. I'll put a copy in /incoming for Dave to place somewhere > >If a random player can get to the list, so can the metaserver. > > I dont quite understand this statement?! Dou you mean the metaserver > attempts to contact my server at TCP port 2591 to request a list of > current players? It should be able to do that... In non-solicit mode, yes it does. And if that doesn't work, it will actually connect as a player on 2592 to get the player list. In solicit mode, the netrek server will send a single UDP packet to the normal metaserver port (3521). > ;-) of course. I'd like to ask for nl.netrek.org to be added, but first > I am curious what makes the automates setup fail. David Watson (Volcane) > also wondered why eurotwinks.netrek.org didn't get listed a while ago, > so it is not just my server. No clue. I could do a metaserver log and a tcpdump log to find out if stuff is getting to my sever to begin with. Let us know when you want it added. > metaserver.eu.netrek.org 3521 60 120 nl.netrek.org B 2592 2593 open He doesn't exist anymore. --Carlos V. _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From Shadow.Hunter at netrek.org Tue Jun 24 06:44:42 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> no Src found In-Reply-To: <20030624001606.GA5241@brain.jpl.nasa.gov> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> <20030624001606.GA5241@brain.jpl.nasa.gov> Message-ID: <3EF839AA.4050900@netrek.org> Carlos Y. Villalpando wrote: >>;-) of course. I'd like to ask for nl.netrek.org to be added, but first >>I am curious what makes the automates setup fail. David Watson (Volcane) >>also wondered why eurotwinks.netrek.org didn't get listed a while ago, >>so it is not just my server. > > > No clue. I could do a metaserver log and a tcpdump log to find out if > stuff is getting to my sever to begin with. > > Let us know when you want it added. Small update. I now know what makes it fail. Now I still need to fix it. What I did: First checked if I didn't see any PDUs sent out to any metaserver. Nothing. Then I started checking the file ERRORS. Ahum. Should have done that sooner ;-) I got loads and loads of these two types of messages: solicit: udp_attach: unable to bind to desired interface (this.host.name field): Can't assign requested address solicit: udp_tx: sendto: Can't assign requested address Closer investigation and debugging in solicit.c reveals that somehow the calls to gethostbyname(m->ours) and gethostbyname(m->host) return garbage. Wierd. This I need to look into. I got all working by filling in the IP addresses of both my server as the metaservers in the file .metaservers. I saw myself getting listed. Apparently it's a local problem for me. Will work on fixing it. However I did see another thing. Namely I run the server on a box behind a NAT firewall. So my internal addresses won't be the same as the call to gethostbyname("nl.netrek.org") returns. As a result the bind() call will fail with (errno = 49 = EADDRNOTAVAIL) and the automated registration will still fail. Is the bind() call really necessary? What if the server simply sends the raw announcement PDU. Does the metaserver run a check on sender address with the DNS-lookup-result of the reported serveraddress? That would still make it `failsafe'. Greetx, Erik _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From Shadow.Hunter at netrek.org Tue Jun 24 10:22:04 2003 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> 64bit issue In-Reply-To: <3EF839AA.4050900@netrek.org> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> <20030624001606.GA5241@brain.jpl.nasa.gov> <3EF839AA.4050900@netrek.org> Message-ID: <3EF86C9C.6010307@netrek.org> E. Hietbrink wrote: > Carlos Y. Villalpando wrote: > >>> ;-) of course. I'd like to ask for nl.netrek.org to be added, but first >>> I am curious what makes the automates setup fail. David Watson (Volcane) >>> also wondered why eurotwinks.netrek.org didn't get listed a while ago, >>> so it is not just my server. >> >> No clue. I could do a metaserver log and a tcpdump log to find out if >> stuff is getting to my sever to begin with. >> >> Let us know when you want it added. > > Small update. I now know what makes it fail. Now I still need to fix it. > > What I did: First checked if I didn't see any PDUs sent out to any > metaserver. Nothing. Then I started checking the file ERRORS. Ahum. > Should have done that sooner ;-) I got loads and loads of these two > types of messages: > > solicit: udp_attach: unable to bind to desired interface > (this.host.name field): Can't assign requested address > solicit: udp_tx: sendto: Can't assign requested address > > Closer investigation and debugging in solicit.c reveals that somehow > the calls to gethostbyname(m->ours) and gethostbyname(m->host) return > garbage. Wierd. This I need to look into. I seem to have a 64-bit problem. I run a Sun UltraSparc with NetBSD and the Vanilla server code isn't 64-bit safe. Example: changing the pointer copy in solicit.c from: m->address.sin_addr.s_addr = *(long *) hp->h_addr; to: ((char *)&(m->address.sin_addr.s_addr))[0] = hp->h_addr[0]; ((char *)&(m->address.sin_addr.s_addr))[1] = hp->h_addr[1]; ((char *)&(m->address.sin_addr.s_addr))[2] = hp->h_addr[2]; ((char *)&(m->address.sin_addr.s_addr))[3] = hp->h_addr[3]; solved my gethostbyname() issue. I think the ultrasparc is capable of running both 64 as 32 bit binairies concurrently, however I haven't found any compiler flag to enforce 32bit compiles. What's the procedure to follow here? Make the entire server 64-bit safe? > I did see another thing. Namely I run the server on a box behind a > NAT firewall. So my internal addresses won't be the same as the call to > gethostbyname("nl.netrek.org") returns. As a result the bind() call will > fail with (errno = 49 = EADDRNOTAVAIL) and the automated registration > will still fail. > > Is the bind() call really necessary? What if the server simply sends > the raw announcement PDU. Does the metaserver run a check on sender > address with the DNS-lookup-result of the reported serveraddress? That > would still make it `failsafe'. At the moment i'm running with the bind call deleted. Greetx, Erik _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From ahn at orion.netrek.org Tue Jun 24 14:38:13 2003 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> no Src found In-Reply-To: <20030624001606.GA5241@brain.jpl.nasa.gov> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> <20030624001606.GA5241@brain.jpl.nasa.gov> Message-ID: <20030624193813.GA11925@orion.netrek.org> On Mon, Jun 23, 2003 at 05:16:06PM -0700, Carlos Y. Villalpando wrote: > > I can't seem to find it either. I'll put a copy in /incoming for Dave > to place somewhere ftp.netrek.org/pub/netrek/servers/metaserver/ _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From quozl at us.netrek.org Wed Jun 25 05:40:23 2003 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:53:25 2005 Subject: [META] What makes the metaserver tick? -> no Src found In-Reply-To: <3EF839AA.4050900@netrek.org> References: <3EF728A5.3030601@netrek.org> <20030623195722.GA4153@brain.jpl.nasa.gov> <3EF76299.1090209@netrek.org> <20030624001606.GA5241@brain.jpl.nasa.gov> <3EF839AA.4050900@netrek.org> Message-ID: <20030625104023.GJ14329@us.netrek.org> On Tue, Jun 24, 2003 at 01:44:42PM +0200, E. Hietbrink wrote: > Is the bind() call really necessary? What if the server simply sends > the raw announcement PDU. Does the metaserver run a check on sender > address with the DNS-lookup-result of the reported serveraddress? That > would still make it `failsafe'. The bind() call was added to support multiple IPs on a single Netrek server, and it wasn't in the code I wrote originally. The metaserver notes the IP address that the packet came from (in your case, the NAT external interface IP) and the name that is in the host name field (which comes from your server's .metaservers file). The relevant code is scan.c uread(). I don't believe the metaserver checks the IP address against the host name provided; it uses the IP address to merge further updates from the same server. The host name is what is sent out to a client request, either by TCP or UDP. The IP address is not sent. This is so that the server owner has full control over where clients are directed. The relevant code is disp_udp.c display_udp(). -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From shawn at rhoads.com Thu Jun 5 16:49:40 2003 From: shawn at rhoads.com (Shawn Rhoads) Date: Wed Jan 12 00:53:25 2005 Subject: [META] RSA Key Access Message-ID: <3EDFBAF4.4080604@rhoads.com> Shawn Howard Rhoads US Citizen I agree. I agree. I agree. This file is located at ** Netrek RES-RSA This information and agreement is relevant only to U.S. Netrek client developers/builders and Netrek server developers/administrators. Many Netrek servers are RSA-enabled and require special RSA-enabled "blessed" client binaries for gameplay. This requirement prevents players from downloading a client's source code and adding special "borgish" features (such as auto- phasers, cloakers on tactical, etc.) to gain unfair advantages over others. Both clients and servers use the RSA algorithm from RSA Laboratories to employ public key cryptography for client validation. You will need access to the Netrek RES-RSA source code only if you plan to run an RSA-enabled server or build an RSA-enabled client. If you are building a client, please be sure to check with the client maintainer(s) to see if a blessed client for your platform is already available. Because of U.S. export restrictions on encryption technology, you must truthfully answer the following questions before a copy of the Netrek RES-RSA library can be released to you. - State your full, legal name. - Are you a citizen or national of the United States or a person who has been lawfully admitted for permanent residence in the United States under the Immigration and Naturalization Act? - Do you agree not to export RSA and all related support code to the extent incorporated therein, in violation of the export control laws of the United States of America as implemented by the United States Department of State Office of Defense Trade Controls? - Do you agree to the terms and conditions of the RSAREF license? - Do you agree to use Netrek RES-RSA and RSAREF solely for non-commercial purposes? Send a copy of this file with your answers to rsakey@us.netrek.org. If you are a PGP user, sign the message and include your public key. The decrypt key for the U.S. RES-RSA package will be sent to you afterwards. The encrypted U.S. RES-RSA package is located at . If you are trying to build an RSA-enabled client, please check with the client maintainers for additional information. RSA-enabled clients not sanctioned by the maintainers are usually rejected by the RSA client keys maintainer and RSA-enabled servers. -da 3/25/99 _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From ahn at orion.netrek.org Mon Jun 16 19:18:00 2003 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:53:25 2005 Subject: [META] RSA Key Access In-Reply-To: <3EDFBAF4.4080604@rhoads.com> References: <3EDFBAF4.4080604@rhoads.com> Message-ID: <20030617001800.GA20731@orion.netrek.org> You don't need to do this anymore. A version of RES-RSA has been released after the relaxing of U.S. export restrictions. Just download the RES-RSA package directly from http://ftp.netrek.org/pub/netrek/ On Thu, Jun 05, 2003 at 04:49:40PM -0500, Shawn Rhoads wrote: > Shawn Howard Rhoads > US Citizen > I agree. > I agree. > I agree. > > This file is located at > > ** Netrek RES-RSA > > This information and agreement is relevant only to U.S. Netrek client > developers/builders and Netrek server developers/administrators. > > Many Netrek servers are RSA-enabled and require special RSA-enabled > "blessed" client binaries for gameplay. This requirement prevents > players from downloading a client's source code and adding special > "borgish" features (such as auto- phasers, cloakers on tactical, etc.) > to gain unfair advantages over others. > > Both clients and servers use the RSA algorithm from RSA Laboratories > to employ public key cryptography for client validation. You will > need access to the Netrek RES-RSA source code only if you plan to run > an RSA-enabled server or build an RSA-enabled client. If you are > building a client, please be sure to check with the client > maintainer(s) to see if a blessed client for your platform is already > available. > > Because of U.S. export restrictions on encryption technology, you must > truthfully answer the following questions before a copy of the Netrek > RES-RSA library can be released to you. > > - State your full, legal name. > > - Are you a citizen or national of the United States or a person who > has been lawfully admitted for permanent residence in the United > States under the Immigration and Naturalization Act? > > - Do you agree not to export RSA and all related support code to the > extent incorporated therein, in violation of the export control laws > of the United States of America as implemented by the United States > Department of State Office of Defense Trade Controls? > > - Do you agree to the terms and conditions of the RSAREF license? > > > - Do you agree to use Netrek RES-RSA and RSAREF solely for > non-commercial purposes? > > Send a copy of this file with your answers to rsakey@us.netrek.org. > If you are a PGP user, sign the message and include your public key. > The decrypt key for the U.S. RES-RSA package will be sent to you > afterwards. The encrypted U.S. RES-RSA package is located at > . > > If you are trying to build an RSA-enabled client, please check with > the client maintainers for additional information. RSA-enabled > clients not sanctioned by the maintainers are usually rejected by the > RSA client keys maintainer and RSA-enabled servers. > > -da 3/25/99 > > > > _______________________________________________ > vanilla-metaserver mailing list > vanilla-metaserver@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver