I built a server, with TCP socket. I have a client using telnet connected to the server. Once the connection is active, the server will send data to the client.
The problem is that the client will send some commands to the server randomly and automatically, such as:
IAC WONT 64 --- FF FC 40
IAC DONT 64 --- FF FE 40
IAC DO 00 --- FF FD 00
Telnet Command list
My questions:
1. Why will the telnet client send out message to server by itself?
2. What is the meaning of those commands, I cannot find the meaning of 0x40 and 0x00?
00 is "binary transmission" meaning that it's an 8-bit connection. 40 is not something that is standardized but whatever it is, the client doesn't want to do it.
Either side of a "telnet" connection can send configuration negotiation options upon establishing the connection (or, though rarely, any time during the session) though typically the client defaults to a "raw socket" until it starts receiving codes from the server so that the program can be used to connect to other, non-telnet ports as well.
You didn't specify what OS you're using but there may be options to telnet that prevent initial option negotiation.
Related
Edit:
I think based on the below answer here, it seems the answer is "client and server basically only communicate on one port, 3478 (or equivalent")
rfc 5766 : Issue when Both devices support TURN
==========================.
I have been reading several sources on TURN, including RFC.
I get the whole premise:
Client creates allocation on TURN server
Client sends data to Peer through TURN that relays via the relayed transport address
Same way around from peer --> Server --> client
Most resources focus on setting up the server and what ports need to be configured.
The point that I am unclear is on the client side:
After the allocation is done and the client can start sending data, do they send that data to the relayed transport address that the Server allocated? Or do they send it to the standard TURN port e.g. 3478, and then the server takes care of looking up the allocation for this client and send it through the relayed address to the peer?
Example:
Client address 192.6.12.123:45677 (let's assume it's the NAT)
TURN server listens on 34.45.34.123:3478
TURN server has done an allocation for client on 34.45.34.123:50678
So when the client wants to send to a peer application data, do they send on port 3478 or port 50678?
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478 and the server takes care to send via the relayed address.
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478
The client will pick a random local port (e.g 45677), but traffic sent from this port goes to the server's port 3478 (or 5349 if using TLS) on the server. The server will forward it through its allocated port (50678) to whatever remote port the other client established during ICE negotiation.
Trying to configure a syslog-ng server to send all of the logs that it receives, to another syslog-ng server over TLS. Both running RHEL 7. Everything seems to be working from an encryption and cert perspective. Not seeing any error messages in the logs, an openssl s_client test connection works successfully, I can see the packets coming in over the port that I'm using for TLS, but nothing is being written to disk on the second syslog-ng server. Here's the summary of the config on the syslog server that I'm trying to send the logs to:
source:
source s_encrypted_syslog {
syslog(ip(0.0.0.0) port(1470) transport("tls")
tls(key-file("/etc/syslog-ng/key.d/privkey.pem")
certfile("/etc/syslog-ng/cert.d/servercert.pem")
peer-verify(optional-untrusted)
}
#changing to trusted once issue is fixed
destination:
destination d_syslog_facility_f {
file("/mnt/syslog/$LOGHOST/log/$R_YEAR-$R_MONTH-$R_DAY/$HOST_FROM/$HOST/$FACILITY.log" dir-owner ("syslogng") dir-group("syslogng") owner("syslogng") group("syslogng"));
log setting:
log { source (s_encrypted_syslog); destination (d_syslog_facility_f); };
syslog-ng is currently running as root to rule out permission issues. selinux is currently set to permissive. Tried increasing the verbosity on syslog-ng logs and turned on debugging, but not seeing anything jumping out at me as far as errors or issues go. Also the odd thing is, I have very similar config on the first syslog-ng server and it's receiving and storing logs just fine.
Also, I should note that there could be some small typo's in the config above as I'm not able to copy and paste it. Syslog-ng allows me to start up the service with no errors with the config that I have loaded currently. It's simply not writing the data that it's receiving to the destination that I have specified.
It happens quite often that the packet filter prevents a connection to the syslog port, or in your case port 1470. In that case the server starts up successfully, you might even be able to connect using openssl s_client on the same host, but the client will not be able to establish a connection to the server.
Please check that you can actually connect to the server from the client computer (e.g. via openssl s_client, or at least with something like netcat or telnet).
If the connection works, another issue might be that the client is not routing messages to this encrypted destination. syslog-ng only performs the SSL handshake as messages are being sent. No messages would result in the connection being open but not really exchanging packets on the TCP level.
Couple of troubleshooting tips:
You can check if there is a connection between the client and the server with "netstat -antp | grep syslog-ng" on the server or the client. You should see connections in the ESTABLISHED state on both sides of the connection (with local/remote addresses switched of course).
Check that your packet filter lets port 1470 connections through. You are most likely using iptables, try reviewing your ruleset and see if port 1470 on TCP is allowed to pass in the INPUT chain. You could try adding a "LOG" rule right before the default rule to see if the packets are dropped at that level. If you already have LOG rules, you might check the kernel logs of the server to see if that LOG rule produced any messages.
You can also confirm if there's traffic with tcpdump on the server (e.g. tcpdump -pen port 1470). If you write the traffic dump to a file (e.g. the -w argument to tcpdump, along with -s 0 to avoid truncation), then this dump file can be analyzed with wireshark to see if the negotiation takes place. You should at the very least see a "Client Hello" and a "Server Hello" packet which are not encrypted at the beginning of the handshake.
When a TELNET session is initialised using PuTTY, I see that PuTTY is sending the following characters to the server at the beginning of the connection:
..... .....'.........
I was able to capture this using WireShark.
The hex characters are as follows:
ff fb 1f ff fb 20 ff fb 18 ff fb 27 ff fd 01 ff fb 03 ff fd 03
Can you please help me understand why PuTTY sends these characters?
I assumed it is something with the connection, but then, these characters are found in the DATA category of the WireShark capture.
Here is a video: https://www.youtube.com/watch?v=WGZru4KPmsM
Thanks to Some programmer dude and Elmi.
These extra chunk of characters are the negotiation sequences from PuTTY (client) to the server.
Negotiations allow the client to have an enriched experience.
A list of negotiation sequences in telnet protocol and their explanation is given here
If you are using PuTTY and do not need these sequences, go to
Connection > Telnet
and set the Telnet negotiation mode to Passive
Here is a link to Elmi's post
One way to quickly test the first-order functionality of a web server is to use the application layer tool Telnet, e.g. How to send an HTTP request using Telnet.
This is the usage I am most familiar with, but today I learned there is such a thing as a Telnet server: https://askubuntu.com/questions/668725/how-can-the-telnet-service-on-ubuntu-server-14-04-lts-be-enabled, which listens on the well-known port 23 and can be used (though not usually, due to its lack of security) as a remote shell.
I am trying to understand if a Telnet server is necessary if I use it to connect to an HTTP server on port 80, e.g.,
telnet 192.168.0.5 80
Does the Telnet client first connect to the telnet server on port 23, then somehow the server's Telnet process then establish a connection to port 80 on localhost? Or does the client directly connect to the HTTP server (or some other TCP/IP server, for that matter) on 80, without need the Telnet server to be present at all?
I could not immediately find a piece of Telnet documentation that explains how Telnet works in this regard; their scarcity might be attributed to Telnet's lack of security...
I'd like to figure out the value of 'keepalive_requests' for a given 'Nginx' or 'Apache' server from the client side. The default for 'Nginx' is 100 (http://nginx.org/en/docs/http/ngx_http_core_module.html) but I'd like to analyse this for www.example.com where I don't have access to the config.
Obviously I could start a Wireshark and do it manually. I was hoping on some sort of easy shell (e.g. 'wget' like) command.
From client side, I use ab test, wireshark, and an editor like notepad++ to count number of http requests in a socket.
First I use apache ab test to send request, something as bellow:
ab -n 100 -c 100 http://www.example.com/index.php
Before execution, start my wireshark, and set the display filter:
ip.dst == && tcp.port == 80 && !http && tcp.flags.fin==1
After the ab test finished, the result list of wireshark shows the total sockets used during the requests. Right click one packet, and click follow TCP stream, the opened windows shows all the message send and receive in this socket.
If the last FIN direction was sent by remote nginx server, which was influenced by the value of keepalive_requests. We can copy the all requests in this TCP connection into the notepad++, search for the key word and then count the requests in this socket. the number presents the value of keepalive_requests setting in the remote nginx server.
BTW, I wish a better solution, my solution is not so good.