I have a server listening on UDP port 22000 at a google compute engine.
I can connect from the internet, any machine no problem, but I cannot connect from the local machine.
The exact same code runs normally in any other (non-google) Linux machine.
My only changes to the default compute engine settings were to add a firewall rule allowing incoming UDP at port 22000.
Any help most welcome!
jaime
Solved!
Apparently in these machines / kernel UDP sockets need to have a name (bind) before sending - never needed in other machines where I installed the server.
So in the sequence:
socket()
settimeout(..)
setsockname( .. )
socksendto( .. )
sockrecvfrom( .. )
... I've always avoided the "setsockname" as per the Lua socket documentation (http://w3.impa.br/~diego/software/luasocket/udp.html#setsockname):
Note: This method can only be called before any datagram
is sent through the UDP object, and only once. Otherwise, the system
automatically binds the object to all local interfaces and chooses an
ephemeral port as soon as the first datagram is sent. After the local
address is set, either automatically by the system or explicitly by
setsockname, it cannot be changed.
... when sending was the first operation.
For some reason, here it is needed. To be specific, I've:
setsockname( '*', 0 ) - that is, bind to all local addresses, use an ephemereal port.
Related
We have a system that implements reverse ssh tunnel to enable remote port forwarding.
This enables to expose devices on local network via a Public IP.
However, we're achieving this by a static port allocation, i.e. We've mapped Serial No.s of devices to Ports and each time a request comes to our server with Serial No. , we forward it to the designated port.
Obviously this design isn't scalable and we want to replace it with dynamic port allocation, such that the server itself takes care of allocating the port and freeing it once the device goes offline.
It'd be great to have suggestions on how this can be achieved.
Thanks in anticipation and apologies for my lack of knowledge in case I didn't explain it better (I'm new to this)
This can be solved by using a ssh command script in ~/.ssh/authorized_keys on your server.
command="reverse_server.py" ssh-rsa <publicKey>
First, a client has to connect to the script and send it's own serial (in my case a use the MAC-adress of one NIC).
The server looks into a database and tell the assigned port number or creates a new one for an unknown serial.
In the next step, the client can connect, using the reported port number as reverse port.
Btw. You should add some logic to monitor and recreate the tunnel if it disconnects or get stuck.
I'd like to use a server between two machines (with no static IP). The only IP known to me is the server's IP address. I'd like to build/use a system that listens to 2 different ports within the server and whatever is received from localhost:portA is sent to localhost:portB and vise versa. Consequently, both machines (with java apps) can communicate through the server in the middle.
Please what is the best solution to do this. I'm working on linux system and I thought of using an SSH java API (hudson / ganymed-ssh-2) to build a port forwarding server application.
Some issue:
1) determining the size of the data transmitted to buffer read or not to forward it to the other port.
2)The speed of reading/writing bytes.
If you can use ssh protocol you can tunnel local or remote ports (this need support on server side). You can also think about an OpenSSH VPN (take a look on ssh -w option, this will create a real VPN (TUN/TAP device is required). ).
You can use the the ssh program. Take a look at the -L and -R options specifically.
Could someone please help me to configure UDP in web server to accept connection from GPRS mobile device. The GPRS mobile device will send data packets which i need to write as a file in web server to process a web page. Please help.
i need to know the following:
1) How to configure UDP in web server
2) How can a GPRS mobile device get connected to the server using UDP
3) Write the data packets to a txt file
Please help.
A "web server" usually means am "http-server", which is a process listening for incoming "http"-requests.
Now http is a protocol that is standardized to be accessed via TCP/IP port 80.
Therefore most webserver implementations will implement a TCP/IP server that listens to port 80 by default. Usually you can change the port if need be, but usually you cannot change the transport layer to e.g. UDP.
Therefore it might not really be possible to make your "web-server" react on UDP packets.
If, however, by "web server" you mean a host accesible on the internet (that eventually might happen to run an http-daemon), you might have more luck: simply run a small server-application on that machine that listens to incoming UDP traffic on a given port, and do "something" with it (e.g. forward it to an http-daemon to display the current location)
Answers to your 3 questions:
Creating a small application listening on UDP-traffic:
a trivial server could be:
`netcat -l -u -p 8888`
This will create a UDP-server listening on port 8888, using netcat.
Whatever client connects to your server, everything that the client sends to the server will be output via stdout, and you can talk back to the client via stdin.
You shouldn't use netcat in a production environment; but it is a good and simple tool to check whether a connetion can be established and whether the protocol works.
In production, you will probably want to use a "real" UDP-server, e.g. by writing your own in the language of your choice.
How to make your gprs device talk to your server? This is impossible to answer without knowing more about the device, it's OS and the software installed that produces the data and is supposed to send it to the.
netcat -l -u -p 8888 > myfile.txt
I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.
The two devices communicate without any problems.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.
The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.
Thanks for your help,
Barry
First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.
Second, the second device will get the peer address and port from recvfrom() api call.
In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.
The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.
So, I will refer to the "first device" as the client, and the "second device" as the server.
Each datagram sent from the client to the server contains two sets of address information:
1) The destination IP address and port, and
2) The return IP address and port.
The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.
This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.
The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).
I am working on a C++ server/.NET client applications couple in which my server (which runs the c++ on linux) broadcasts a message to show it's alive to the whole network and my .NET program listens for packets and parses to get the uptime of the server.
As I have read, to send a regular UDP broadcast to the broadcast address, I simply have to send a packet to 192.168.0.255 (in my case 192.168.2.255) or 255.255.255.255. Is this right? Can I use the same port address? Are there any other necessities?
I understand the fact that if my .NET program listens on that particular address it is possible to receive packets from other applications than my C++ server program. Is there any method of "signing" the packet on the C++ server-side in order for my .NET program to read the header of the packet and see that it is (almost) the one I am looking for?
Regardless of the language you are using, here is my answer:
Regarding the broadcast IP addresses, both addresses are broadcast addresses but the limited broadcast address (which is 255.255.255.255) won't be forwarded by routers. It is better to use the subnet-directed broadcast address (192.168.2.255).
In order to send/receive a broadcast address, you need to define your broadcast address (broadcast IP address and port number). For example: 192.168.2.255 and port number 3000. The client applications (the senders) MUST enable SO_BROADCAST socket option as follows:
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled, sizeof(enabled));
where sockfd is the socket descriptor.
The server application will listen on a specific port number (port 3000). Normally, the server will respond to each request using unicast message.
There will be no conflict as long as no application is listening on the same port number. Your server will not run if another application is listening on the same port unless you enabled SO_REUSEADDRESS socket option. However, if there is a conflict, then your signiture is depending on your protocol (message format). So, check the message format and reject the message if it does not follow the message format defined by your application protocol.
For client applications, the received packet is unicast (unless you have another design). So, no conflict at this side.
You also have to enable the SO_BROADCAST socket option in C++ to send broadcast traffic, or you'll get a permission denied error:
int broadcastPermission = 1;
setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, (void*)&broadcastPermission, sizeof(broadcastPermission))
If your .NET program listens for broadcast traffic, it will receive any and all broadcast traffic on the network sent on that port, including traffic not sent by your server. You could put a "marker" in the payload of the broadcast messages sent by your server. This way, your .NET program could distinguish which ones it cares about.
Beyond that, I would recommend using multicast instead of broadcast. Broadcast traffic is usually restricted to hosts on the same subnet. In layman's terms, if you have a router in your network, a host on side A of the router will not see broadcast traffic sent by a host on side B (and vice versa) because the router "blocks" it. Routers will almost always forward multicast traffic if a host has joined the multicast group.