Debian, SpaceNavigator PE, 3DxWare V1.2.7,failed to get user

[miltieIV2]

I'm getting "failed to get user" (with and without sudo)

$ sudo /etc/3DxWare/daemon/3dxsrv -d usb -v
3DxWareUNIX = V1.2.7, ID 2994

$ sudo /etc/3DxWare/daemon/3dxsrv -d usb -debug
[2007-05-20 18:32:13] 3dxsrv.c,647: displayname = :0
[2007-05-20 18:32:13]
[2007-05-20 18:32:13] 3dxsrv.c :: startupCommandLine(), authGetUser(), failed to get user
[2007-05-20 18:32:13] Error: 3dxsrv.c :: startupCommandLine(), authGetUser(), failed to get user

$ sudo /etc/3DxWare/daemon/3dxsrv -debug -firmware USB
[2007-05-20 18:32:34] UdDev: Opening USB device on USB port /proc/bus/usb/002/016
[2007-05-20 18:32:34] UdDev: SpaceNavigator opened
[2007-05-20 18:32:34] UdDev: Opening SpaceNavigator device on USB port /proc/bus/usb/002/016
[2007-05-20 18:32:34] snav_usb.c :: UdDevRezero(): Rezeroing the device
Device = SpaceNavigator
Firmware = V3.18


I did an ltrace and I see a sequence where the /var/run/utmp file is being scanned with setutxent/getutxent.../endutxent, some of the netutxent calls are followed by calls to strstr() with ":0" as the second argument. It looks like it's trying to find the login record for the user on the first X display. When it scans what looks like the correct utmp record, I see this (my login is jbm):

20380 strstr(":%\001Kjbm", ":0") = NULL

It looks like something is not understanding the format of the 384 byte per entry (on my system) utmp file properly or possibly the struct the getutxent function is returning. Maybe the output of who should be parsed instead of, or as a fall-back to scanning the utmp file.


My system is Debian unstable, kernel is 2.6.18.2, glibc is 2.5

[Wally]

I hate to issue "me too" posts, but we have exactly the same behaviour for Suse 10.1 x386, version 1.2.7 from 2007-05-08.

We hope this can be resolved fast, as we currently can't use out Navigator SE at all.

Thanks for any updates on this issue!

[ssross]

I found a hack that works for me. I added a new entry in the utmp file that matches what the daemon wishes to see. It seems that; ut_user must not be empty (obvious), ut_id must contain a colon and display number (":0"), the ut_line must equal ut_id, ut_host must be empty (I think), and the type must be USER_PROCESS. Most of this was figured out by trial and error so some of this may be wrong.

On FC6, the utmp entries are not even close. ut_id="/0", ut_line='pts/0', ut_host=":0.0".

Here is a small C program that I used. Note that this has only been tested once, on Fedora Core 6, and there isn't anyway to clean up the mess this makes of utmp. But I can now spin the cube

Code: Select all

#include <stdio>
#include <string>
#include <stdlib>
#include <utmpx>

int
main(int argc, char ** argv) {
  if (argc != 2) {
    fprintf(stderr, "Need a name to put in the structure\n");
    exit(1);
  }
  struct utmpx u;
  memset(&u, 0, sizeof(u));
  u.ut_type = USER_PROCESS;
  u.ut_pid = getpid();
  strcpy(u.ut_id, ":0");
  strcpy(u.ut_line, ":0");
  strcpy(u.ut_user, argv[1]);
  setutxent();
  pututxline(&u);
  endutxent();
}



[massimo.ricci]

Impressive hacking!
I compiled the source code of ssross, and it run! (FC6 kernel .6.20-1.2933.fc6)
(except i had to add ".h" at the end of the included file names )
Great! I hope it could help the 3d connexion staff to understand the problem and fix it!
At this point I'm waiting for a new official linux driver release soon, that replaces that workaround.

Thank you very much ssross!
you have a good hacking.
Massimo

[ngomes]

Hi,

We are aware of this problem. For your information, it is internally tracked as issue 4407.

