[9fans] just checking ...

[9fans] just checking ...

[Ronald G Minnich]

anyone yet done a ppp over gprs on plan 9?

I'm starting ...

ron

[9fans] just checking ...

[erik quanstrom]

what equipment/service provider are you going to use?

- erik

Ronald G Minnich <rminnich@lanl.gov> writes

|
|
| anyone yet done a ppp over gprs on plan 9?
|
| I'm starting ...
|
| ron

Re: [9fans] just checking ...

[Ronald G Minnich]

erik quanstrom wrote:
> what equipment/service provider are you going to use?

I'm using t-mobil, unlimited data plan for $19.95/month.

I just bought a sim card; phone is
this:http://www.sparkfun.com/commerce/product_info.php?products_id=478

I'm talking to plan 9 from cell, and have got to this point:
OK
at+cgdcont=1,"IP","internet2.voicestream.com"

OK
ATDT*99#
ATDT*99#
CONNECT

according to the t-mobil web site, I'm now ready to talk ppp.I've
started ppp as follows:
bind -a '#I' /net.alt
  ip/ppp -f -p /dev/eia0  -x /net.alt &

not having done this on plan 9, I'm not quite sure what happens next. It
seems an ip/ipconfig is in order. I'm not sure what t-mobil does for all
this; many details appear to live in a windows driver. My reading of the
various gsm docs implies that the provider has to give me a private IP
address.

/net.alt looks like this:
/net.alt/arp
/net.alt/bootp
/net.alt/esp
/net.alt/gre
/net.alt/icmp
/net.alt/icmpv6
/net.alt/il
/net.alt/ipifc
/net.alt/ipmux
/net.alt/iproute
/net.alt/ipselftab
/net.alt/log
/net.alt/ndb
/net.alt/rudp
/net.alt/tcp
/net.alt/udp
hm. what would I ipconfig against? Time to go RTFWiki

ron

Re: [9fans] just checking ...

[Steve Simon]

as I rembember ppp sets up IP addresses dns etc
for you, cat /net.alt/ndb to see what it learns

-Steve

Re: [9fans] just checking ...

[Ronald G Minnich]

erik quanstrom wrote:
> i found this on a linux-oriented howto site:
>
> 	AT+CGDCONT=1,"IP","internet2.voicestream.com","0.0.0.0",0,0
>
> the "0.0.0.0" means "assign me an ip, please".
>
> - erik
>

just realized, while walking ppp.c, that if you give it a -p /dev/eia0
it opens /dev/eia0ctl and just hardwires the baud rate to 64k ... bad deal.

I think I'm going to beat on ppp.c a bit ...

ron

Re: [9fans] just checking ...

[erik quanstrom]

