I am using AzerothCore locally and when I try to log in - I am stuck at "Authenticating".
Previously on login attempt - a error occured, WorldSocket Malformed request sent by client, But after opening the ports for both inbound and outbound connections - it dissapeared.
Therefore, no error message, just stuck at "Authenticating".
Client version: 3.3.5 (13240) (Release)
Jan 24 2010
The realmList is changed to 127.0.0.1:8085 But I am not sure if it is correct, since once I had issues accessing localhost on another application and had to use the router's IP (192.168.0.3)
WorldSocket Malformed request sent by client
WorldSocket::ReadHeaderHandler(): client 111.222.11.22 sent malformed packet (size: 1234, cmd: 3333333)
means some machine anywhere on the planet sent a random portscan to your IP.
Not related to your actual problem.
You should try and set the realmlist to the LAN IP of the machine running the server and do the same in the realmlist table.
Also make sure all ports are properly forwarded to your server. (8085 und 3724 by default).
If both, client and server are running on the same machine, you can use 127.0.0.1. Not otherwise.
Solved:
On the client, use set realmlist 127.0.0.1
Without the port
I can run my Qt DBus test by connecting to the session bus:
QDBusConnection connection = QDBusConnection::sessionBus();
connection.registerService(...)
....
TestserviceInterface testserviceInterface( .... , connection, &a);
But can I connect to this DBus from a different computer. I know I can do something like this:
connection = QDBusConnection::connectToPeer("tcp:host=127.0.0.1,port=45000", Testservice::ServiceName);
But how would I obtain the port? Whatever I have tried, there seems to be no connection. Or am I at the wrong path here and need to us Peer 2 Peer DBus instead of the session bus?
I am almost sure the service name is correct, as I can see it qdbusviewer. When I use dbus-monitor the output does not mean a lot to me, I cannot see any port, etc.
Any idea how I would be able to connect from another computer?
PS: I am aware that there is something like gabriel for tunnelling via SSH (http://gabriel.sourceforge.net/howto.html). This is not what I am up to, I am looking for a "direct connection".
Session bus daemon usually listens unix socket /var/run/dbus/system_bus_socket ( check your /usr/local/etc/dbus-1/session.conf config ) which means that you can't access it remotely via tcp. Start some kind of port forwarding on computer where bus daemon is running (using socat for example) or configure it to listen tcp.
You can use SSH to create a tunnel for DBus.
ssh -nNT -L ./dbus_on_local:/var/run/dbus/system_bus_socket user#remote
Explanation
This will create a local "file" (unix domain socket) dbus_on_local that you can connect to.
I have a server application with a listening socket opened on a specific IP port.
How can I allow the socket to enable incoming connections from just one specified IP address?
You'll have to either use some firewall software to restrict incoming requests to that port, or shut down accepted connections that you do not want to service (based on the socket address returned by accept).
There might be libraries out there that do that for you, but the socket API doesn't have anything to do it automatically.
When you accept a connection you can examine the sockaddr after accepting to see if it came from the right address. If not you immediately close the connect socket returned by accept.
You have to accept the connection with accept(), then close it if you don't want it (perhaps sending an error response if your protocol supports this). This is good enough for most applications.
Try: libauth, it's a robust way of access control http://linux.die.net/man/3/libauth
How do I detect if a remote client is running Remote Desktop Protocol? and it is also accepting remote desktop connections ??
Like Open an port to detect HTTP and send request, receive request headers and see in request headers information about HTTP so I will know the person is running HTTP weather if he changed the port e.g: running HTTP 6551.
Attempt and make a connection with something that is RDP-connection aware (RDP is not HTTP). Of course, failing to establish an initial handshake is not proof that a connection can not be established. It could be blocked by a firewall, listening on another port, etc.
The MS-RDPBCGR specification, page 16 talks about connecting which in turn defers to X.224, go figure.
It'd likely just be easiest to use Wireshark and observe in-the-wild behavior to develop a minimal detection case. I suspect only the very initial portion of the handshake needs to be generated/replayed in order to "decide" that it's a listening RDP server.
(Or, perhaps use an existing RDP client which has this "test connect" functionality or the ability to be scripted.)
A fast way is to pen a shell and type
telnet IPADDRESS 3389
If you get a connection, chances are good that an RDP server is on the other side. RDP can run on any port, but TCP Port 3389 is set per default.
Windows 7 requires some extra steps to enable the telnet Client.
You could do netstat -a in the command line and see if the default port for remote desktop connection is listening, ie. TCP:3389 but thats only if the client hasn't changed the ports for MSTSC
I have a requirement to send some 100 bytes data over internet .My machine is connected to internet.
I can do this with HTTP by sending requests and receiving responses.
But my requirement is just to send data not receive response.
I am thinking of doing this using UDP Client server program. But to do that I need to host UDP client on internet?
Is there any other way to do that?
any suggestions?
Cheap answer to send 100 bytes of data on the internet.
C:\Windows\system32>ping -n 1 -l 100 -4 google.com
Pinging google.com [209.85.171.99] with 100 bytes of data:
Reply from 209.85.171.99: bytes=56 (sent 100) time=174ms TTL=233
Ping statistics for 209.85.171.99:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 174ms, Maximum = 174ms, Average = 174ms
Anything that happens on the internet requires a client and a server.
One box is in the role of client, the other is in the role of server for your specific transaction.
Usually (but not always) your local box is a client and some other box is the server.
Software MUST be running on both to implement some protocol for exchanging data.
A server can listen on TCP or UDP sockets, with some restrictions. Some port numbers are privileged. Some port numbers are blocked by firewalls.
Port 80, while rarely blocked by firewalls is a privileged port. Generally, you need a web server (e.g., Apache) or privileges to listen on port 80.
"Sending 100 bytes" can be done using a lot of available protocols: Echo, Telnet, FTP, HTTP to name a few.
The big advantage of HTTP is that port 80 is very often open. With other protocols you have to rely on the operators to open the port.
In order to send data but not receive a response, you can simply write your program in such a way that it does not listen for a response. This doesn't mean one won't be sent to you, just that you won't get it.
For example, you can make sure you don't call "recv" on the socket. Also, you can use "shutdown" to disable reads on the socket. Depending on the underlying implementation, going the "shutdown" route might cause all incoming packets to simply be dropped.
As far as how to send the packets, really any sort of protocol will work. Of course, you need to know of a destination server on the Internet, but you've got plenty of options. Perhaps the simplest route to take is what you have suggested: HTTP (perhaps use www.google.com as your destination server).
You need a client (you) and a server (other end). For UDP, you send datagrams over the Internet (using IP). UDP doesn't provide the safety that TCP does, but doesn't require a response (but such responses are part of their protocols, not yours).
I would suggest using TCP to save you some headache.
Also, make sure you're not behind a firewall, else your packets won't make it to their destination as you'd expect.
Hmmm...
You want to send short messages over the internet, but without any response.
Your application wouldn't by any chance be some kind of spyware, would it?
Use UDP. Open a socket, send the data, close the socket. That's it. Here is a Python version of the client:
import socket
data = 100*'x'
address = ('192.168.0.123', 8080) # Host, port
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP
sock.connect(address)
sock.send(data)
sock.close()
On the Wikipedia page about UDP there is some corresponding WinSock code.
Of course the other side must be reachable, and there must be someone listening there, otherwise the target machine will reply with an ICMP "port unreachable" packet (at least if it complies with standards).
If you want a UDP listener on the internet, it will have to be hosted somewhere.
You can get HTTP hosting much easier, it's everywhere, UDP you may need your own machine or at least a VM.
curl is a command line tool for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, Telnet and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and a busload of other useful tricks.
See examples here