HP 16700 Logic Analyser remote access using an X terminal

[LittleFrog]

Hi

EDIT:  Added some detail on other things I've tried/seen...

Quite a few people have written about this topic on this forum and elsewhere... There seem to be two camps; those for whom it works without issue and those that cannot get it to work at all.  I'm in the latter .  Sorry if I've missed the answer, but here goes...

I am trying to get my HP 16700 headless Logic Analyser to work with an X-Terminal emulator running on my Windows 10 computer.  The LA is second hand and I have no way of knowing if it's been meddled with in any way.  I have a strong feeling that it could work (based on partial success, see below).  My W10 box is running MobaXTerm.  Both systems have static IP address on the same subnet as follows;

LA	192.168.0.16
W10	192.168.0.72

I think that the "normal" way of getting remote X working is to start a telnet session with the LA and log in like this;

Code: [Select]

telnet 192.168.0.16
Logic Analysis System
Please Log in as: logic [displayname:0]
login: logic 192.168.0.72:0
Starting Session Manager on display '192.168.0.72:0'
When I do this, four pop-ups appear on the W10 display in quick succession as long as I press "Yes", each showing the prompt attached.  The telnet session is closed after about 8 seconds (even if I don't press "Yes").

The fact that my W10 box shows these prompts makes me think that;

• The X Server is running on the W10 box
• The W10 firewall is not blocking anything.

Not withstanding the above, I've tried turning off the firewall and there is no meaningful change in behavior.

An interesting thing I've found is that if I enter the following;

Code: [Select]

telnet 192.168.0.16
Logic Analysis System
Please Log in as: logic [displayname:0]
login: logic 192.168.0.16:0
Starting Session Manager on display '192.168.0.16:0'
(In other words telnet form the W10 box on to the LA but start the X Terminal session on the LA), the LA session does indeed start.  This to me means that the script or what ever it is that runs when you log in as "logic" does work, it's just that it does not work to a remote X server.

Using a prompt here;
https://www.mattmillman.com/16702b/

I've managed to make it work, but this seems like a work around.  I'd like to make starting a remote session work as (I feel) it should.  For reference, the bones of Matt's solution is to enter the following on the LA;

Code: [Select]

logic:/home/hplogic> export DISPLAY=192.168.0.31:0.0 (my IP address is .72 of course)
logic:/home/hplogic> vp &
As I say, this works, but to me, I should be able to make the first way work...

I have roamed around the LA file system looking for either an X or maybe HP-UX log of login attempts/results etc but to no avail.  I must be missing something here because this must exist; sorry if I have!

I have not enabled "Secure mode" on the LA (System Administration tools -> Security) because I don't feel that I know what I'm doing.

I have read this;
https://xdevs.com/doc/HP_Agilent_Keysight/HP%2016700A%2C%20B%20Help%20Volume.pdf

But this only seems to refer to using one LA to talk with another....  I can't map the information on to my use case.  Perhaps I need to read it all again!

The only other thing to say is that I've tried the above with and without a LA session running.  In other words, using the LA Session Manager to start (or not start) an "Exclusive session (console or remoteX)".

If anyone has any pointers, I'd be really pleased to hear from you.

Thanks for your attention.

Dave

[berke]

Maybe the "vp" command launches the logic analyzer program, which opens a regular window, but when you try to get the LA to "manage your session" it starts a session manager and/or a window manage. and there is an incompatibility there.  For example maybe MobaXTerm doesn't handle some message used by window managers but not by the regular application, or conversely maybe whatever login/window manager is launched on the LA can't handle the MobaXTerm display (pixel format or whatever.)

Personally I would run a network sniffer such as Wireshark (which comes with an X11 dissector) to see what's going on.  Traffic for display 0 is normally on TCP port 6000.  If you have a Linux machine (that could be a Pi/BBone) you could try also with a real X server, but you have to edit the server configuration as plain TCP connections are considered risky and not accepted nowadays.

[perdrix]

If you've not already visited, you may find the following link useful: http://perdrix.co.uk/hp16700/index.htm

Cheers, David Partridge

[LittleFrog]

Hi folks,

Thanks for the replies.  I'm working through David's information now but regarding Berke's Wireshark tip, I can report the following;

• I have obtained two Wireshark traces, both log all the traffic between the W10 box and 16700 LA.
• Both indicate that there is only traffic on the expected X11 and TELNET ports which I regard as to be expected and generally a good thing.
• The first is the working example created while running Matt Millman's method.  It shows me kicking off the process with telnet commands / responses and then the (quite complicated looking to my eye) X11 dialogue.  Amazing, but beyond my technical knowledge to interpret.
• The second trace shows the failed start up created by logging in as user "logic" with the IP address of the X11 server following the user name.
• I have to say that based on a visual inspection alone (might have missed something), the two traces are basically identical UNTIL the telnet session suddenly closes (disconnect from the LA end, not the client).  Then the X11 dialogue stops, but not in an orderly way; the initialisation just stops dead.

To me, the second attempt is failing because something in the LA is terminating the telnet session.  I don't know what this might be.  I've looked again for files that might hint at reasons for login attempts to fail without meaningful progress.

With all this in mind, I just created a really quick test as follows;

• Telnet on to the LA and log in as root
• Enter the following

Code: [Select]

DISPLAY=192.168.0.72:0
export DISPLAY
sam


• Then using the GUI version of sam (which starts on my W10 box no problem), create a vanilla user with it's own home directory.  new users joins a group called "users" which is fair enough I think.
• Exit sam and terminate the root telnet session
• Use telnet to log on to the LA using the new user creds
• Use vi to modify .profile in the home directory of the new user, adding the following to the bottom of the file

Code: [Select]

DISPLAY=192.168.0.72:0
export DISPLAY
vp&


• Log out of the telnet session
• Use telnet to log on to the LA again using the new user creds
• The LA session starts fine and I can use the LA remotely

So while I have not solved the original problem, I have produced a simple way of logging into the LA remotely and running an X11 session on my hi-res W10 box which is basically all I wanted to do.

As I say, I'll see if there's anything in David's LA page that could help and report back.

Thanks again for the pointers/tips.  I should declare that I'm a retired hobbyist and although this learning curve is in no way going to benefit the world at large, I'm a happy bunny .

Kind regards,

Dave

[MarkL]

For whatever it's worth, I can't get the "login: logic" method to work either.  I played around with this a little bit.

(Minor note: If you login as user "logic" without specifying the display, the system defaults DISPLAY to <incoming IP>:0.)

If you look at /etc/passwd, the user "logic" executes /usr/sprockets/bin/sessionWrapper, which in turn runs /usr/sprockets/bin/sessionMgr.  Each time "logic" logs in, a sessionMgr process is created but then sits there, even after the telnet disconnects.

I think sessionWrapper just sets up the DISPLAY and maybe other environment variables, and then calls sessionMgr.

From a normal login session as another user, you can manually export the DISPLAY environment variable and run /usr/sprockets/bin/sessionMgr by itself, and it will indeed just sit there:
  # export DISPLAY=MY_IP:0
  # /usr/sprockets/bin/sessionMgr

Both sessionMgr and sessionWrapper take a single option "-debug <DEBUGLEVEL>", but I'm not seeing any additional output for any values of DEBUGLEVEL.

Running sessionMgr in the dde debugger says that it forks /usr/contrib/bin/X11/xdpyinfo.  And it appears the actual problem is that xdpyinfo just sits there.  xdpyinfo runs fine standalone.  If you kill the xdpyinfo process, sessionMgr will run it again.  If you kill it a second time, the sessionMgr will proceed properly.  So, it's some issue with the interaction between sessionMgr and xdpyinfo.

The issue can be worked around by substituting xdpyinfo with a script that blindly outputs what xdpyinfo outputs when run on the native display:

Code: [Select]

#!/bin/sh

echo "version number:    11.0
vendor string:    Hewlett-Packard Company
vendor release number:    600000
maximum request size:  4194300 bytes
motion buffer size:  100
bitmap unit, bit order, padding:    32, MSBFirst, 32
image byte order:    MSBFirst
number of supported pixmap formats:    2
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
keycode range:    minimum 16, maximum 150
focus:  window 0x1c00327, revert to Parent
number of extensions:    14
    BIG-REQUESTS
    DOUBLE-BUFFER
    HP-SMT
    HPExtension
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    Multi-Buffering
    SHAPE
    ShareExtension
    XC-MISC
    XIE
    XInputExtension
    XTEST
    XTestExtension1
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    800x600 pixels (307x230 millimeters)
  resolution:    66x66 dots per inch
  depths (2):    1, 8
  root window id:    0x24
  depth of root window:    8 planes
  number of colormaps:    minimum 1, maximum 2
  default colormap:    0x22
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 1
  options:    backing-store YES, save-unders YES
  largest cursor:    64x64
  current input event mask:    0x58003d
    KeyPressMask             ButtonPressMask          ButtonReleaseMask       
    EnterWindowMask          LeaveWindowMask          SubstructureNotifyMask   
    SubstructureRedirectMask PropertyChangeMask       
  number of visuals:    2
  default visual id:  0x20
  visual:
    visual id:    0x20
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    8 bits"

It seems to work, but who knows what hidden side effects this will have.  I would just use the method:
  # export DISPLAY=MY_IP:0
  # vp &
It works fine.  I've been using it for years.

And if you don't want to run as root (which I do but is probably not advisable), you can re-use the userid "hplogicz" by changing the password, or create a new user with the UID/GID of 16700/16700 so that all created files will be accessible from the front panel and remotely.  See /etc/passwd on how these are set up.

[LittleFrog]

Hi Mark,

Thanks for the report.  You've been deeper into this that I am able but I think the result is that I need to proceed as you have suggested.

Thanks to others for suggestions, but I think it's time to move on...  TRIGGERS!

Well actually triggers and making a hand wired interposer for my DIP 68K...

Kind regards,

Dave

[artag]

I find I can run a remote display reliably on my Linux desktop if I :

1. 'xhost +<LA name>'
2. Telnet from the linux machine to the LA
3. Log in as root
4. 'su - logic'
5. 'vp -display <server name>:0'

The session (but not the session manager) then starts on the server as expected. This is probably the minimal part of what the perdix site explains, nothing new there but it's less steps than most.

Logging in directly as the user 'logic' fails as described by other users.fails.

I speculate that vp only opens a single session, but logic's login script attempts to start the session manager. This wants to be the window manager for the server screen, but it already has a window manager that owns the root window so it isn't permitted.

It may be that it does work for people who have started up a bare server, but not for people who's server starts up with it's own window manager, which is why people report different experiences. In addition, some are using an X server runnong under Windows, which seem to add a further set of weirdnesses to the problem. Perdrix's instructions focus on getting rid of the LA's default session manager so it avoids the problem but at the cost of a fairly involved set of changes.

It's possible that a very vanilla setup experience can probably be created using a surplus thin client / Xterminal (£10-75 on ebay). At least last time when I played with one they present an unmanaged server ready to use, since the session manager is on the host rather than in the same box, as with a Linux machine. In fact, such a server could probably be fitted inside the box to provide a much accelerated 16700, or perhaps a raspberry pi for an improved 16702 using the original LCD.

I haven't checked through every line of the above thread so apologies if somebody has already explained this , notably berke.  I find references to bits of the above explanation but I understand it better this way. Or I might be quite wrong - I have tried to point the LA to a second, unmanaged, X server on the desk PC but haven't got that to work yet.

[MarkL]

I don't use the attached screen on my 16702B, so I disable it completely.

I've found that there's no reason to endure the long initialization of "vp" twice (once on the local screen, and then again on a remote X session).  I commented it out in /etc/inittab:

  ...

  # vp commented out for faster remote use - mwl
  # uncomment only one of the following (vp or note)...
  #
  #vp  :4:respawn:/usr/sprockets/os/hplogicrc < /dev/console > /dev/console # sprockets startup
  note:4:once:echo "\n*** GUI disabled in /etc/inittab - remote use only ***" > /dev/console

  ...

The above leaves a message on the console so it's not a mystery why the standard boot up is not happening.

Then, login to the logic analyzer and:

  export DISPLAY=mylinuxbox:0
  vp &

I use rsh for login.  That allows me to set a trusted user and not bother to enter credentials.  (Obviously you would not want to expose this configuration to an un-firewalled internet connection.)  And the setting of DISPLAY can be included in .profile, so even that doesn't need to be entered.


Once you have the luxury of using your local and familiar window manager and let it manage vastly more screen space than is available on the 167xx display, you'll never go back to using the 167xx attached display.  Performance over X11 is only slightly slower than the attached display, and the tradeoff is well worth it.

[Maxis]

Hello!

Help needed!

I use 16702a with Xming+Putty under WIN10. Everything worked fine till now (use VP session over X).

But, yesterday accidentally I dropped a keyboard on the flloor keys down. And something got pressed while I was in the LA session.

PROBLEM: I can't drag the Treshold/Level and other cursors in ANY menu of X. Everything else is working fine.

I.e. some sort of a hot key was accidentally pressed, which stops the HP SW from following the action.

Otherwise the mouse seem to work normally in X with both buttons being active.

Also, if I enter via an HP web server into the shared X session, I can drag the cursors in the LA and the oscilloscope windows no problem, but it's sluggish and tiny (incomparable to the full sized windows)

What could possible go wrong?

Have you ever come across anything like this (any hotkeys)?

Thank you!

[Maxis]

Is it possible, that somehow the system.fvwm95rc file got corrupted or some VUE config files?

[MarkL]

When you say "cursors", do you mean dragging the scroll bars?  I'm not sure I understand what you're describing.  Can you give a specific example of what is failing?   E.g., what specific threshold/level menu and what are you trying to manipulate?

If you start an "xterm" from your login session, can you type normally into the window?

I would try a different workstation running an X11 server to determine if the problem is on the logic analyzer or your workstation.

Maybe your keyboard is broken?  Try a different keyboard.

[Maxis]

Thank you for your reply!

The "cursor" mean the Green and Yellow time cursors (vertical lines) in the logic analyzer Wave window. They are draggable by the mouse pointer. Same goes for Oscilloscope Trigger level (horizontal line), which can be also moved directly by the mouse pointer.
Now, when you are displacing the time cursor, automatically you have a small pop-up window which shows the time difference between the cursors.

Now, all the above functionality stopped working. BUT, when I installed XMING and PUTTY to a different computer, changed the IP addresses, cleared the cache, all these functions are again available (but from the different terminal computer).
This means that the problem is with the XMING! After re-installation of XMING on the original computer - still the same problem persists.

I don't understand at all about what's going on...

Also launched SAM on 16702 and re-selected all the options. Still doesn't help.

[MarkL]

That's very strange.

If you change the IP address of the non-working one, does it work?  Just wondering if the logic analyzer is looking at the IP address and doing something different.

Here's another thought...

The X11 server has a primitive database that can be read by clients to set application preferences like colors, fonts, and various behaviors.  Its purpose is to override default system settings on a per user basis.  It's usually loaded when the session manager starts, and entries can be modified by X11 clients on-the-fly.

Perhaps there's something different that gets set in this database between the working and non-working installations.  Try comparing the contents of the database between the two.  The command to query the database is "xrdb -q" and can be run from the logic analyzer, or XMING if it supports it.

If there is a difference, the xrdb command can also be used to adjust the database, including completely reloading all the entries.

On Linux, the database is loaded from ~/.Xresources or ~/.Xdefaults.  No clue on what windows might use if there's something odd in there.

On a side note, application resource defaults are in /usr/sprockets/env (and most of them in the file "Resources").  If you're interested, once you get this current problem fixed, it may be useful to modify some fonts and background colors to work better on larger displays.


Another utility that may be interesting is "xev", which displays input events.  Again, between the non-working and working workstations, you can ask xev to show you all input events from (for example) the oscilloscope window and see if there's any difference in server events from a mouse click or drag.  It's a client application that contacts the X11 server.  Unfortunately HP-UX does not have xev installed, but maybe XMING does.

[Maxis]

Thank you for your reply!
It took me a while to answer. Looks like the problem is somewhere else.

Here is what I don't understand at all.

1) When I connect my desktop WIN10 machine in question via the WEB interface to 16702a, I'm presented with the choice of running the X session via the external X display. When I select this X session it's dead slow but EVERYTHING works! I can move the cursors as I wish with the mouse pointer.
2) When I telnet to 16702a and run VP on the very same desktop machine, I have a problem with the cursor focus (I can't grab the trigger line or time cursors with the mouse pointer and drag it on the screen)
3) When I use my notebook with WIN10 and very same settings in PUTTY and XMING like on the desktop machine above, everything works in both cases: when starting X via the WEB interface (very slow) or when connecting via telnet and starting VP.