cool.  gprs/edge is way faster than my current connection.
(isn't that pathetic.)

- erik

Ronald G Minnich <rminnich@lanl.gov> writes

|
| erik quanstrom wrote:
| > what equipment/service provider are you going to use?
|
| I'm using t-mobil, unlimited data plan for $19.95/month.
|
| I just bought a sim card; phone is
| this:http://www.sparkfun.com/commerce/product_info.php?products_id=478
|
| I'm talking to plan 9 from cell, and have got to this point:
| OK
| at+cgdcont=1,"IP","internet2.voicestream.com"
|
| OK
| ATDT*99#
| ATDT*99#
| CONNECT

Re: [9fans] just checking ...

[erik quanstrom]

i found this on a linux-oriented howto site:

	AT+CGDCONT=1,"IP","internet2.voicestream.com","0.0.0.0",0,0

the "0.0.0.0" means "assign me an ip, please".

- erik

Re: [9fans] just checking ...

[jmk]

On Wed Mar 22 19:08:29 EST 2006, rminnich@lanl.gov wrote:
> ...
> just realized, while walking ppp.c, that if you give it a -p /dev/eia0
> it opens /dev/eia0ctl and just hardwires the baud rate to 64k ... bad deal.
>
> I think I'm going to beat on ppp.c a bit ...
>
> ron

no it doesn't. it sets the bad to whatever you set with -b
and sets the q size to 64k.

--jim

Re: [9fans] just checking ...

[Gabriel Diaz]

Hello

that card seems to be nice for out of band management of non-mobile
equipment, isn't it better to use a usb one? i think Christoph has an
usb serial driver for plan9, that way you can use it with a notebook too :-?

gabi


On 3/23/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> erik quanstrom wrote:
> > what equipment/service provider are you going to use?
>
> I'm using t-mobil, unlimited data plan for $19.95/month.
>
> I just bought a sim card; phone is
> this:http://www.sparkfun.com/commerce/product_info.php?products_id=478
>
> I'm talking to plan 9 from cell, and have got to this point:
> OK
> at+cgdcont=1,"IP","internet2.voicestream.com"
>
> OK
> ATDT*99#
> ATDT*99#
> CONNECT
>
> according to the t-mobil web site, I'm now ready to talk ppp.I've
> started ppp as follows:
> bind -a '#I' /net.alt
>   ip/ppp -f -p /dev/eia0  -x /net.alt &
>
> not having done this on plan 9, I'm not quite sure what happens next. It
> seems an ip/ipconfig is in order. I'm not sure what t-mobil does for all
> this; many details appear to live in a windows driver. My reading of the
> various gsm docs implies that the provider has to give me a private IP
> address.
>
> /net.alt looks like this:
> /net.alt/arp
> /net.alt/bootp
> /net.alt/esp
> /net.alt/gre
> /net.alt/icmp
> /net.alt/icmpv6
> /net.alt/il
> /net.alt/ipifc
> /net.alt/ipmux
> /net.alt/iproute
> /net.alt/ipselftab
> /net.alt/log
> /net.alt/ndb
> /net.alt/rudp
> /net.alt/tcp
> /net.alt/udp
> hm. what would I ipconfig against? Time to go RTFWiki
>
> ron
>

Re: [9fans] just checking ...

[Christoph Lohmann]

Good morning.

Am Thu, 23 Mar 2006 09:54:41 +0100 schrieb "Gabriel Diaz" <gabidiaz@gmail.com>:

> Hello
>
> that card seems to be nice for out of band management of non-mobile
> equipment, isn't it better to use a usb one? i think Christoph has an
> usb serial driver for plan9, that way you can use it with a notebook too :-?
>
> gabi

The driver is at [0]. The file needs to be extracted into /sys/src/cmd/usb/misc
and then mk usbuart.install. Usage is as follows:

	% usb/usbuart;
	% con -b 115200 /n/uart/uia;

I did not submit it to sources, because I had no time to write a manpage, but
the commands to /n/uart/uiactl are the same as to /dev/eia0ctl.

Sincerely,

Christoph

[0] http://www.r-36.net/usbuart.tgz
    || /n/sources/contrib/zwansch/usbuart.tgz

Re: [9fans] just checking ...

[Ronald G Minnich]

jmk@plan9.bell-labs.com wrote:
> On Wed Mar 22 19:08:29 EST 2006, rminnich@lanl.gov wrote:
>
>>...
>>just realized, while walking ppp.c, that if you give it a -p /dev/eia0
>>it opens /dev/eia0ctl and just hardwires the baud rate to 64k ... bad deal.
>>
>>I think I'm going to beat on ppp.c a bit ...
>>
>>ron
>
>
> no it doesn't. it sets the bad to whatever you set with -b
> and sets the q size to 64k.

oops. Thanks for the correction.

how did I look at a q and read a b? These contacts are new!

ron

Re: [9fans] just checking ...

[Ronald G Minnich]

Gabriel Diaz wrote:
> Hello
>
> that card seems to be nice for out of band management of non-mobile
> equipment, isn't it better to use a usb one? i think Christoph has an
> usb serial driver for plan9, that way you can use it with a notebook too :-?
>


no usb driver for this chipset yet.

I'm allergic to usb most days, but yeah, it might be nice for this
application (oh, actually, I don't like usb at all ...)

ron

Re: [9fans] just checking ...

[Charles Forsyth]

> no usb driver for this chipset yet.

i'm currently revisiting the usb driver and when i'm done
it will then include OHCI.  i could possibly add it directly to the existing one, but
i wasn't happy with parts of the interface.  it's still a strange struggle.

Re: [9fans] just checking ...

[lucio]

>     || /n/sources/contrib/zwansch/usbuart.tgz

In usbuart.c:

	char ident[]		= "Enabled 0x0000ff 0x067b 0x2303";

Is that for real?  I've never noticed anything beyond the first "Enabled" argument, and I only get:

	Enabled 0x0000ff
	 0 0x0000ff         57 bytes          5 blocks
	 1 0x0000ff          0 bytes          0 blocks
	 2 0x0000ff          0 bytes          0 blocks
	 3 0x0000ff          0 bytes          0 blocks

for my Ericsson USB connector, which NetBSD identifies as:

	Prolific Technolgy Inc. USB-Serial Controller. rev 1.10/3.00. addr 3

++L

Re: [9fans] just checking ...

[Charles Forsyth]

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

perhaps your devusb.c and usbd are not up to date.
the latter now sets the vendor and device IDs, and the former
displays them if set

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

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] just checking ...
Date: Thu, 23 Mar 2006 20:55:19 +0200
Message-ID: <942177f118a07e7cbb4d452ca3429bcd@proxima.alt.za>

>     || /n/sources/contrib/zwansch/usbuart.tgz

In usbuart.c:

	char ident[]		= "Enabled 0x0000ff 0x067b 0x2303";

Is that for real?  I've never noticed anything beyond the first "Enabled" argument, and I only get:

	Enabled 0x0000ff
	 0 0x0000ff         57 bytes          5 blocks
	 1 0x0000ff          0 bytes          0 blocks
	 2 0x0000ff          0 bytes          0 blocks
	 3 0x0000ff          0 bytes          0 blocks

for my Ericsson USB connector, which NetBSD identifies as:

	Prolific Technolgy Inc. USB-Serial Controller. rev 1.10/3.00. addr 3

++L

Re: [9fans] just checking ...

[Christoph Lohmann]

Good evening.

Am Thu, 23 Mar 2006 20:55:19 +0200 schrieb lucio@proxima.alt.za:

> 	char ident[]		= "Enabled 0x0000ff 0x067b 0x2303";
>
> Is that for real?  I've never noticed anything beyond the first "Enabled" argument, and I only get:

You need to update your usb/usbd, as Charles mentioned.

Sincerely,

Christoph

Re: [9fans] just checking ...

[lucio]

> You need to update your usb/usbd, as Charles mentioned.

I've been "pull"ing regularly and I didn't think my in-core usbd had
been around that long.  But maybe I'm answering the wrong message.

I'll take the peek I ought to have taken already :-(

++L

Re: [9fans] just checking ...

[lucio]

> perhaps your devusb.c and usbd are not up to date.
> the latter now sets the vendor and device IDs, and the former
> displays them if set

Looks like my kernel was loaded a day too soon (1 March vs 2 March).  Thank
you, everyone.

++L

Re: [9fans] just checking ...

[lucio]

> You need to update your usb/usbd, as Charles mentioned.

I do have another question, tangentially related: How does one turn
charging on, on such a device?  Is it a separate USB function, or is
it a trick of the simulated serial device?

++L

Re: [9fans] just checking ...

[Christoph Lohmann]

Good day.

Am Fri, 24 Mar 2006 07:38:11 +0200 schrieb lucio@proxima.alt.za:

> I do have another question, tangentially related: How does one turn
> charging on, on such a device?  Is it a separate USB function, or is
> it a trick of the simulated serial device?

The device requests an amount of mA (milli Ampere) in the configuration
of the device and gets that from the USB controller. No need to set that
somewhere in userspace.

Sincerely,

Christoph

Re: [9fans] just checking ...

[Charles Forsyth]

> The device requests an amount of mA (milli Ampere) in the configuration
> of the device and gets that from the USB controller. No need to set that
> somewhere in userspace.

there can be other vendor-specific power controls for a device.
as usual for usb, enough is specified to make it complicated, but not enough
to be complete, once for all.

Re: [9fans] just checking ...

[Charles Forsyth]

> as usual for usb, enough is specified to make it complicated

to be fair, no doubt the usb2/ehci documentation read better in the original Martian

Re: [9fans] just checking ...

[lucio]

> You need to update your usb/usbd, as Charles mentioned.

Actually, no, I need to debug /sys/src/9/pc/devusb.c as it does not
detect the device the way NetBSD does.  Incidentally, its VID and DID
are as given.  At the end of the day the hack:

	... (strncmp(ident, line, strlen(ident)) == 0 || strncmp(ident, line, 16) == 0))

