Re: [9fans] aan for drawterm

Re: [9fans] aan for drawterm

[andrey mirtchovski]

> Now that drawterm supports ssl (Thanks Richard), is anyone working on
> aan for drawterm?  I can see where it should go in, by comparing
> drawterm to exportfs.  Is it really as simple as starting a proc that
> runs the aan function?

you'd have to filter all traffic through aan on both sides.  afaik it
only speaks 9p2000...

[9fans] aan for drawterm

[9nut]

Now that drawterm supports ssl (Thanks Richard), is anyone working on
aan for drawterm?  I can see where it should go in, by comparing
drawterm to exportfs.  Is it really as simple as starting a proc that
runs the aan function?

Re: [9fans] aan for drawterm

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Yup.  Hopefully we'll have Rocks soon and won't need aan
anymore.  The intent is to make a dial string like

	rocks!host!service

to replace any call like

	tcp!host!service

so that an aan like service will be available to all
services without having to build aan into every program.

[-- Attachment #2: Type: message/rfc822, Size: 2034 bytes --]

From: 9nut@9netics.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] aan for drawterm
Date: Wed, 25 Feb 2004 15:00:01 -0800
Message-ID: <a1f7f06996b4da6c2fc19175c9d5f221@9netics.com>

> you'd have to filter all traffic through aan on both sides.  afaik it
> only speaks 9p2000...

'aan.c' seems to be protocol neutral. Did I miss something?
srvold9p already takes care of the conversion on the Plan9
side; it should look something like this:
(drawterm+aan)↔(aan)↔(srvold9p)↔(cpu)

Re: [9fans] aan for drawterm

[9nut]

> you'd have to filter all traffic through aan on both sides.  afaik it
> only speaks 9p2000...

'aan.c' seems to be protocol neutral. Did I miss something?
srvold9p already takes care of the conversion on the Plan9
side; it should look something like this:
(drawterm+aan)↔(aan)↔(srvold9p)↔(cpu)

Re: [9fans] aan for drawterm

[Derek Fawcus]

On Wed, Feb 25, 2004 at 05:59:37PM -0500, David Presotto wrote:
> Yup.  Hopefully we'll have Rocks soon and won't need aan
> anymore.  The intent is to make a dial string like
>
> 	rocks!host!service

rocks?

Re: [9fans] aan for drawterm

[boyd, rounin]

> rocks?

yes projectiles.  you chuck 'em, i shoot you with an MP5-A3SD.

Re: [9fans] aan for drawterm

[9nut]

> Yup.  Hopefully we'll have Rocks soon and won't need aan
> anymore.  The intent is to make a dial string like
>
> 	rocks!host!service
>
> to replace any call like

Any specifications for rocks to perhaps start work on for drawterm?

Re: [9fans] aan for drawterm

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 37 bytes --]

Look for Vic Zandy's paper in google.

[-- Attachment #2: Type: message/rfc822, Size: 1942 bytes --]

From: 9nut@9netics.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] aan for drawterm
Date: Wed, 25 Feb 2004 23:26:25 -0800
Message-ID: <a64882b88bbaeb498c922974ba68225c@9netics.com>

> Yup.  Hopefully we'll have Rocks soon and won't need aan
> anymore.  The intent is to make a dial string like
>
> 	rocks!host!service
>
> to replace any call like

Any specifications for rocks to perhaps start work on for drawterm?

Re: [9fans] aan for drawterm

[Philippe Anel]

http://www.cs.wisc.edu/paradyn/papers/#rocks

[9fans] rocks

[rog]

> Look for Vic Zandy's paper in google.

google wasn't very helpful in this respect for me, but
i did find it indirectly after a bit.

for others' benefit, this page points towards
the paper:

http://www.cs.wisc.edu/~zandy/rocks

Re: [9fans] rocks

[vic zandy]

> http://www.cs.wisc.edu/~zandy/rocks

is the right place to go for the code and paper.

But the code (for linux) linked there is regretfully old.

The curious can grab
http://www.cs.wisc.edu/~zandy/rocks/rocks-latest.tar.gz
for all committed updates.