It seems that gdm is somewhat broken in FC6. See Red Hat's Bugzilla Bug 209537.

I believe the problem is fixed in FC7. Note that other tools -- like finger and who -- were also broken by this bug.

[UtaSH]

I need some more information from those Linux installations where the driver can not identify correctly the logged in user.

If you are willing to help please send me a private message with your email address and Linux details (distribution, arch, kernel). I will send you a short piece of code that reads and prints the utmp file.

This would be of great help! Thx.

[UtaSH]

With the help of our users we could fix this issue!

A beta version is available for those who encounter the problem that the driver could not identify the logged in user ("failed to get user"). Please send me a private message with your email address and your system details (Linux distribution and architecture) and I will send out the driver with the bug fix.

Uta Ludwig
3Dconnexion

[UtaSH]

The beta is now released. It is version 1.2.11 and available from our download site: http://www.3dconnexion.com/support/software

Uta Ludwig
3Dconnexion

[guyed]

The beta is now released. It is version 1.2.11 and available from our download site: http://www.3dconnexion.com/support/software

Uta Ludwig
3Dconnexion

Hi Uta,

Sorry, I'm still getting this issue even with the newer driver (on Centos 5)

# /etc/3DxWare/daemon/3dxsrv -d usb -v
3DxWareUNIX = V1.2.11, ID 3213

# /etc/3DxWare/daemon/3dxsrv -d usb -debug
[2007-08-23 15:44:52] 3dxsrv.c,651: displayname = :0.0
[2007-08-23 15:44:52] 3dxsrv.c :: startupCommandLine(), authGetUser(), failed to get user
[2007-08-23 15:44:52] Error: 3dxsrv.c :: startupCommandLine(), authGetUser(), failed to get user

# /etc/3DxWare/daemon/3dxsrv -debug -firmware USB
[2007-08-23 15:45:31] UdDev: Opening USB device on USB port /proc/bus/usb/002/002
[2007-08-23 15:45:32] UdDev: SpaceNavigator opened
[2007-08-23 15:45:32] UdDev: Opening SpaceNavigator device on USB port /proc/bus/usb/002/002
[2007-08-23 15:45:32] snav_usb.c :: UdDevRezero(): Rezeroing the device
Device = SpaceNavigator
Firmware = V3.18

The c code fix above appears to work

Cheers

[UtaSH]

Hi,

it seems that the solution that we found does not yet fit to all Linux versions. Unfortunately we can not try every Linux and every possible configuration.

But with your help hopefully we can find a solution for CentOS, too. If you agree I will send you a little tool that prints out some information, which might help us find out what is going wrong on your installation.

Please send me a private message to let me know if I can send you the code for testing.

Uta Ludwig
3Dconnexion

[CASA]

Hello all here.

I was wondering whether to open a new thread or post a reply, because my issue has to do with the same problems here mentioned.

But now, it's not a linux machine; it happens, the same thing, to a dozen or more HP C8000 workstations, with HP-UX 11.11 (we have plenty of other models, none of them affected). We have here different Spaceball devices, some of them 2003C, some 4000, and I think there is one or two 5000. All of them work through serial ports.

We have just changed around 300 machines authentication method to LDAP. The technical personnel said the problems started to appear just after that. Speaking with the users they said they always worked, but now they don't. Imho, it has nothing to do, it sounds pretty absurd. Even, I reverted a WS back to the old auth method and the problem kept on. Every C8000 with Spaceball suffers from it.

Our spaceball drivers are v. 7.3 and 9.2. I have downloaded the recent drivers, tested them, but no success. The symptoms are similar to those, the daemon starts up, doesn't seem to hold on to a serial port, and after a while its PID is 'given' from uid 0 to the user's uid, in some cases it gets the serial port and in other it doesn't. Then, it stops to work. Or never works, who knows. /tmp/sball.txt throws "Unable to connect to X server after 3 minutes".

There are no plans to change all these spaceballs unless stated. My opinion is that it seems a serial port hardware problem or misconfiguration, but the behaviour of the driver is what most intrigues me. Ask me the output or files you want to know about, I have them all, even more.

