UDP Port access - c

I have a small server program in C which prints a message to the client. This program uses UDP Port for communication.
My question is: Is there a way or application by which I can test the functionality of my program from my windows machine. Example, if I type in some command, I can see the response from my program on my computer.
telnet xx.xx.xx.xx. PortNum, I believe telnet wpuld not work.

Not aware of any existing tools. I assume your server receives a message from the client and sends a response message back. If this is correct, create a basic client program which sends a message (sendto()) and then calls recvfrom() (default is blocking mode on my platform), then print the response message received. This works well for me. Don't have time to ferret around for an example (which is on linux) but you should be able to use an example udp client for windows from the web, I imagine. Let me know if you would like my client program as a template.

I think you may want to use netcat; if it's installed on your machine, it's typically executed by "nc"
netcat can connect to or listen on tcp or udp ports; -u is udp.
nc -u host port # connect to a udp port
nc -u -l 127.0.0.1 1026 # listen on port 1026, in udp mode.
etc.

Related

How let telnet server mandates telnet client to run in passive mode?

I have written a basic Telnet Server in C language, and I am testing it against some telnet clients.
However, depending on the client I use (PuTTY, for example) then the client acts as Active by default.
Is there a way for the server to always mandate the client to act in passive mode?
I am asking this because, in my understanding, if the server mandates it, then I do not need to implement any protocol-specific details, only the basics to handle this mandatory passive mode. So, my Telnet Server will be at the end a simple TCP socket.
Update 1:
Here I describe the data received when a client connects to the server:
Launch the Telnet Server
Telnet Client Connects (and sends telnet protocol data)
received = {ffff1fffff20ffff18ffff27ffff01ffff03ffff03}
The data is hex encoded, and by decoding it according to the Telnet specification, the client is trying to establish some configuration before any data starts to be exchanged.
On the Telnet Server side, I simply ignore received data starting with 0xff (IAC code).
That solves the problem for a while.
Type some data on the Client side and hit enter
Telnet Server receives the data
Type some data on the Client side and hit enter
Telnet Server receives the data + telnet protocol data
Here is the received data (I sent "123456"):
received = {616263646566ffff18ffff27ffff01ffff03ffff03}
As you can see, I received what I sent, but I also got some telnet protocol stuff. That is because the Telnet Client is in Active mode.
I wish that at some intermediate step between 2 and 3, the Telnet Server could set the Telnet Client to run in Passive mode, so, I would not receive any Telnet Protocol data at step 6.
Update 2:
As requested in the comments for more details about the "Passive mode", I mean the Telnet negotiation mode: (1) Passive mode: where the Telnet Client/Server will not send any negotiation data, only user data; (2) Active mode: where the Telnet Client/Server will send the negotiation data to configure/handshake what are the features to be used/set.
And yes, I also could not find that to be specific to the protocol, only on PuTTY documentation
TL;DR: The Telnet protocol and well-known options offer no support for what you describe.
I mean the Telnet negotiation mode: (1) Passive mode: where the Telnet Client/Server will not send any negotiation data, only user data; (2) Active mode: where the Telnet Client/Server will send the negotiation data to configure/handshake what are the features to be used/set.
The Telnet specifications do not define a "passive mode" by any name. There is no defined way for one side to request that the other refrain from attempting to negotiate protocol options, much less to refrain from sending any protocol commands at all.
On the Telnet Server side, I simply ignore received data starting with 0xff (IAC code).
There are many more Telnet commands than those related to option negotiation. Ignoring all Telnet commands makes your server not only impolite, but deficient. You reference PuTTY's "passive mode", but even in that mode, PuTTY still emits Telnet commands for purposes other than option negotiation, and it likely still performs option negotiation too, albeit after allowing the server to negotiate first.
Additionally,
Option negotiation and other protocol commands are asynchronous, which is why the approach you describe doesn't stall communication altogether, but that does not make it valid to ignore protocol commands. The server should emit a response to each option negotiation command received, even if that response is negative.
And that will make it less likely for clients to make renewed attempts to negotiate the same options, but the server cannot say "never" to any option request, only "no".
Although it is not obligated to accept requests or offers to enable non-default options, the server is obligated to honor requests to disable options:
Clearly, a party may always refuse
a request to enable, and must never refuse a request to disable some option
(RFC 854, p.2)
The only way for a Telnet endpoint to receive a data byte with value 255 (decimal) is via the IAC mechanism.
If a Telnet endpoint does not respond to AYT commands, then the other endpoint may sometimes conclude that the session has been dropped when in fact it is still active.
A Telnet endpoint that ignores protocol commands does not support standard, expected terminal operations including break signals, interrupt process signals, erase character and erase line commands, and terminal synch. If yours is a special-purpose Telnet implementation then perhaps some of these do not actually require any server-side action, but the synch, at least, is about the data stream between server and client, and I don't see any way that a conforming Telnet implementation can fail to provide for it.

