Re: [hlds_linux] Multi-homed breaks steam?
[BT]Black V wrote: I have to disagree with that statement I have several machines behind a double nat And they get steam auth fine Your statement does not colide with my statement. Servers have no problem with NAT, the client has if the server connecting to is on the same network. But what im not too sure on a couple of points 1.is the hlds server and the client on the same network ? Yes it is. 2.Is the server in lan mode or inet mode (sv_lan 1/0 nomaster etc) I would say inet mode like ours, IMHO in lan mode not all people from the inet could connect to the server otherwise. Afterall it was like that in cs1.5 and I don't think steam would be that different. Cheers, Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Multi-homed breaks steam?
m0gely wrote: Mad Scientist wrote: Hmmm... probably not. It is an Internet server... Anyhow, worth a try, I will pass that suggestion on. Basically you mean your server is publicly accessible and users are authenticating to Steam to play on it. Users can still authenticate to Steam playing a LAN game. Thats how you need to do it. My server at work is set up the same way. sv_lan is set to 0 and people from the net connect to it via Internet games, everyone at my connects via LAN games. Everyone has a steamid, everyone is happy. :) Interesting, I will try it. Since our SNAT solution was build befor the LAN game come up. Probably it is now easier with the LAN mode. Thx any way, Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Multi-homed breaks steam?
Mad Scientist wrote: According to the great words of Frank Stollar: Another admin wrote an User-space SNAT Proxy running on the server, the server will see the clients fake outside IP and the Steam Ticket is valid for the people now. Any idea where I can find this? As this special solution was coded by an admin of our servers and a good friend of mine. As this is a very special solution because the masq for 2500 clients use dynamical ip allocation per user. Therefor the SNAT proxy on the server querries the masq via a module which extern IP that specific client has and maps that IP as SNAT to the pakets send to the server. The next problem was that this SNAT Proxy has to be implemented in user-space and not kernel-space. If you wish, I can get you his email address, he would surely public his code under the GPL. This may be helpful for other people but surly it must be rewritten to their personal needs. And if you use a plain NAT that would be overkill, as iptables has better method of static SNAT translation as Marques already pointed out. But he is wrong as POSTROUTING is no solution at all, because the pakets must be altered _before_ they reach your server. PREROUTING would be the right chain. But SNAT does not work in the PREROUTING chain :-/ To circumvent that behaviour you must set up another pseudo interface and route your internal traffic through that interface. Then you can use POSTROUTING on that pseudo interface and get SNAT working. Well, indeed that is somehow the same procedure as the user-space SNAT is working, but without the overkill of dynamic IP NAT. Hope I enlighted you, Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Update feature request
Frash wrote: For the server update I'd like to request 2 things: 1) A referer: header containing the server IP address, professional webmasters can grant access to files by referer (More important than you think, other servers can get your bandwidth down by leeching/sniffing the downloadurl) 2) A fully working banner (To get sponsoring webhosts) I second that! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Re: steam update - Broken Server :(
Jay Carter wrote: After the update, my server is not starting. Has anyone else experienced this? The server starts up, looks like everything is working fine but doesn't show up on HLSW and doesn't accept console commands. The update is not finished yet. Please look at http://www.steampowered.com or http://www.steampowered.com/status/status.html first. Thank you! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Steam hlds: sv_downloadurl ?
ruwen wrote: Am I too stupid or did it not work under cs 1.5? It was introduced with the new Steam update though. As 1.5 is not using Steam it could not be updated and therefor it could not work :) If you read all posting about this subject you should have known this already... Cheers, Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] 5 reasons i'm shutting down my HL Servers
Brett Fernicola wrote: I never once claimed to have 0% cpu ususage. You guys are truely dumb and try so hard to find fault in my posts. I was trying to illustrate the fps of my server not my cpu usuage which always shows 0% with hlsw you dumb noobs, this is also why I included a screen shot of top. I wasnt even going to respond to your dumb statements but your just pissing me off too much. [ ] The word netiquette is something I know of. And your statements about 'You guys have to much friggin hardware and not enough linux expierence' doesn't explain at all, why on the same machine are runngin 5x16slot CS1.5 without a glitch but 2x12 CS1.6 have a normal load of 0.6 and spikes of 1.2, laggs and so on. Befor calling somebody dump and of not enough linux experience, you should first explain that friggin behaviour. We tried all we knew and read of, but nothing did really help. Just replacing the cpu with a 512 L2-cache core does help. And therefor I call 1.6 bad software, as a new version bringing no new enhancements serversides is x2-x5 more CPU hungry on the same hardware. It is a fucking _update_ and no new game! An update implified to me a enhancement and no step back. If you call yourself so 'linux experienced' than you can surly tell me how to get 2 CS1.6 server with 12 slots running lagfree on a XP2000+ when full. At this time 6 different people with deep linux and hardware knowledge tried there fortune but nobody solved it. Only a Barton core solved it easily and that's not ok to me. Valve, do someting! Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] 5 reasons i'm shutting down my HL Servers
dual_bereta_r0x wrote: the sad truth The same here. Since the 3.1.1.1 servers I get pissed cause of the bad performance. And since the release of Steam our XP2000+ in not capable anymore of a fluid gameplay for 2 servers. That's not only bad that's disgusting. Besides the point that 3.1.1.1 does not bring any new enhancements for a server regarding the increase in cpu load. With Steam it just got worse. Not to mention the problems and bugs on the client side. As we are trying new hardware (Barton core Athlons seem to be much better performing with steam servers than Palomino cores) we are giving MoHAA, BF1942 and Tribes2 a shot. They perform much better, are also full most of the time and there are less known problems. For the long run we will decrease the HL Servers, because of the immens cost for new hardware they are needing. Myself I would drop HL completly because of the bad support regarding the performance hit since 3.1.1.1 and valve ignoring the bitching. Any other server is performing better. Some 1/2 some 1/5 of CPU load for the same amount of slots used. Best example is Tribes2, it is real cpu friendly. If there will be no update in the near future fixing this problem, there will be no CS server anymore hosted by us. It's too expensive. That's it, flames on Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] 2.6.0-test9-bk6 16 players 90fps 38% usage
Simon Garner wrote: On Friday, November 07, 2003 4:42 AM NZT, Brett Fernicola [EMAIL PROTECTED] wrote: Im pinging 250 on your server from a t3, thats not good no matter where its at in the world. Hmm, well, considering he's in Australia and you're (presumably) in the USA... the speed of light becomes a little bit of a nuisance. 250ms is pretty good considering. I ping it at 35ms here. Throwing another piece in the bowl, I got an average ping of 340ms from Munich/Germany with a 100Mbit fiberline. Well, conisdering the Inet connection to australia is not very good from germany but more surprising is the 75% packet loss. The Traceroute is also interesting: 1: gateway.fs.ei.tum.de (129.187.54.254) 2.593ms 2: csrwan-neu.lrz-muenchen.de (129.187.1.8) 2.409ms 3: csrwan.lrz-muenchen.de (129.187.9.17) 8.730ms 4: ar-muenchen1-po2-0.g-win.dfn.de (188.1.37.13) 4.481ms 5: cr-muenchen1-ge0-0.g-win.dfn.de (188.1.74.1) 2.672ms 6: cr-leipzig1-po9-3.g-win.dfn.de (188.1.18.210)asymm 8 17.299ms 7: cr-frankfurt1-po10-0.g-win.dfn.de (188.1.18.189) 18.533ms 8: so-6-0-0.ar2.FRA2.gblx.net (208.48.23.141) asymm 9 15.816ms 9: pos5-0-2488M.cr2.FRA2.gblx.net (67.17.65.53) 15.663ms 10: so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38)asymm 13 40.156ms 11: so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30)asymm 13 40.253ms 12: sl-bb21-lon-1-3.sprintlink.net (213.206.131.25) asymm 16 39.790ms 13: sl-bb23-lon-14-0.sprintlink.net (213.206.128.54) asymm 17 39.839ms 14: sl-bb22-lon-15-0.sprintlink.net (213.206.128.160)asymm 16 39.733ms 15: sl-bb20-nyc-2-0.sprintlink.net (144.232.9.163) asymm 14 103.717ms 16: sl-bb26-nyc-6-0.sprintlink.net (144.232.13.9)asymm 15 103.655ms 17: sl-bb23-pen-12-0.sprintlink.net (144.232.20.95) asymm 16 107.063ms 18: sl-bb20-pen-14-0.sprintlink.net (144.232.16.25) asymm 17 106.807ms 19: sl-bb20-stk-10-0.sprintlink.net (144.232.18.46) asymm 18 167.150ms 20: sl-bb20-sj-9-0.sprintlink.net (144.232.20.99)asymm 19 167.903ms 21: sl-st20-pa-15-0.sprintlink.net (144.232.9.4) asymm 20 168.553ms 22: sl-newzeal-1-0.sprintlink.net (144.223.243.18) 175.558ms 23: p5-1.sjbr1.global-gateway.net.nz (202.37.245.229)asymm 24 324.047ms 24: p1-5.sybr3.global-gateway.net.nz (202.37.247.81) asymm 23 323.277ms 25: connect4.sybr3.global-gateway.net.nz (202.37.245.210) 323.789ms 26: so-0-3-0.cre1.syd.connect.com.au (202.10.4.11) 318.845ms 27: so-1-0-0.cre1.can.connect.com.au (202.10.0.36) 325.962ms 28: so-0-0-0.cre2.can.connect.com.au (202.10.0.95) asymm 29 324.465ms 29: pos5-1-0.bdr1.can.connect.com.au (202.10.4.54) 327.079ms 30: fastethernet0-0.cor1.can.connect.com.au (203.63.113.49) asymm 29 330.437ms 31: 203.63.214.17 (203.63.214.17)332.145ms The pakets are really going a long way from London over New York and New Zealand. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] MY Response to CPU Usage -- Test Result Database
Very nice indeed! Hope you will not bite my for adding a few ideas: - What should be added is if you are VAC running or not. - Possability to add server-fps and CPU load for old server 3.1.1.0 and 3.1.1.1 to compare with. - Should I add the same machine multiple times for different configurations/kernels ? I will add myself as I looked more closly in my box. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Crazy Usage
[EMAIL PROTECTED] wrote: I am telling you, and PROVING to you, that using this kernel, with DEFAULT kernel timings results in performance vastly superior to any kernel released after. When we all know it is just impossible for the 1% you quote to be true. I fully ACK Jeremy. This is not possible, no way. The new VM started with 2.4.10 was (after some bugs) superior as the old VM. Proved by application benchmarks. And the new scheduler in 2.6. adds even more power to the kernel. Why should all other applications gain from the new VM besides HL? Indeed why should a kernel which only 'manages' the ressources be guilty for a userspace programm needing 1/10 of the CPU Power. The calculations done by hlds are done the same way, with 2.4.9 or 2.4.22. And HLDS is no high-stress program like a database with 100 nodes and a few 10xgig of data. Why should the hlds do its calculations 10 times faster with a differnet kernel, just saying 'ho you can now have some CPU power' and 'here is the memory you wanted'. Normaly the kernel does almost not need much CPU power but the user programms can have let's say ~95% of the CPU power. There may be a fault in the HLDS code, no other dedicated server around like Tribes2, Q3 and so on are needing that much CPU power from a server. Sometimes I whish I could have a look for optimizing the HLDS engine or VALVe would make it under the GPL or any other Licence as HL2 is approching the horizon. Also Steam is a nice idea and I would like it is a GPL project, many people can offer there knowledge and talents to it. If Steam would be open-sorce, nevertheless VALVe could use it as destribution for there very own products without a hassle, like other open-source online-shops projects. But I'm dreaming and going to far... With your numbers that should mean that you could add 50 16 player 24/7 iceworld server. Name them all 24/7 iceworld in the hostname and wait for them to fill up. Lets see your server lock up WAY before you ever get to those 800 concurrent players. Because with your match you could get all 800 on there and still have powere to spare. Well nothing to say about this. The numbers speak for themselfes. If that would be true, HLDS has a bigger problem as anybody ever expected. :) cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cstrike server for class A network
Alfred Reynolds wrote: The definition of LAN game has not changed. All clients that match the servers ip with netmask 255.255.255.0 are allowed into a LAN game. Sorry Alfred that's definitly not correct. We are running a few CS servers for a large dormitory in Munich with 2500+ users. As they are running with the IP 10.150.127.30 and sv_lan 1, all user with 10.x.x.x are able to join them. For example 10.149.x.x which is definitly no 255.255.255.0 mask. Please recheck your code. By the way, if you would change this to another behavior and regrett it to a Class C (new meaning), many large LANs cannot host a HL Server anymore like we do permanently. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cstrike server for class A network
Matthew Cheale wrote: Didn't they say that if you authed with Steam then LAN restrictions didn't apply? I'm talking about 3110c 3111d and new Steam version. All have this behavior, besides Steam does not support real offline LAN game till now. And as old versions like 3110c also does not restrict LAN game to Class C as said by Alfred, there is an error flowting around. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] hlds 3.1.1.0 fix for buffer-overrun exploit CAUTION:is not working !
Hi, I have no idea how this can happen to a server - if the patch got loaded it prevents anything beyond 255 characters from being passed to the original function. I'm guessing, since no one else is reporting crashes/hangs/overflows, that this isnt related to your patch. Frank, are you sure beyond a doubt? If the patch wasnt working, or was crashing servers, don't you think we would see more comments here? I *know* attacks stopped against my servers once i applied the patch. We have over a dozen servers using that patch on 3.1.1.0.c, all were tested after patching and none have went down since it was applied. I think Frank is doing something wrong. Watch your server output when you fire it up Frank, I forgot to put the .so file in the hlds_l dir on one of the servers I upgraded but caught the mistake when I saw it looking for the file on startup. Thank you for your answers. We are investigating further into it and will retry this test. To clear some questions: We wrote the line 'export LD_PRELOAD=./boffix_i386.so' into hlds_run in the halflife directory direct after the 'export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH' line. We copied boffix_i386.so in the hlds_l directory. It shows up when we fired up the server. The only difference could be, it was an LAN server we tried this. Dominic, I will contact you for further informations to this topic. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] hlds 3.1.1.0 fix for buffer-overrun exploit CAUTION:isnot working !
Frank Stollar wrote: Hi, I have no idea how this can happen to a server - if the patch got loaded it prevents anything beyond 255 characters from being passed to the original function. I'm guessing, since no one else is reporting crashes/hangs/overflows, that this isnt related to your patch. Frank, are you sure beyond a doubt? If the patch wasnt working, or was crashing servers, don't you think we would see more comments here? I *know* attacks stopped against my servers once i applied the patch. We have over a dozen servers using that patch on 3.1.1.0.c, all were tested after patching and none have went down since it was applied. I think Frank is doing something wrong. Watch your server output when you fire it up Frank, I forgot to put the .so file in the hlds_l dir on one of the servers I upgraded but caught the mistake when I saw it looking for the file on startup. Thank you for your answers. We are investigating further into it and will retry this test. Ok here we go. We just found the problem and it is persistent, but not as bad as supposed first. We tested it again at our LAN server and he was vulnerable again after 2 attacks. Ok, switching over to inet via 'sv_lan 0' and it works fluently. Hammered on the server with the exploit-tool but it was not going down. Switched back to lan with 'sv_lan 1' and after 2 attacks it goes to it knees. That would be no big problem for most of you, but I'm running LAN servers too, and I don't want it to be killed by a kiddy during a tournament or similiar. Therefor when the server is running in LAN mode, another function seems to be responsible for the exploit. I hope Dominic would take a look into this problem and could fix it. Thx go to Bernhard again for his help. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] problem with 3.1.1.1d???
JC | KrUCiaL | Gamerezo.com wrote: as you can see in this image the server runns for 40 seconds and seems to be down every 40 seconds for 20 seconds - but the server is NOT crashed - players are still connected and the have no lags or timeouts... Dowload lastest HLSW (v1.0.0-beta 3). Latest beta is v1.0.0-beta6 and I recommend to use it, as beta3 has many bugs already fixed in beta6. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] problem with 3.1.1.1d???
Eric (Deacon) wrote: Frank Stollar wrote: Funny, the internation side seems to be not up-to-date. As the developer is german, here the link from the german page (www.hlsw.de): ftp://ftp.hlsw.org/downloads/beta/hlsw_1_0_0_6-beta.exe Hmmm...so that's just the program executable, NOT an updated installer? HLSW is nothing more than a executable. Files missing will be generated by the first startup. I plugged it over beta3 and it works without a glitch. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Half-Life Primary Server x.1.1.1d Beta Release
Steven Hartland wrote: - Original Message - From: Frank Stollar [EMAIL PROTECTED] OMG! I can't believe there are admins sticking with older versions than 1.16!! Hitbox bug was awesome till this release. I did research on my own to discover it was metamod and not WWCL-tool to blame. I think he meant awful not awesome :P Indeed! 8-) Did I mention that english is not my native language? :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] hlds_amd 2 times for 1 server???
[EMAIL PROTECTED] wrote: hi, since i updated to hl 3.1.1.1c1 my server starts 2 hlds_amd processes??? why? is that correct? what does the 2nd one do? 9317 ?00:00:01 screen 9318 pts/300:01:14 halfd 9320 pts/301:19:35 hlds_amd 9338 pts/300:00:00 hlds_amd You are running C-D 4.1.0, right? This seems some 'bug' or 'misbehaviour' of C-D at the moment. I got myself extremly performance problems with the new release, besides the 'double process' bug or whatever. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Reporting Server Hackers
Florian Zschocke wrote: Frank Stollar wrote: Espacially this would be very hard if anywhere between two routers is no ethernet-link but ATM or any other Layer2 protocol. In no other Layer2 are ARPs present. Uhm, no. ARP is not restricted to Ethernet. As ATM hast no MAC adresses, ARP would not work. There you use ATMARP, similiar to ARP on ethernet. Ok these are also 'ARPs' but not that ARP we are reffering for spoofing. http://www.faqs.org/rfcs/rfc2225.html And also written in the first PDF document I refered: http://www.rootsecure.net/content/downloads/pdf_downloads/arp_spoofing_intro.pdf This paper deals with the subject of ARP spoofing. ARP spoofing is a method of exploiting the interaction of IP and Ethernet protocols. It is only applicable to Ethernet networks running IP. And as we talk about getting the MAC of a network card on the internet, which does not appear or travel through ATM except by Eth-over-ATM. Every network technologie hast something similiar to address resolution ARP, but they are not dealing with MAC addresses as ethernet does. As you can see, I refer ARP as 'ethernet ARP' as the most common situation. Sorry for the simple misunderstanding as I only talked about 'ethernet ARP' as we are taking about MAC addresses. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Reporting Server Hackers
Britt Priddy (PZGN) wrote: Ok - to clear the confusion - this is done by spoofing and placing yourself on that local segment - and you can obtain any MAC address you are able to connect to - note I pulled the MAC of the IP of the guy that asked me to look at it - this was done by sitting on his network with a spoofed packet to his game server and did an ARP Request. I'll just tell you its very possible and its done everyday - I do not feel its my place to tell someone how to 'hack' and/or spoof to gain access to a segment of a network to listen to the broadcasted traffic. You didn't answer my question! I was the guy asked you for the MAC of 141.84.69.34, and the MAC you gave me is definitly wrong! Read it again: As for your machine - I see SSH running that's pretty much it as far as anything I can connect to to establish an open connection. IP 141.84.69.34 = MAC = 00:09:b7:27:84:a0 Almost 99% UDP traffic is seen Look for yourself: bigbadaboom:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:00:CB:56:56:CC inet addr:10.150.127.30 Bcast:10.150.127.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:121311890 errors:1 dropped:0 overruns:0 frame:0 TX packets:99285661 errors:60 dropped:0 overruns:0 carrier:60 collisions:0 txqueuelen:100 RX bytes:2021109323 (1.8 GiB) TX bytes:1738254273 (1.6 GiB) Interrupt:10 Base address:0xc00 eth0:0Link encap:Ethernet HWaddr 00:00:CB:56:56:CC inet addr:141.84.69.34 Bcast:141.84.69.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:10 Base address:0xc00 As you can see is the HWaddr=MAC not the same you specified. The 99% UDP traffic is easy to guess, if you scan the machine for services and found a few CS servers running. This can be provided with nmap or similiar port scanners. Please explain why you told us a wrong MAC if this is foolproof? I can give you another example: 141.84.69.28, tell me the MAC of that machine. If you cannot give me the MAC of my machine, how will you than spoof my MAC at all? Or even sniff the traffic itself? You must give more evidence and argument to strenghten your position. If you are right, you should bring any proof with it. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Reporting Server Hackers
Florian Zschocke wrote: Britt Priddy (PZGN) wrote: LOL Florian - that is where I sit. (the spoofed packet):P LOL Britt - I'm not sure what you are trying to tell me. :) That MAC address is a Cisco MAC address and I am 95% sure that Frank doesn't have a NIC with a Cisco MAC address. So I guess I still didn't quite understand your method there, really. Oh, I can give you 100% :) For those not knowing what we talk about, the first 3 hex digits are dedicated to certain manufacturer. Here you can take a look: http://standards.ieee.org/regauth/oui/index.shtml Serching for cisco gave you besides many other entries this: 00-09-B7 (hex)Cisco Systems 0009B7 (base 16)Cisco Systems 80 West Tasman Dr. SJ-M/1 San Jose CA 94134 UNITED STATES Looking at the MAC Brit is providing 00:09:b7:27:84:a0 we can easily see that is the MAC of a CISCO product. Looking at the MAC of my NIC 00:00:CB:56:56:CC will reveal: 00-00-CB (hex)COMPU-SHACK ELECTRONIC GMBH CB (base 16)COMPU-SHACK ELECTRONIC GMBH RINGSTR. 56 - 58, 5450 NEUWIED WEST GERMANY This is correct, at they build this TULIP card build in. cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Reporting Server Hackers
Kevin J. Anderson wrote: I cant believe you guys are STILL talking about this... Hey, this is one of the best and most productive discussions since months :) SCNR Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New Security Modules -February 25
Tyler Overkill Schwend wrote: No, more info for us is fine. But the problem is, the cheaters can make better use of that information than we can. We don't really have any real dire need to know what is and isn't detected. Sure, in time everyone will know, but that doesn't mean we should go ahead and bust loose with it. Anyone who really wants to do crack is gonna do it eventually anyway, but that doesn't mean we should just go ahead and make it perfectly available :-) I am not sure why cheaters would make better use of this information when it will be puplic a few days later anyway. I don't say they should puplic the list along with the VAC update, but a few days/weeks, maybe months later. I try to imagine which use a cheater can make about an info several weeks old?!? I don't see any if I think hard about it. Am I not weird enought? You are right wo don't have any real dire about this, but if it don't harm, why not share? :) Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New Security Modules -February 25
Thomas J. Stensås wrote: The only problem is that the people being keept in the dark are the server admins. The cheaters already know what VAC detects and not, they cant make any real use of such an addition to logs as they are quite aware which cheat they where running to test if VAC caught it or not. I see you take the point. The cheater has no new info but the admin looking into the logfiles maybe days later, has no info at all. Why not save and share that info. I think cheaters have more use for this behavior than a server admin. Cheers Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New Security Modules -February 25
Thomas J. Stensås wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 February 2003 01:05, Frank Stollar wrote: I see you take the point. The cheater has no new info but the admin looking into the logfiles maybe days later, has no info at all. Why not save and share that info. I think cheaters have more use for this behavior than a server admin. Wrong, admins have no info, but cheaters already have the info. It takes approx 5 minutes from a new VAC module is released until most of the cheating community is spreading the news of which new cheats are being caught. snip Did I say something different? *g* Maybe my rusty bad english was not clear enough? :) As I said, the cheater has the info already, the admin does not get _any_ info at all. I don't see the logical point why this is done like it is. Greets Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [OT] Re: Multi-vendor Game Server DDoSVulnerability
Frank Stollar wrote: Jeremy Brooking wrote: I believe a lot of it has to do with 1 having a degree vs a working history in an ISP. A lot of people either lack the ability, or purely do not understand the effects these things can have. From their view, the network works, so I wont touch it... ironie Never touch a running system, ey? I can't believe this old law will stand also for this 'behavior'! /ironie But the point about 'degree' is obviously the bitter true reason. *sigh* Oups, pressed the send button too fast Sure it is also true, the most admins don't see something is wrong, there network is running and all is fine. I think most admins won't know the risk which arise out of misconfigurated network. *sigh* good night Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [OT] Having fun as an admin..
Another way to have some fun is: mp_buytime 0.01 slow buying players will have no fun mp_footsteps 0 at the end of a round when everybody is camping and hear the enemy before comming around the corner. mp_roundtime 1 when the T (in de levels) will take too much time to finish mp_c4timer 15 when the CT are taking all time to get to the bomb mp_freezetime of course mp_startmoney 16000 just bevor a mapchange... not all people get it :) sv_maxspeed 80 slow baby slow but also a fun is to give the worst player on the server (with a 0:xx kd ratio) an extra bonus with admin_godmode player for one round. But better do this with people online you know, otherwise there will be lameness come up. hf Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Win XP, A3D and compatibility mode
Leon Hartwig wrote: We have confirmed a false positive with the current (August 28) beta modules: Windows XP clients who run HL/CS in Windows 98 compatibility mode. We'll get new beta modules up soon to correct this. Well, this is used often by users trying to get a3d 2.0 to work under Win XP. I already wanted to write something about this topic but never managed to. Everywere this is a common tip for XP users to enable the compatible mode in XP for HL to get A3D to work. Just look at the source for every Aureal user: http://www.vortexofsound.com/ There in the forum you can see most people get A3D running only with compatibility mode activated. It's a walk trough hell to get A3D with the AU8830 to work on w2k or XP. With good old 95/98 it is a piece of cake. So the comp. mode will used more likely as you think. I know this is a bit OT but I will tell you anyway, hoping somebody know the answer or somebody from VALVe will read this. I on my self are one of the less lucky guys who do not get A3D 2.0 running with HL. Will VALVe please fix this obvious bug ? It's a pain for all users of modern WinOS to stumble with HL to get A3D. I have a AU8830 card and installed the W2k Driver available. They run flawless. Everything work. The A3D 2.0 demos, A3D plugin for winamp, all just fine. But when I activate A3D in HL and somebody shoot (pistole, rifle anything else) it will instantly freeze the HL process. I tried many many thing, different drivers, HL original A3D.DLL, newer, older, with and without compatibility mode but nothing works. All sound are played very well as A3D but it will hang 1-3 sek after the first shot of any weapon. I hope somebody out there will hear this... Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] weird wonid
Jay Anstiss wrote: I had someone join my server tonight and they ahd the following wonid: :[Tara'sKnight]: - wonid: -1 I'm not saying they're upto anything dodgy, but that is a weird wonid. I mean, -1?! Any thoughts?! That's very easy. If you habe an LAN HL Server, the WonID you would see in the logs is 4294967295. If you put this in a signed integer of 32 bit, this would be equal to -1. It's a kind of computer math and how a computer interprets positiv and negativ numbers. But 4294967295 = -1 that's the point :) Hope this helps Frank ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
