mandos general protection error

[Teddy Hogeborn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dick Middleton <dick at fouter.net> writes:

>>> Trying to connect - nothing much happens; reports error:
>>>
>>> sendmsg() to 0:0:ff02:: failed: Operation not permitted
>>
>> It seems that it fails to use Avahi to find the ZeroConf service.
>> Do you have the avahi-daemon installed?
>
> It seems to be there (on client and server).  I assume it's the one
> on the server that matters?

Actually, the client might not, in theory, work very well with an
Avahi server running.  (We've never actually had any problems with it,
but the theory is sound.)  This is not usually a problem, since the
client normally runs during startup in the initial RAM disk
environment, before any Avahi daemon is started.  This is also why the
client uses a special way to do ZeroConf/Avahi stuff which does not
need - and may very well clash with - any existing Avahi daemon.
Again, we haven't had a problem with it, but while running the client
in a normal booted system (for testing purposes) you may want to try
running the client without any Avahi daemon running (just stop it
temporarily).

>> Is IPv6 support installed?
>
> That's a good question.  I think so but I don't know how to prove
> it.  It's possible IPv6 is disabled in some significant application.

Run "ip addr list".  If your network interface has an inet6 address on
it, you have activated IPv6 support in your kernel.

> The server is Debian Lenny but nothing is installed unless
> needed. I.e. basic system, no X etc.

Sounds good.

>> You could try to use "strace" when starting mandos-client
>
> I've attached that (xxx.gz)

Right, thank you.  That log does seem to indicate a possible conflict
with the Avahi server.  Please try to run the client without any Avahi
server running on the client computer.

>> without - --connect and send us the output;
[...]
>> problem lies.  What user are you running mandos-client as?
>
> root both ends.

Good, good.

>>> Anyway if I use --connect on mandos-client then it seems to run OK
>>> until it gets a GPG error (see attached).
>>
>> "--connect" with mandos-client bypasses Avahi/ZeroConf
>> completely. Here I have no idea why it doesn't work, and I haven't
>> been able to reproduce it.  Any manual installations of
>> GnuTLS/libgcrypt11?
>
> The gremlins are at work! I don't use gpg except where Debian has
> installed it for its own key checking.  I had a bit of bother
> installing the mandos keys as a result.  Maybe there's something
> missing.

I don't think so.  GPG is not used at all except when generating new
keys during installation, and when the client needs to decrypt the
data received from the server.  From what I can see, you haven't gotten
it to work that far yet.  The server doesn't use GPG at all.

Note: When I say "GPG", I mean the program commonly known as "GnuPG".
Both the server and client handles OpenPGP-style *keys*, generated at
install time on the client by a shell script calling GnuPG.  These
keys are located in the "/etc/keys/mandos" directory.  If you suspect
something may be wrong with them, and you might be correct, you may
want to try to regenerate them using "mandos-keygen".  (This will
necessitate running "mandos-keygen --password" again.)

> Same with avahi.  No idea what it's for - it's only installed
> because some app demanded it.  Could be a configuration problem with
> that.

I don't think Avahi needs configuring; we certainly haven't changed
any settings for Avahi here.

Avahi is the ZeroConf daemon; normally, when some program wants to
announce a ZeroConf service to the local network, it asks (via D-Bus)
the Avahi server to do it; the Avahi program does all the actual mDNS
announcements, since only one program can listen to the mDNS port.

> I get the same symptoms on 2 different client systems.
>
>>> On the server in syslog I get:
>>>
>>> Jan 22 19:24:20 Geronimo kernel: [769771.374160] mandos[22960] general
>>> protection ip:b7a6b4bc sp:bfa94dd4 error:0 in
>>> libgcrypt.so.11.4.4[b7a49000+66000]
>>
>> That sounds seriously weird.
>
> I think the client side should be debugged first however sss.gz has
> session with general protection error (only seen in syslog and at
> client).  This is using --connect again.

Unfortunately, that log didn't help as much as I hoped it would.  The
strace command didn't trace the forked processes, which is where
client connections are handled.  If you could do it again using
"strace -f", I would be much obliged.  And please send the log
separately to "mandos at fukt.bsnet.se" instead of to the list; I
wouldn't want list subscribers to be inconvenienced by very large
attachments.

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJefRBOWBmT5XqI90RArmlAKCgHfc6PF5yOpw0xMBEffGkBQ+LDwCgqIhD
a9Bw8gJxmfMfgOG7NxGkdd0=
=a9MZ
-----END PGP SIGNATURE-----