There are several bugs and a couple feature re-designs
that before this week I didn't have time to even think
about.  These fixes will need to go in before I push
out another version of that code.

That tarball also has the (undocumented) port to
Windows that Greg Quinn at Wisconsin wrote.

Drawterm on Linux and Windows is just another tcp
client, so it will work with rocks once plan 9 speaks
rocks.

[9fans] Newbie installation error - IBM 300 GL

[Andy Clements]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

Hello 9 fans,

I'm trying to install Plan 9 on an IBM 300 GL desktop via floppy disk.
I have done this successfully before with a similar IBM 300 GL desktop,
the only difference between the two machines is the working one has a
faster processor, CD-ROM & an slightly older BIOS date.

I get the following message when attempting to install Plan 9: (retyped
from notes - so there may be inconsistencies)

init: stating  /bin/rc
dossrv: serving #s/dos
/n/a:/vgainfo.txt: rc: can't open :clone failed.

init: starting /bin/rc
%

 From what I understand of the installation process from the wiki, the
OS is trying to write the aux/vga information to the floppy disk.  It
seems to fail in it's attempt to write to the disk.  When I go to /n/a:
and attempt to access any of the files, I recieve the message "clone
failed".  Can I assume this is possibly a hardware problem and my floppy
drive is defective - or is there something else?

Being that I have installed successfully on a similar machine, I assume
that the vgainfo.txt & pci.txt from that machine would be valid for this
one.  I added these files to the floppy and re-tried the installation,
however, the installation stopped again in it's attempt to write to the
disk.  My question is this, can I edit the script for the process to
skip the aux/vga -p >/n/a:vgainfo.txt step and just read the vgainfo.txt
I already have there?  If this is possible, can someone point me to the
place where this script is located.

I have added the plan9.ini of the broke installation and the vgainfo.txt
& pci.txt files of the working installation for perusal.

Thanks for your help in advance

--Andy Clements