Checking if a UDP message is sent in C

I want to check why a program is not receiving UDP messages. A client program is sending 4 integers every time sample. I have a server program that is using "recvfrom()" to get the UDP messages on a port but the program does not seem to be receiving the messages on the port number and is stuck in the "recvfrom" function. I was wondering if there are debugging techniques I can use to debug this issue?
Thanks!
There are many possibilities, common case could be,
Firewall on your machine or in transit, for example, your another endpoint is behind a firewall that disallow UDP inbound traffic from this address.
Routing, make sure the ping works
Your code bug, make sure loopback address works
To debug, you could install Wireshark to inspect specific interface's traffic.

bind() failed: Address already in use

I am implementing DNS server and DNS resolver and i am using socket programming in this. But i get error in function bind() as bind() failed and sendto() permission denied.
I had tried using different port numbers, also i am working as a root, but still it giving me same error.Please help me to solve those issues. Your answers are welcome. Thanks.
https://github.com/srijan/DNS-Server---Resolver/tree/c73a124a15f53eb985a4b4afc0dffedd432c8454
This error typically means some other socket in the system is open on the same port.
To see what other UDP sockets are open, run netstat -anu from the command line. You'll get a list of IP/port pairings. If you see one for port 53, that socket is conflicting with yours. If you are able to run as root and also use the -p option, it will additionally tell you the process number that owns each socket.
Run Netstat -anob with CLI in Windows.
C:\Windows\System32>socat TCP-LISTEN:443,fork,reuseaddr TCP:localhost:22
2021/02/01 16:22:41 socat[11240] E bind(5, {AF=2 0.0.0.0:443}, 16): Address already in use
C:\WINDOWS\system32>netstat -anob
Connexions actives
Proto Adresse locale Adresse distante État
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING 5676
[sshd.exe]
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1244
RpcSs
[svchost.exe]
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 7396
[vmware-hostd.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
[vmware-hostd.exe] is the process that listen instead of [socat.exe].
In my case, I am using VMware Workstation 16 Pro and have disabled virtual machine sharing in Preferences, which is an deprecated option. All is now OK.
WMware Workstation Server deprecated

Nanomsg TCP Handshake

I also posted this in the Arduino section, but this problem is probably caused more by my ignorance of nanomsg and connections in general rather than an Arduino problem.
I am attempting to communicate with a server that is using nanomsg to communicate via TCP on a port using an Arduino. I have attempted a variety of different configurations (remotely connecting to the arduino and having the arduino connect to the server, using different nanomsg tools).
I can get the Arduino, in server mode (running a very slightly modified version of the WiFiWebServer example) to successfully read text I send using cat
sudo cat texttosend > /dev/tcp/192.168.1.50/80
However in all the configurations, and no matter what text I am trying to send using nanomsg, I always get a string of the same numbers. Printing the bytes as hex from the arduino, they are 0 53 50 0 0 51 0 0. Nanocat (the simple command line tool of nanomsg) hangs instead of sending and shutting down (like it is constantly trying to confirm the connection before sending the data).
I'm assuming this is some kind of handshake the Arduino is failing, because the client connects, reads those bytes, then shuts down and restarts. Using nanomsg on both ends (from my local computer to the server) works fine.
If these numbers I'm getting are a handshake, how do I complete it?
The meat of the loop part of the Arduino code is
client = server.available();
if (client) {
Serial.println("new client");
while (client.connected()) {
while (client.available()) {
byte b = client.read();
Serial.print(b,HEX);
Serial.write(b);
}
}
}
And the nanocat command that hangs when trying to connect is
nanocat --push --connect tcp://192.168.1.50:80 --data thismesadsfsdfg
The following text describes nanomsg protocol for TCP.
In it you can see why you're getting the specified byte stream and what you should write before the text you want to send.

Address already in use while executing C socket programme

Hii All,
While running a socket programme (server side ) am getting message like
Address already in use
Am trying to connect to port 80 since port 80 is reserved for https application So before running server side programme i am closing all application that uses https application ,is it enough...
or am doing it wrong??
Am trying to make a communication between browser and termial...
You must run your application as super user(root) on Linux or administrator privileges on Windows in order to bind to port 80. This is the case for all service ports, which is < 1024. Either that or there still is another program binded to that port.
Try using netstat to find out what programs might be listening on port 80.
Example:
on Linux:
netstat -punta
on Windows:
netstat -ban
Both must be run with super user/admin privileges in order to see the program names that bind to specific ports.
If you just closed another process listening on 80 port, this port will be blocked for a certain timespan depending on your OS. This behavior is here to prevent an attacker to crash a service on your machine and immediately restart a malicious service on the same port.
This behavior can be disabled by using SO_REUSEADDR (by using setsockopt).
If your main problem is to communicate from a custom server to your broswer, you can use any port in your server for providing HTTP (8080 is common for that), just specify the port in the url http://server:port/ (ie. http://localhost:8080/)

Resources