got me only a little bit further.  No response from the device,
though.

++L

Re: [9fans] just checking ...

[Charles Forsyth]

> Actually, no, I need to debug /sys/src/9/pc/devusb.c as it does not
> detect the device the way NetBSD does.  Incidentally, its VID and DID

it isn't really involved, except to store the values and return
them when a status file is read.  usbd does the enumeration etc.
and it tags the device with vendor and device IDs once it has
got them, by writing them in a control message ("class" i think)
to the usb device ctl file.  that's why you needed the updated
usbd as well as the usb driver.  you need the latter to implement
the message; you need the former to do the work.

{usb/usbd -v} will trace some of its actions.

the driver is not even involved much in root port detection:
even then it's just a matter of returning to usbd
values it reads from the port control registers.
that's partly because the things must be polled, and
that might as well be programmed at user level,
where one can use thread.h

Re: [9fans] just checking ...

[lucio]

> that's why you needed the updated
> usbd as well as the usb driver.  you need the latter to implement
> the message; you need the former to do the work.

Negative :-(

I have the same size binary as sources, but the USB status remains
unqualified:

	term% cat /dev/usb0/*/status
	Attached 0x000000
	 0 0x000000         40 bytes         15 blocks
	Enabled 0x000101
	 0 0x000101       1041 bytes        134 blocks
	 2 0x000201          0 bytes          0 blocks
	 4 0x000201          0 bytes          0 blocks
	Enabled 0x0000ff
	 0 0x0000ff         57 bytes          5 blocks
	 1 0x0000ff          0 bytes          0 blocks
	 2 0x0000ff          0 bytes          0 blocks
	 3 0x0000ff          0 bytes          0 blocks

...  and the modified usbuart loads, but con returns nothing from the
device.

++L

Re: [9fans] just checking ...

[lucio]

>> I do have another question, tangentially related: How does one turn
>> charging on, on such a device?  Is it a separate USB function, or is
>> it a trick of the simulated serial device?
>
> The device requests an amount of mA (milli Ampere) in the configuration
> of the device and gets that from the USB controller. No need to set that
> somewhere in userspace.

But the charging function can be turned on or off (at least on, at any
rate) on demand.  How is this done?  I've only seen it happen under
Windows, with the help of a dedicated utility.

++L

Re: [9fans] just checking ...

[Charles Forsyth]

>> that's why you needed the updated
>> usbd as well as the usb driver.  you need the latter to implement
>> the message; you need the former to do the work.
>
> Negative :-(
>
> I have the same size binary as sources, but the USB status remains
> unqualified:

it won't show vendor or device IDs at all if both are zero in your device.
as i said, usb/usbd -v will show the settings (be sure any existing usbd has been killed
before running that).  if the settings include the vendor and device ID,
but they aren't in the driver's files, i'd suspect you still aren't using the right driver or kernel binary.

Re: [9fans] just checking ...

[Christoph Lohmann]

Good evening.

Am Fri, 24 Mar 2006 16:50:22 +0200 schrieb lucio@proxima.alt.za:

> > You need to update your usb/usbd, as Charles mentioned.
>
> Actually, no, I need to debug /sys/src/9/pc/devusb.c as it does not
> detect the device the way NetBSD does.  Incidentally, its VID and DID
> are as given.  At the end of the day the hack:

Wrong. Please update your /sys/src/cmd/usb/lib/device.c and recompile the
usb/usbd with the new libusb.

Sincerely,

Christoph

Re: [9fans] just checking ...

[Christoph Lohmann]

Good evening.

Am Fri, 24 Mar 2006 20:47:51 +0200 schrieb lucio@proxima.alt.za:

> >> I do have another question, tangentially related: How does one turn
> >> charging on, on such a device?  Is it a separate USB function, or is
> >> it a trick of the simulated serial device?
> >
> > The device requests an amount of mA (milli Ampere) in the configuration
> > of the device and gets that from the USB controller. No need to set that
> > somewhere in userspace.
>
> But the charging function can be turned on or off (at least on, at any
> rate) on demand.  How is this done?  I've only seen it happen under
> Windows, with the help of a dedicated utility.

Sniff the USB Stack of Windows.

Sincerely,

Christoph

Re: [9fans] just checking ...

[lucio]

> Wrong. Please update your /sys/src/cmd/usb/lib/device.c and recompile the
> usb/usbd with the new libusb.

That was the key.  My libusb was locally manufactured and consequently
out of date.  Mind you, does it not fall outside replica/pull's
control?

Now, for some further testing...

++L

Re: [9fans] just checking ...

[lucio]

> Sniff the USB Stack of Windows.

How difficult would this be to do?  I must confess my days as a
hardware hacker are somewhat in the past.

++L

Re: [9fans] just checking ...

[Russ Cox]

> That was the key.  My libusb was locally manufactured and consequently
> out of date.  Mind you, does it not fall outside replica/pull's
> control?

Libraries that live outside /386/lib are treated like object files.
They are not shipped with the system.

Russ

Re: [9fans] just checking ...

[lucio]

> Libraries that live outside /386/lib are treated like object files.
> They are not shipped with the system.

It seems to me we ought to adjust the mkfiles in /usb to rebuild
libusb when necessary, then.  Something I'd try if I wasn't convinced
I'd battle to get it right and then somebody would anyways fix it :-(

++L

Re: [9fans] just checking ...

[Russ Cox]

> It seems to me we ought to adjust the mkfiles in /usb to rebuild
> libusb when necessary, then.  Something I'd try if I wasn't convinced
> I'd battle to get it right and then somebody would anyways fix it :-(

If you run mk in /sys/src/cmd/usb it will do all the right things.

Russ

Re: [9fans] just checking ...

[lucio]

> Now, for some further testing...

This would be an absolute treat if I could get it to work.
Unfortunately, once I've installed usbuart, I get no response whatever
from the "con" command:

	term% kill usbuart|rc
	term% usb/usbuart -d
	Found matching device at /dev/usb0/2
	Send ep 3 bulk r 32 64 to /dev/usb0/2/ctl
	Send ep 2 bulk w 32 64 to /dev/usb0/2/ctl
	Start reading and writing from /dev/usb0/2/setup
	Start writing on /dev/usb0/2/ep2data
	Start reading on /dev/usb0/2/ep3data
	term% con -b 115200 -Rs /n/uart/uia
	>>> q
	term% ls /n/uart
	/n/uart/uia
	/n/uart/uiactl
	/n/uart/uiastatus

Purely as a datapoint, I have successfully established a PPP
connection using NetBSD on the same dongle, on a different host.  I
would much rather use Plan 9, although my target use actually involves
a remote terminal.

I suppose I must persist.  Anything I ought to look at in usbuart.c?

++L

Re: [9fans] just checking ...

[Christoph Lohmann]

Good day.

Am Sat, 25 Mar 2006 19:07:03 +0200
schrieb lucio@proxima.alt.za:

> I suppose I must persist.  Anything I ought to look at in usbuart.c?

Look at the function initpl2303(). There is a big comment with undocument-
ed, vendor specific calls, that were not needed for my dongle. If that
does not work, then I will look at the NetBSD driver and see what they
did different to usbuart.c.

Sincerely,

Christoph

Re: [9fans] just checking ...

[lucio]

> Look at the function initpl2303(). There is a big comment with undocument-
> ed, vendor specific calls, that were not needed for my dongle. If that
> does not work, then I will look at the NetBSD driver and see what they
> did different to usbuart.c.

I saw those, I'll compare them and other things to the NetBSD sources.
I'll have time to do that in the week ahead.  Thanks for the
encouragement.

++L