1

I have a digital scope, with LAN connection. I'd like to check if telnet is running on the scope (the manual doesn't say so, but then the manual doesn't offer anything useful about the LAN port).

I tried connecting (and succeeded) connecting with netcat, and also with telnet. The telnet command confirms connection, but I can only see the connection to the TCP port (using wireshark).

From what I read about the telnet protocol, from the outside it looks like an attended TCP port, and the configuration negotiation commands are optional, so sending those wouldn't be a convincing if no reply came.

EDIT: In case anyone is interested, the scope is the Owon SDS7102E. Don't buy that scope if you are interested in it for the LAN connection. The documentation is basically non-existing (it says "LAN is same as USB"). The manufacturer seems somewhat interested to help out (at least answered) but no real solutions yet.

  • 1
    Can you use ss -tln and see if there is a listening service on TCP port 23? – Patrick May 5 '18 at 4:50
  • No unix-like commands are available at all from the LAN connection. Not even a prompt appears. – jcoppens May 5 '18 at 20:28
4

You can debug your telnet connection on the client by adding 3 lines to your file ~/.telnetrc:

scope
 set netdata
 set options

where scope is the hostname of your scope and must be in column 1, and the other 2 lines must be indented 1 space.

When you run telnet it should now show you the data read and written and the commands sent and received, if any.

You can send explicit telnet negotiation commands to see if your scope replies. Note, when you change a setting to a value that the remote thinks it already is, it will not reply, so you may need to try a command and its inverse. For example, (type control-] to enter command mode), send "are you there?":

telnet> send ayt
> 0x0   fff6
< 0x0   74643a207265637620494143204159540d0a0d0a5b686f6d65203a207965735d
< 0x20  0d0a
td: recv IAC AYT

[scope : yes]

The > and < data lines are the result of set netdata. The td: negotiation lines are the result of set options. (If you don't see them perhaps your rc file was ignored, so type them in explicitly in command mode.)

Set echo on, then off and on again:

telnet> send do echo

telnet> send dont echo
> 0x0   fffe01
< 0x0   74643a207265637620646f6e74204543484f0d0afffc0174643a2073656e6420
< 0x20  776f6e74204543484f0d0a
td: recv dont ECHO
td: send wont ECHO

telnet> send do echo
> 0x0   fffd01
< 0x0   74643a207265637620646f204543484f0d0afffb0174643a2073656e64207769
< 0x20  6c6c204543484f0d0a
td: recv do ECHO
td: send will ECHO
  • Great! No reply at all. So, as I suspected, no telnet server is running in the scope. The seller boasts it has a LAN port, but controlling the scope with just TCP seems unreliable, as TCP at times packs packets into one line, which seems to utterly confuse the scope (firmware even hangs). Thanks for the info, @meuh! Very interesting... – jcoppens May 5 '18 at 20:14
0

You can connect to any port with telnet, even if there's not a telnet server behind it. If the port expects the client to send something first, then you won't see anything when connecting, and that's exactly the situation you have.

So there may be a telnet server running and expecting input, there may be something else running, or it may be a firewall feature that just pretends you can connect to it. With telnet alone it's hard to tell.

If you want to find out which possible services are running on an unknown device, I recommend probing with nmap.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.