[-- Attachment #2: vgainfo.txt --]
[-- Type: text/plain, Size: 3225 bytes --]

main->snarf
vga->snarf
clgd542x->snarf
vga->attr: 0xC0039=CL-GD5436/46 PCI VGA BIOS Version
vga->dump
vga misc             67
vga feature          00
vga sequencer        03 00 03 00 02
vga crt              5F 4F 50 82 55 81 BF 1F - 00 4F 0D 0E 00 00 06 40
                     9C 8E 8F 28 1F 96 B9 A3 - FF
vga graphics         00 00 00 00 00 10 0E 00 - FF
vga attribute        00 01 02 03 04 05 14 07 - 38 39 3A 3B 3C 3D 3E 3F
                     0C 00 0F 08 00
vga virtual         0 0
vga panning         off
vga clock[1] f      135000000
vga clock[1] d i m          0        0       -        0
vga clock[1] n p q r        0        0       -        0        0
vga vm a b           16777216        0
vga vmz              16777216
vga apz                     0
vga linear                  1
clgd542x->dump
clgd542x flag        Ulinear|Hlinear|Fsnarf
clgd542x Seq06       12 00 83 B0 33 4A 5B 42 - 7E 1B 00 00 00 00 10 03
                     08 21 40 00 00 2B 2F 1F - 33 2D
clgd542x Crt19       00 00 00 00 00
clgd542x Gr09        00 00 00 FF 00 00 00 FF - FF FF FF FF FF 37 00 04
                     00 FF FF FF FF FF FF FF - 1F FF 07 FF 1F FF 1F FF
                     FF 3F 00 FF FF 3F 00 00 - 00 00 00 FF FF 00 00 00
                     00
clgd542x Id Hdr      B8 00

vmf 0 vmdf 40000000 vf1 135000000 vbw 75000000
using frequency 56818080 rr 85.00 membw 40800000
vga->init
clgd542x->init
clgd542x->init->clgd54xxclock
dbdumpmode
type=multisync75, size=800x600x8
frequency=56818080
x=800 (0x320), y=600 (0x258), z=8 (0x8)
ht=1056 (0x420), shb=840 (0x348), ehb=1000 (0x3E8)
shs=840 (0x348), ehs=1000 (0x3E8)
vt=633 (0x279), vrs=605 (0x25D), vre=607 (0x25F)
hsync=0, vsync=0, interlace=0
vga->attr: 0xC0039=CL-GD5436/46 PCI VGA BIOS Version
vga->dump
vga flag             Fdump|Finit|Fsnarf
vga misc             EF
vga feature          00
vga sequencer        03 01 0F 00 0A
vga crt              7F 63 68 9D 69 9D277 F0 - 00 60 00 00 00 00 00 00
                    25D 2F257 64 6025D25E A3 -7FF
vga graphics         00 00 00 00 00 50 05 0F - FF
vga attribute        00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
                     41 FF 0F 00 00
vga virtual         800 600
vga panning         off
vga clock[0] f       56810843
vga clock[0] d i m         31        0       -        0
vga clock[0] n p q r      123        0       -        0        0
vga clock[1] f      135000000
vga clock[1] d i m          0        0       -        0
vga clock[1] n p q r        0        0       -        0        0
vga vm a b           16777216        0
vga vmz              16777216
vga apz                     0
vga linear                  1
clgd542x->dump
clgd542x flag        Ulinear|Hlinear|Fdump|Fsnarf
clgd542x Seq06       12 01 83 B0 33 4A 5B 42 - 7B 3B 00 00 00 00 10 03
                     08 21 40 00 00 2B 2F 1F - 3E 2D
clgd542x Crt19       00 90 22 00 00
clgd542x Gr09        00 00 20 FF 00 00 00 FF - FF FF FF FF FF 37 00 04
                     00 FF FF FF FF FF FF FF - 1F FF 07 FF 1F FF 1F FF
                     FF 3F 00 FF FF 3F 00 00 - 00 00 00 FF FF 00 00 00
                     00
clgd542x Id Hdr      B8 00

main->exits

[-- Attachment #3: pci.txt --]
[-- Type: text/plain, Size: 311 bytes --]

0.0.0:	06.00.00 8086/7030   0
0.1.0:	06.01.00 8086/7000   0
0.1.1:	01.01.80 8086/7010   0 4:0000fff1 16
0.1.2:	0c.03.00 8086/7020  11 4:00005441 32
0.11.0:	04.01.00 1274/1371  11 0:00005401 64
0.12.0:	02.00.00 1186/1300  10 0:00005001 256 1:60000000 256
0.8.0:	03.00.00 1013/00b8 255 0:40000008 16777216

[-- Attachment #4.1: Type: text/plain, Size: 309 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/plain;
 name="PLAN9.INI"
	Content-Transfer-Encoding: 7bit
	Content-Disposition: inline;
 filename="PLAN9.INI"

[-- Attachment #4.2: PLAN9.INI.suspect --]
[-- Type: application/octet-stream, Size: 371 bytes --]

*nomp=1
distname=plan9
nobootprompt=local!/boot/bzroot
debug=1

# serial console on COM1
#console=0

# disable ether and usb probing
#*nousbprobe=1
#*noetherprobe=1

monitor=multisync65
vgasize=680x480x8
mouseport=ps2
bootfile=fd0!dos!9pcflop.gz
installurl=http://204.178.31.2/magic/9down4e/compressed/1077139799.aejq2nggky8svt7ijewpsyqwqp2e3hi7

Re: [9fans] aan for drawterm

[Peter Bosch]

>> you'd have to filter all traffic through aan on both sides.  afaik it
>> only speaks 9p2000...
>
> 'aan.c' seems to be protocol neutral. Did I miss something?

s/seems to be/is/

Re: [9fans] aan for drawterm

[andrey mirtchovski]

>>> you'd have to filter all traffic through aan on both sides.  afaik it
>>> only speaks 9p2000...
>>
>> 'aan.c' seems to be protocol neutral. Did I miss something?
>
> s/seems to be/is/

my bad, I was left with the impression that aan sits behind the server
recording 9p messages before sending them off to the net.  looking at
the source it's obvious it doesn't know anything about 9p's
structure...

andrey