Here I come to an intermediate observation:
a) It's not IP address related.
b) It's not XMING settings related ( see cases 1 and 2 above) since the very same X machine behaves differently in two cases!
c) Removing and re-installing XMING and PUTTY on the desktop machine in question (erasing all the intermediate data) doesn't solve the problem
d) I couldn't find any X connection related data in the session files inside LA (many settings, but these are generic regardless the connection)

Hence, I'm puzzled. Reset all the mouse and keyboard options to default (excluding the disability settings) in WIN10 but still w/o any effect.
Could it be something still in the registry of WIN10, which remains stealth and creates such a problem?

I really don't know. But I had very same situation on the old company PC with the 16505a analyzer before (6 years ago). Had no possibility to investigate further, since that host machine went to recycling (it was running WIN7). And now again. Very same problem...... But this time with 16702a when running WIN10

[MarkL]

Starting the X session via the web interface starts a VNC client on the 16702A and sends the VNC client window to the X server (XMING).  The VNC client window contains a virtual frame buffer representing the entire screen with the applications running inside it.  So, XMING is actually interacting with the VNC client and then VNC is forwarding X11 events to the application inside the VNC window.  This layering is also why it's so slow.

When you start vp on its own, the individual application windows are sent directly to XMING, and the applications receive the X11 events directly from XMING.  This is why I described a number of tests to try with X11 events.

You could try some applications that are unrelated to the logic analyzer.  "datebook" and "dtterm" are a couple.  See if the mouse behaves ok in those.

In the scope application, if you hover over the trace, offset, ground, or markers, does the cursor change shape (indicating you can move the object)?  It should.  If it does, maybe you're having an issue with button events.

In the Workspace window (Window-->System-->Workspace...), can you drag the icons around?  E.g., try dragging a waveform display on the left into the workspace on the right.

I don't run windows, so I'm afraid my help is going to be limited to what I know is supposed to be happening on the HP-UX side.


Edit: fix path to workspace window