View Full Version : [OTT] UDP port 20999 - 62.140.29.51
Does anyone know what this address is : 62.140.29.51? Its on level3 in Hamburg.
That's the Mars worldserver.
I looked up that address on de.wikipedia.org and this came up:
http://tkershaw.netfirms.com/pics/bs/adolfvader.jpg
Also, hai2kurai.
awkward silence
27-03-07, 20:43
I had to look at that pic a few mins till i got the point... :lol:
Too tired
If this is the Mars server, then there is something very strange happening with the client and my laptop and more than likely VMWare.
My internal network uses the range 10.51.44.0/24.
My firewall (Cisco PIX) is seeing these packets on the inside interface:
305005: No translation group found for udp src inside:192.168.143.1/20999 dst outside:62.140.29.51/5008
305005: No translation group found for udp src inside:192.168.153.1/20999 dst outside:62.140.29.51/5008
305005: No translation group found for udp src inside:192.168.143.1/20999 dst outside:62.140.29.51/5008
305005: No translation group found for udp src inside:192.168.153.1/20999 dst outside:62.140.29.51/5008
305005: No translation group found for udp src inside:192.168.143.1/20999 dst outside:62.140.29.51/5008
305005: No translation group found for udp src inside:192.168.153.1/20999 dst outside:62.140.29.51/5008
These messages state that a machine on the inside (192.168.153.1) is trying to send UDP to 62.140.29.51, which is always blocked by my firewall because this Class C address is not configured on my firewall. The machine that is trying to send these packets can only be mine since it is the only PC connected to my network, and it uses CatV cable, not wireless.
I have Join Proxy Fail messages whenever I try and re-log each time. Maybe these are connected.
The likely culprit is VMware, since it has some addresses configured for the 192.168.153.n. Time to unconfigure these and see what happens. o_O
I uninstalled VMWare and the Join Proxy Failed message disappeared. I can relog once more without having to close the client down and start it again each time.
However, this does not tell me why this happened, and it is still a problem because I use VMWare. Does VMWare understand that NC uses these ports as well; Does NC understand that the VMWare interfaces are not for it to route packets out of? The plot thickens.
Mighty Max
27-03-07, 23:27
If the cisco router is not part of a 168.192.x.x network, it will deny to route network traffic from or to such IPs (as these are declared private) unless you configured the router otherwise.
Neocron will try to use the first available NIC, which in the case of an installed VM-Ware with a virtual NIC can be that virtual NIC. Thus sending the packets with the IP of that NIC namely the 168.192.... These will leave the VMWare since it will route these packets. The next step is the router which as above explained will block them
Dribble Joy
28-03-07, 04:54
So.... are the current sync issues in NC KK's responsibility or not?
So.... are the current sync issues in NC KK's responsibility or not?This thread doesn't have anything to do with that. This has to do with why his VMWare install is causing issues for his PIX.
zil, why don't you put in persistent static routes for the NC IPs via a gateway reached via a real NIC?
Eh, nevermind. That probably wouldn't work. You need to kick the client in the bean bag and get it to use a different NIC. I know there's an ordering scheme somewhere in Windows to determine which int is used "first". Does anyone know if there is a config file change that can be made to force NC to use a particular int?
If the cisco router is not part of a 168.192.x.x network, it will deny to route network traffic from or to such IPs (as these are declared private) unless you configured the router otherwise.
Yes, this is why the PIX dropped the traffic. There is no PAT(nat) mapping for it so it has no idea what to do with it.
Neocron will try to use the first available NIC, which in the case of an installed VM-Ware with a virtual NIC can be that virtual NIC. Thus sending the packets with the IP of that NIC namely the 168.192.... These will leave the VMWare since it will route these packets. The next step is the router which as above explained will block them
Why does NC try and use the first available NIC? This seems a little daft, and would explain many problems that I have with NC on multihomed systems.
I agree, adding a static route ought to solve this problem.
I wonder if it might affect the problem with the login server. I think that it might use port 9050, which is the same port that is reserved for the TOR network service. I know this because during login and logout the client will hang if Tor is running. At this point, if the Tor client is disabled, the client will continue to the login screen or log out respectively.
z.
This thread doesn't have anything to do with that. This has to do with why his VMWare install is causing issues for his PIX.
zil, why don't you put in persistent static routes for the NC IPs via a gateway reached via a real NIC?
There are no problems with the PIX. It is performing as it was expected to. The problem is with some Neocron packets being routed out of the wrong NIC.
Why, who knows. These packets ought to have gone out of the correct interface, but did not.
I think that this has a lot to do with the sync problems.
Since I have uninstalled VMWare, and therefore the VMWare configured NICs, my sync issues have disappeared. Now each sync takes approximately a few seconds, instead of between ten & sixty seconds.
Since I have uninstalled VMWare, and therefore the VMWare configured NICs, my sync issues have disappeared. Now each sync takes approximately a few seconds, instead of between ten & sixty seconds.
That's odd. I have VMware installed, and I don't normally get a problem. I do get login issues if I've just powered down a virtual machine - for some reason Neocron doesn't like a network drive beoming disconnected. (Although to be fair to Neocron, Windows doesn't like a network drive beoming disconnected either.)
I do know my 2 VMware network cards are on the 192.168.75/15.x subnets, and my main network NIC is on 192.168.192.x It's possible that NC could be routing via one of the VMware NIC's and my router is somehow routing the packets, but this breaks just about every rule of IP networking.
Can you open a command prompt and post up the results of
ipconfig
and also
route print
Shall do, when I get back home. I am at work right now.
There are no problems with the PIX. It is performing as it was expected to. Problems as in making log messages that NC shouldn't if NC was behaving properly. :-)
You might want to change the NIC priority list and it might work, who knows :p
Start menu>Settings>Network & Dial-up Connections>*click*
In Network & Dial-up Connections, go to the advanced menu and then select "Advanced Settings...". Move up your original NIC to the top. Press OK.
Might or might not work.
This after VMware was uninstalled.
ifconfig
Windows IP Configuration
Ethernet adapter Wireless Network Connection 6:
Media State . . . . . . . . . . . : Media disconnected
Ethernet adapter Local Area Connection 3:
Connection-specific DNS Suffix . : nnnn.hidden.com
IP Address. . . . . . . . . . . . : 10.51.51.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.51.51.1
Ethernet adapter Wireless Network Connection 7:
Media State . . . . . . . . . . . : Media disconnected
Ethernet adapter Local Area Connection 5:
Media State . . . . . . . . . . . : Media disconnected
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : fe80::ffff:ffff:fffd%7
Default Gateway . . . . . . . . . : ::
Tunnel adapter Automatic Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . : pixie.local
IP Address. . . . . . . . . . . . : fe80::5efe:10.51.51.100%2
Default Gateway . . . . . . . . . :
route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 15 6d 51 0f ef ...... Atheros AR5004X Cardbus Wireless Network Adapter
- Packet Scheduler Miniport
0x3 ...00 01 4a f6 eb 2a ...... Marvell Yukon 88E8036 PCI-E Fast Ethernet Contro
ller - Packet Scheduler Miniport
0x4 ...00 13 02 10 eb a1 ...... Intel(R) PRO/Wireless 3945ABG Network Connection
- Packet Scheduler Miniport
0x5 ...00 ff 07 c3 e6 4c ...... TAP-Win32 Adapter V8 - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.51.51.1 10.51.51.100 20
10.51.51.0 255.255.255.0 10.51.51.100 10.51.51.100 20
10.51.51.100 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.51.51.100 10.51.51.100 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.51.51.100 10.51.51.100 20
255.255.255.255 255.255.255.255 10.51.51.100 2 1
255.255.255.255 255.255.255.255 10.51.51.100 5 1
255.255.255.255 255.255.255.255 10.51.51.100 10.51.51.100 1
255.255.255.255 255.255.255.255 10.51.51.100 4 1
Default Gateway: 10.51.51.1
===========================================================================
Persistent Routes:
None
Try my thing, one post above yours.
Ahah. Never saw this tab afore. I shall install VMware again and see what difference it makes.
Thank-you Rob.
If NC uses the wrong NIC that should solve the issue. However, if NC is using more than one NIC it's actually a problem within NC.
Mighty Max
28-03-07, 22:30
If NC uses the wrong NIC that should solve the issue. However, if NC is using more than one NIC it's actually a problem within NC.
It's actually working quite well usually. You can look into the Error.log to see which NIC Neocron verified as useable.
HostIP : 10.0.0.7
HostIP : 10.0.0.9
WINSOCKMGR : Bind recv socket HostIP 0, Addr:117440522, Port:20999
WINSOCKMGR : Bind send socket HostIP 0, Addr:117440522, Port:21000
WINSOCKMGR : Bind recv socket HostIP 1, Addr:150994954, Port:20999
WINSOCKMGR : Bind send socket HostIP 1, Addr:150994954, Port:21000
Receive from 2
Receive from 2
Received 1
Received Bytes 7
VALID IP received 1
Good IP found 150994954 1
If you happen to have a config where neocron decides wrong, it might be usefull to send an bugreport in with the log appended.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.