[9fans] just checking ...
Ronald G Minnich
anyone yet done a ppp over gprs on plan 9?
I'm starting ...
ron
erik quanstrom
- erik
Ronald G Minnich <rmin...@lanl.gov> writes
Ronald G Minnich
> 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
Steve Simon
for you, cat /net.alt/ndb to see what it learns
-Steve
erik quanstrom
(isn't that pathetic.)
- erik
Ronald G Minnich <rmin...@lanl.gov> writes
|
erik quanstrom
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
Ronald G Minnich
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
j...@plan9.bell-labs.com
> ...
> 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
Gabriel Diaz
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
Christoph Lohmann
Am Thu, 23 Mar 2006 09:54:41 +0100 schrieb "Gabriel Diaz" <gabi...@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
Ronald G Minnich
oops. Thanks for the correction.
how did I look at a q and read a b? These contacts are new!
ron
Ronald G Minnich
> 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
Charles Forsyth
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.
lu...@proxima.alt.za
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
Charles Forsyth
the latter now sets the vendor and device IDs, and the former
displays them if set
Christoph Lohmann
Am Thu, 23 Mar 2006 20:55:19 +0200 schrieb lu...@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
lu...@proxima.alt.za
> 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
lu...@proxima.alt.za
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
lu...@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?
++L
Christoph Lohmann
Am Fri, 24 Mar 2006 07:38:11 +0200 schrieb lu...@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
Charles Forsyth
> 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.
Charles Forsyth
to be fair, no doubt the usb2/ehci documentation read better in the original Martian
lu...@proxima.alt.za
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
Charles Forsyth
> 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
lu...@proxima.alt.za
>> 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
lu...@proxima.alt.za
> 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
Charles Forsyth
>> 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.
Christoph Lohmann
Am Fri, 24 Mar 2006 16:50:22 +0200 schrieb lu...@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
Christoph Lohmann
Sniff the USB Stack of Windows.
Sincerely,
Christoph
lu...@proxima.alt.za
> 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
lu...@proxima.alt.za
How difficult would this be to do? I must confess my days as a
hardware hacker are somewhat in the past.
++L
Russ Cox
> 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
lu...@proxima.alt.za
> 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
Russ Cox
> 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
lu...@proxima.alt.za
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
Christoph Lohmann
Am Sat, 25 Mar 2006 19:07:03 +0200
schrieb lu...@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
lu...@proxima.alt.za
> 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