Incoming request to confirm support for raw TCP sockets and UDP protocol comms.
Prospective user would like to send/receive UDP datagram messages and utilise UDP device type commands over IP. In addition they also want full support for raw TCP/IP sockets.
I understand this can be acheived by switching off auto-negotiation on a TELNET session but I believe this will only allow CLI to a raw TCP socket.
Can you confirm the config for supporting both TCP and UDP command-line sessions.
Thanks.
Telnet application can be used for raw tcp sockets if the data on the socket is ASCII. If the data is binary, you cannot use telnet application.
It is odd to talk about having an app for raw TCP or raw UDP socket. These are transport layers in an OSI stack and what you really want is an integration with an application next layer up like Telnet or SSH or SNMP (udp) or Syslog (udp).
We do have "wireshark" app which is perfect for TCP and UDP analysis and in fact it can be used to analyze data even at lower layers. It can also deal with binary data. I would recommend using wireshark for this and it will work perfectly.
Wireshark session is fine for monitoring and analysis. Prospective user has seen this and agrees this is useful. This falls short of requirements.
To clarify my request, what is required with UDP is to be able to send actual customised commands to switch devices on/off etc.
I believe this can be done using TELNET/SSH but requires some configuration of the Session Properties.
What I need is confirmation of the actual configuration required to interact with either transport protocol.
Thanks,
Ralph
If they really want to have control and send/receive UDP packets, they could create a very simple SDK app that handled this. It wouldn't take a lot to provide this functionality.
That's exactly what they need. Your response, Adam, does suggest that command line interaction at the UDP level is not something that can be acheived with configuration of existing iTest CLI session.
2 questions:
1. What config changes are required in the TELNET Session Properties are required to be able to interact with a raw TCP Socket?
2. Can you expand on what data would be needed to start to build an SDK session that would perform command line UDP interaction?
Thanks,
Ralph
Ralph
Tcp/Udp are transport layers in the network stack. You can write an application which can send and receive any type of data using these transports. It is an unusual request to be able to send data at these layers. Generally, this is done by tools called traffic generators (ixia, spirent). Sometimes, people create their own custom protocol on top of these layers (e.g. like Telnet for tcp and SNMP for udp) and for most commonly used protocols on top of Tcp and Udp, you will find well known tools to deal with them (e.g. iTest's telnet client, putty, iTest's SNMP Mib browser, net-snmp open source tools for SNMP).
Before you build a tool using SDK for this custom protocol, you may want to look at this page:
http://wiki.wireshark.org/Tools#head-533ceb0292aac1ed2b541ebf91bd2903f55f70b1
You will find a number of tools which let you send tcp and udp packets from commandline.
Nemesis seems to be closest to what we are trying to acheive here. The point our prospect was making too was how other tools "like" ours have this transport layer support in the base product.
Thanks.
I have not heard of any tools like iTest which do raw TCP and UDP packets other than "traffic generators" like Ixia and Spirent. Can you elaborate which tool has this ability (which is not a traffic generator)?
QS Test Shell Builder claims to have the following support in the form of encapsulated test modules.
Quoting from their web:
"Network Protocol Modules: enabling access, control and configuration of network devices using protocols such as FTP, SNMP, Telnet, SSH, TCP, UDP and others"
Our prospect has seen it and claims it does what it says.
Can you ask your client on what he "specifically" wants to do with UDP/TCP integration? That will be a much more useful discussion. It is kind of silly to put "ftp, snmp, telnet, ssh" in the same category as "tcp and udp". These two are different layers of OSI stack. The statement seems more like marketing statement than a technical one.
I agree.
It may very well be the case that the customer wants to test their custom protocol that happens to be running over UDP instead of TCP, but a generic test system capable of handling all possible requirements is a bit much. For example, is this carrying plain text over UDP? Is it binary? How are they handling retransmit, sequencing, etc.
Any attempt to do a control protocol over UDP needs to answer these questions and then the test system becomes a client that needs to obey these protocol rules.
I have already asked our prospect what his specific requirements are here.
I'll report back when I have some more detail.
Prospect is using a general purpose PIC Microprocessor Board for controlling their testbed physical switches (Relays, RF-Switches, Ethernet L1 Switches etc).
These boards use TCP and UDP protocol for remote device control and command over an Ethernet link.
The datagram of the TCP/UDP packets contains the ASCII based commands to/from the PIC Device.
