[9fans] snoopy thinks that the cpu command talks 9p

[9fans] snoopy thinks that the cpu command talks 9p

[Alberto Cortés]

Hello.

Trying to understand how authentication works, I ended up using
snoopy on a cpu connection, something like:

    % snoopy -f 'tcp(sd=17010)'

and, on another window:

    % cpu


This will give you lots of lines that looks like:

    ninep(68656c6c6f203966616e7321)


I believe it should say something like:

    unknown(68656c6c6f203966616e7321)

or

    unknown"helo 9fans"


Maybe this brings up again the topic of dynamic loading of
modules.

-- 
Alberto Cortés

Re: [9fans] snoopy thinks that the cpu command talks 9p

[Russ Cox]

> Trying to understand how authentication works, I ended up using
> snoopy on a cpu connection, something like:
>
>     % snoopy -f 'tcp(sd=17010)'
>
> and, on another window:
>
>     % cpu
>
>
> This will give you lots of lines that looks like:
>
>     ninep(68656c6c6f203966616e7321)

Cpu *does* talk 9P, but it is usually encrypted 9P, and the
chance of 9P encrypting to an ASCII string is pretty low.

If you ran cpu -e none (not an option unless you compile
your own special copy of cpu) you would be able to see
the raw 9P traffic.

> I believe it should say something like:
>
>    unknown(68656c6c6f203966616e7321)
>
> or
>
>    unknown"helo 9fans"

There's not really any good option here, since the interesting
bits are encrypted, and saying ninep is not a lie, so I'm
inclined just to leave it alone.  There's certainly no point in
printing unknown("hello 9fans!"), since as I mentioned above,
it's either 9P or encrypted 9P, never plain text.

Russ

Re: [9fans] snoopy thinks that the cpu command talks 9p

[Alberto Cortés]

Russ Cox said:

> There's not really any good option here, since the interesting
> bits are encrypted, and saying ninep is not a lie, so I'm
> inclined just to leave it alone.  There's certainly no point in
> printing unknown("hello 9fans!"), since as I mentioned above,
> it's either 9P or encrypted 9P, never plain text.

It certainly have plain text on the first packet:

    p9 rc4_256 sha1

I am not sure if this is 9P.

And I have seen at least another packet that looks like "p9any
version 1" after that (not sure what I am saying, remember I am
trying to understand authentication with this experiment).

But then, I didn't get to the encrypted part :), and didn't know
about it so I guess you are rigth and there is no plain text
afterwards.

Labeling those first lines as whatever protocol they are can be
interesting.

-- 
Alberto Cortés

Re: [9fans] snoopy thinks that the cpu command talks 9p

[Russ Cox]

> > There's not really any good option here, since the interesting
> > bits are encrypted, and saying ninep is not a lie, so I'm
> > inclined just to leave it alone.  There's certainly no point in
> > printing unknown("hello 9fans!"), since as I mentioned above,
> > it's either 9P or encrypted 9P, never plain text.
>
> It certainly have plain text on the first packet:
>
>     p9 rc4_256 sha1
>
> I am not sure if this is 9P.

No, it's not.  There is a negotiation that happens first, specific to cpu,
and then there is a generic factotum authentication protocol that happens
afterward (if p9 is what is chosen by the cpu negotiation),
and then the bulk of the connection is in fact encrypted 9P.
Printing the hex is still the best choice: only the first little bit has
text, and even that has some NULs and the like for framing.
The auth protocol has some text strings embedded but it's mostly
binary.

Russ

Re: [9fans] snoopy thinks that the cpu command talks 9p

[Alberto Cortés]

Russ Cox said:

> No, it's not.  There is a negotiation that happens first, specific to cpu,
> and then there is a generic factotum authentication protocol that happens
> afterward (if p9 is what is chosen by the cpu negotiation),
> and then the bulk of the connection is in fact encrypted 9P.
> Printing the hex is still the best choice: only the first little bit has
> text, and even that has some NULs and the like for framing.
> The auth protocol has some text strings embedded but it's mostly
> binary.
> 
> Russ

Thanks you very much for the explanation, some things are much
more clear now.

Those few runes-as-hex sound reasonable, now that I understand a
little bit of the big picture.

-- 
Alberto Cortés