Thanks.

[UtaSH]

Hi CASA,

your problem is something different.
The SpaceBall 2003 aren't supported since a while. The current driver does not recognize these devices. Driver version 7.3 and 9.0 is a very old driver, which was called Spaceware and was made by Labtec. This was the company that created the first Spaceball models. The driver was definitely not made for or tested with HPUX 11.x. And I am not at all familiar with it, so I can not help here.

With the latest driver, which is 3DxWareUnix version 1.2.11 you can activate the logging by adding the options -debug -E to the start of the driver. Please let us know what you find there.

Do you get any message if you start the driver from the command line?

Regards,
Uta Ludwig
3Dconnexion

[CASA]

Hi CASA,

your problem is something different.
The SpaceBall 2003 aren't supported since a while. The current driver does not recognize these devices. Driver version 7.3 and 9.0 is a very old driver, which was called Spaceware and was made by Labtec. This was the company that created the first Spaceball models. The driver was definitely not made for or tested with HPUX 11.x. And I am not at all familiar with it, so I can not help here.

With the latest driver, which is 3DxWareUnix version 1.2.11 you can activate the logging by adding the options -debug -E to the start of the driver. Please let us know what you find there.

Do you get any message if you start the driver from the command line?

Regards,
Uta Ludwig
3Dconnexion

Sure. This is what I get with the current drivers (I tried 3dx driver but it said the connected spaceball was not supported, as you said), in one of the stations:

Code: Select all

root-dpshp317:/>/etc/SpaceWare/spaceballd -nb -d /dev/tty0p0 -debug -e
UdDev: Opening Spaceball 4000 device on serial port /dev/tty0p0

UdDev: Failed to get 4000 firmware version - no device detected

UdDev: Opening Spaceball 2003 or 3003 device on serial port /dev/tty0p0

UdDev: Spaceball 2003C opened

UdCtl: calling XOpenDisplay with display=:0

Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
No connection to Xserver :0 - aborting


I made the 'xhost +' on the machine via .profile, .dtprofile, /etc/profile, no success. Erased the .Xauthority file, same. Exported DISPLAY to my IP, same. This is being done by a terminal session.

All processes not traced by tusc, I mean, typical error log messages, point to a X server refuse. Even those run by the user in the same machine.

Yes, our SB were made by Labtec; HP offers us solutions and "help" for cases like these, but they told us support for these devices is now done by 3dconnexion.com.

What other dumps, logs could I attach? What should I give permissions to (file, socket, characted devices)? I could bury you in data as I did on the HP support guy (maybe I caused him a core dump and surrendered)

[UtaSH]

Hey,

at least you are still in a good temper and jocular. Hopefully I am not changing your high spirits ...

Look - the driver you have was made a long time ago. I wasn't involved and hence don't know about it. And at this time no HPUX 11 existed. Therefore I think this is an OS issue. This driver version is not compatible to the OS version you have. Maybe someone else has an idea.

I am really willing to help with the supported devices and the actual driver. Did you try a Spaceball 4000 or 5000 with 3DxWareUnix?

Uta

[CASA]

Hey,

at least you are still in a good temper and jocular. Hopefully I am not changing your high spirits ...

Look - the driver you have was made a long time ago. I wasn't involved and hence don't know about it. And at this time no HPUX 11 existed. Therefore I think this is an OS issue. This driver version is not compatible to the OS version you have. Maybe someone else has an idea.

I am really willing to help with the supported devices and the actual driver. Did you try a Spaceball 4000 or 5000 with 3DxWareUnix?

Uta

The driver seems to work fine as there are more HP-UX 11.11 with different types of Spaceball and these driver versions. I know there are some SBall 4000 out there, but not in the troubled machines. They work fine with every driver. I'll try some things:

- attach a SB 4000 and try;
- try to locate an USB one and try;
- try at any cost to enable the driver to contact with the X Windows. All error message scream it's unable to contact with :0.

Don't worry, you can't change my mood, things like these problems keep me alive Well, they keep us all computer people alive...