topic Re: telnet option impact RF scanning device in Operating System - HP-UX

telnet option impact RF scanning device

Peter Gillis — Thu, 17 Jun 2004 22:46:56 GMT

Hi,
We run ux 11.0 op system. We have recently upgraded our wlan nwork to 802.11b. we had to include -TCP_DELAY on telnet in inetd.conf file. All scanners working ok on the 802.11b network. BUT,(as usual!) we have 2 scanners working on a spectrum 1 Spring protocol. these two scanners now unable to login. Msg received is: SVTP;v2 you are at the end. From this point on we are stuck. have to reboot device. Soon as remove -TCP_DELAY from telnet statement able to login properly.
Is there any way I can set these two scanners up with there own telnet statement without the TCP_DELAY?

thanks in advance for any info.
maria

Re: telnet option impact RF scanning device

Dietmar Konermann — Fri, 18 Jun 2004 04:39:56 GMT

Maria,

one idea that comes into my mind is to setup another alternative telnet port to be used without TCP_DELAY option configured.

Example:

/etc/services:

telnet 23/tcp # Virtual Terminal Protocol
otelnet 10023/tcp # Virtual Terminal Protocol w/o TCP_DELAY

/etc/inetd.conf:

telnet stream tcp nowait root /usr/lbin/telnetd telnetd -TCP_DELAY
otelnet stream tcp nowait root /usr/lbin/telnetd telnetd

The question is if you are able to configure the telnet port to be used by your scanners.

Best regards...
Dietmar.

Re: telnet option impact RF scanning device

rick jones — Sat, 19 Jun 2004 03:24:06 GMT

Setting or not setting TCP_DELAY in telnet will only alter how data sent to the scanner is segmented (packetized) by TCP. It will not change the data itself.

That being the case, if setting or unsetting TCP_DELAY causes some of your scanners to fail, it suggests something was already wrong with the code on the scanners. Perhaps something along the lines of broken code that assumed that a 64 byte send at one end was guaranteed to be a single 64 byte receive at the other. Or that a trio of 64 byte sends at one end would be three separate 64 byte receives at the other. Those are assumptions a TCP application may not make.

So, as suggested by another post, you could setup a telnet service on an alternate port, but it really would be a good idea to try to further diagnose what might be wrong with the code in the scanners. That might involve taking packet traces.

Re: telnet option impact RF scanning device

Peter Gillis — Tue, 22 Jun 2004 20:16:36 GMT

hi again,
thank you for your answers. still experiencing some problems though....
I have setup another telnet port as suggested, added a second telnet line in both /etc/services and inetd.conf. I have made sure the telnet port can be used by the scanners. The result now is comms appears to establish, but where I would normally get the login screen, the cursor is flashing at the top left hand corner of a blank screen. Nothing appears to happen from there. Is it possible that there is some other security on the unix system stopping me from attaching to the unix system; or is it that the scanners are not able to comm from their side? Can anyone offer ways to check either of these possiblities?

thanks
Maria

Re: telnet option impact RF scanning device

Bill Hassell — Tue, 22 Jun 2004 20:54:49 GMT

The best way to troubleshoot this problem is to use a packet trace so you can see the exact message handshake. The scanners likely have very terse code and cannot provide any useful diagnostics. Even so, the scanner probably can't be fixed with new code from the manufacturer, and for that, you'd likely have to provide a document showing the improper handshake. Get a copy of Ethereal (now available for HP_UX 11.11) so you can trace the handshake. Since you know that IP address for the scanner, you can limit the trace to just that IP. Ethereal is available for PCs (along with WinPcap which listens to the pactkets). See http://www.ethereal.com for details and the recently announced Internet Express from HP: http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=HPUXIEXP1111

Re: telnet option impact RF scanning device

Peter Gillis — Tue, 22 Jun 2004 23:48:36 GMT

Bill, thanks for advice. I am running ux11.00. Have been able to run a trace on our network and found that there is NO LISTENER. Now, wonderding if all I needed to setup a new telnet port was edit /etc/services and add:
telnet 10023/tcp
then edit /etc/inetd.conf and add:
telnet stream tcp nowait root /usr/lbin/telnetd telnetd -b /etc/issue
then run: inetd -c?
Any words of wisdom on this one?

thanks,
Maria

Re: telnet option impact RF scanning device

Rajeev Shukla — Wed, 23 Jun 2004 00:31:14 GMT

Hi Maria,

cant help much but i can confirm that the procedure to add a new telnet port as described by Dietmar is correct.
I have tested and when done telnet to that port i can get connected

telnet host 10023
And yes you have to just edit /etc/services and /etc/inetd.conf and then run inetd -c for update.

Rajeev

Re: telnet option impact RF scanning device

rick jones — Wed, 23 Jun 2004 11:35:19 GMT

indeed the steps would be add a services line with your port, add an entry in inetd.conf and then inetd -c. you could do a netetst -an | grep LISTEN | grep to make sure that it "took"

when you say it appears there is "NO LISTENER" does that mean you've looked in a packet trace (tcpdump and libpcap should compile and run on 11.0 - www.tcpdump.org, or it should be in the porting archives) and you've seen the scanner send a SYN segment to the server and get an RST segment in response (perhaps with some interesting text in the RST segment :)

other thoughts - you might take a tusc trace of the inetd and tell it to be verbose, display the pid, and to follow forks and then try connecting from one of the scanners. you could then see what system calls the telnetd is making - perhaps it is checking its port number, perhaps it wants a "priviledged" port number (i can't see the previous stuff while I write this - it may be already priv'd < 1024) tusc -> ftp://ftp.cup.hp.com/dist/networking/tools/

my money is still somewhat on those scanners imp;roperly expecting data to be segmented in a particular way