Can anyone tell me which Communication Protocol is used by hyperterminal connecting via Tcp/Ip ?
Protocol here means UDP, Socket/Server, other(If any).
Actually, I need to design an application (in QT, Linux as OS) to communicate to a machine (basically a printer) via Ethernet. I need to send request to the printer as well as receive response, if any, from the printer.
It can be communicated via Hyperterminal using Tcp/IP.
So I wonder which protocol should i use for the communication. As Printer simply supports ethernet therefore I have no idea, if I can use Socket/Server for communication.
Need suggestion over this. All idea/suggestion are welcome.
Thanks in Advance
You need to get your terminology right. TCP/IP and UDP are transport layers. A protocol refers to the application data that is transmitted over a transport. A socket is a programming API that allows an application to gain access to a transport so it can send/receive protocol data.
Now, to answer your question - HyperTerminal typically uses the Telnet protocol over TCP/IP. Many protocols in existence are text-based, and Telnet is largely compatible with simple ASCII text, which makes it convenient for allowing users to use Telnet UI clients, like HyperTerminal, to manually send text commands to network-connected devices. However, most devices/protocols do not use the actual Telnet protocol. But if you can communicate with a device using HyperTerminal, you can code your app to send/receive the same text commands.
Related
For learning purposes I'm implementing TCP (for now just RFC 793) but I have no
idea how to test it. Most TUN/TAP stuff on the internet are out of date (e.g.
Linux API calls no longer work) and just doesn't explain enough. In addition, I
feel like a creating a device and forwarding packages etc. are not the best way
for learning purposes. For example, I'd rather only override socket(),
listen(), connect(), accept(), send(), recv() etc. in a program rather
than forwarding all ethernet traffic to a device/program that does the
bookeeping for the whole system rather than for a single program.
I'm wondering if this is possible. If not, I'd like to know the simplest way to
test a TCP implementation on Linux.
Because I'm following RFC 793, it'd be great if I could have an IP (Internet
Protocol as mentioned in the RFC) API in my application. Is this possible or do
I have to mess with TUN/TAP stuff?
Thanks..
If we talk about research I strongly recommend you read Engineering with Logic: Rigorous Test-Oracle Specification and
Validation for TCP/IP and the Sockets API
It contains section about testing TCP/IP implementation:
"EXPERIMENTAL VALIDATION: TESTING INFRASTRUCTURE"
You could try setting up two peers, one using a RAW socket and the other a TCP socket.
If they can communicate and packets are really delivered/recovered the same way TCP does, you know that your custom implementation is successful.
C sockets
C RAW sockets
C TCP implementation
All you need is to intercept all tcp packets with bits (syn, ack, fin, etc.) your application has sent and to see if it works properly:
It could simply be done with wireshark or other sniffer. When testing you will see all tcp packets with bits you've sent.
In order you want to see linux system calls which your application are calling, you can use GDB or any other debugger.
I'm working on an application that interfaces with embedded equipment via the SNMP protocol. To facilitate testing, I've written a simulator for the embedded equipment with Nodejs and the snmpjs library. The simulator responds to SNMP gets/sets and sends traps to the managing application. The trap messages are constructed by the snmpjs library, but sent manually using Node's standard UDP sockets.
This works well when simulating one equipment, but I've run into an issue when attempting to simulate multiple equipment. Specifically, the managing application identifies the source equipment of SNMP traps by analyzing the source IP/port of the UDP packet carrying the trap. This precludes my simulating multiple equipment simultaneously, which is the most common use case for the application.
So, my question is: Is there some way to control/spoof the source IP or port of the udp packet with Nodejs? Or, perhaps, would it be possible to use some kind of proxy to achieve the desired result?
(Note: Running the simulators on a single machine is a strict requirement. Also, it is not sufficient that I have unique IPs/ports for each simulator, I must be able to know their values ahead of time so that I can configure the managing application to interface with them correctly.)
The solution was simple. I overlooked this line from the node documentation for the send method of udp sockets, "If the socket has not been previously bound with a call to bind, it's assigned a random port number..." I just needed to bind the socket to a port first. I've verified this with a test script.
I have a device which connects via serial port. I communicate with it via Windows Hyper Terminal. I'm just wondering, what protocol does it use? As you probably, know hyper terminal can display and accept input as well. It's a two way communication.
Thank you for any help.
HyperTerminal uses the following communication protocols according to TechNet:
Transmission protocol and port: The protocols used are Kermit, Xmodem, Xmodem-1K, Ymodem, Ymodem-G and Zmodem transmissions protocols on port 23
There is actually no protocol. Serial sends and recieve bits. You specify them in your serial setting when you want to communicate with a device. Typically 8 bits are specified which is equivalent to an ASCII character. Both communicating parties send and receive ASCII data any time they want
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
I have a black-box device with a modem attached (which I can send commands to), and would like to be able to connect to send data to a server from it. What connectivity options do I have, is PPP the protocol I need to use or is there a better option?
ppp is certainly the most common solution for getting an IP connection over a modem. There are other solutions, but there's no reason not to use PPP if what you need is an IP connection.
If you don't need an IP connection and you're writing both the client and the server, you could also do a straight serial connection from one modem to another, but that's kind of old-school.
PPP is probably your best option, if you also want an IP gateway and routing. If you only need terminal access to the device, and it runs some form of *nix, you probably have getty+serial communication as an option. You can use any number of modem terminal clients on the other side.