Menu
▾
▴
netconsole-devel — Developer mailing list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(29) |
Mar
(3) |
Apr
|
May
(2) |
Jun
(6) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lee <lee...@ko...> - 2005-03-28 13:43:59
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=euc-kr">
<meta name="generator" content="Namo WebEditor v5.0">
</head>
<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red">
<div align="left">
<table style="margin-top:7; margin-right:5; margin-left:10;" cellspacing="0" width="665" bordercolordark="white" bordercolorlight="black" cellpadding="0">
<tr>
<td align="left" valign="top" style="border-bottom-width:1; border-bottom-color:rgb(204,204,204); border-bottom-style:solid;">
<p><font face="Arial" color="#0000CC"><span style="font-size:10pt;">Dear sir,<br><br>We are
pleased to introduce our new product "<b>MP4 Player"</b> via your internet site.<br>Please
let me know if you have interested in your marketing, then we
will provide more detail specification for your evaluation.<br><br>We are looking forward to hearing
from you.<br> Kind
Regards,<br>Mr. Lee / WA Corp. from South Korea. <br>E-mail : </span></font><a href="mailto:lee...@ko..."><span style="font-size:10pt;"><font face="Arial" color="#0000CC">lee...@ko...</font></span></a><font face="Arial" color="#0000CC"><span style="font-size:10pt;"><br><br></span></font></p>
</td>
</tr>
<tr>
<td width="680" align="left" style="border-top-width:1; border-bottom-width:1; border-top-color:rgb(204,204,204); border-bottom-color:rgb(204,204,204); border-top-style:solid; border-bottom-style:double;">
<span style="font-size:10pt;"><font color="#333333"><br></font></span> <table style="margin:5;" border="1" cellspacing="0" width="609" bordercolordark="white" bordercolorlight="#CCCCCC">
<tr>
<td width="603" align="left"> <p><span style="font-size:10pt;"><font color="blue">MP4
Player 2010M</font></span></p>
</td>
</tr>
<tr>
<td width="603" align="left">
<p align="left"><span style="font-size:10pt;"><font color="#333333"><br></font></span><SPAN class="style3" style="font-size:10pt;"><b>Product Description: </b></SPAN><span style="font-size:10pt;"><BR>1. Support MPX, MPEG I/II
Layer 2/3,8-44Kbps MP3, WMA format.<BR>2. SP/LP digital recorder function(SP can
record 4 hours and LP can record for 21 hours)<BR>3. With USB disk function.
support USB Mass Storage, Don't need driver for OS advanced than Win98<BR>4. ID3
Editor, Display lyric and sound at the same time. <BR>5. Support Language:
Simple Chinese/Traditional Chinese/English three language.<BR>6. TXT file
reading<BR>7. With FM radio(can automatically search channel) .<BR>8. Real color
65535 colours<BR><br> </span><IMG src="http://www.eton-tech.net/products_img/et-2010ms.gif"><span style="font-size:10pt;"><br><br><br></span></p>
<div align="left">
<TABLE cellSpacing=0 width="100%" border=0>
<TBODY>
<TR>
<TD vAlign=top align=right width="25%">
<p align="left"><STRONG><span style="font-size:10pt;">Product size: </span></STRONG></TD>
<TD width="74%">
<p align="left"><span style="font-size:10pt;">Diameter: 55mm, H: 15mm </span></TD></TR>
</TBODY></TABLE>
</div>
<p align="left"><span style="font-size:10pt;"> </span></p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
</body>
</html>
|
|
From: Ulisses <ra9...@ic...> - 2002-08-07 22:55:50
|
... -- Ulisses |
|
From: ULISSES F. F. DA S. <ra9...@ic...> - 2001-12-13 19:25:47
|
Hi, I'm curious if there is an easy way of add input processing like SysRq to Ingo's netconsole module. Even if there is no easy way, anyone can explain to me what I have to do? I would appreciate any help. Thanks, -- Ulisses |
|
From: H. P. A. <hp...@zy...> - 2001-09-27 22:10:57
|
Something I was thinking about... and feel free to tell me that I'm an idiot, but is there any reason that printk logging output -- as opposed to /dev/console and sysrq output -- couldn't simply use syslog protocol, which is UDP anyway? -hpa |
|
From: H. P. A. <hp...@zy...> - 2001-09-27 20:42:14
|
Ookhoi wrote: >> >>more about features and limitations can be found under: >> >> Documentation/networking/netlogging.txt >> >>reports, comments, suggestions welcome. >> > > Somebody more or less asked this already, but, will things like SysRq > work in the future? That would be great. :-) Thnx! > SysRq, as well as input in general (think single-user mode), I think it is an absolute necessity. As far as the handling of the MAC address is concerned, I would like to suggest that netconsole asks the conventional IP stack to ARP the target address for it periodically (in most/many cases it will be a fait accompli, and will be in the ARP cache) -- until the first such ARP transaction, using the broadcast address should be just fine. I don't think there is any reason to support any other network stack than IP, and UDP is definitely the way to go. If it wasn't for the fact that too many networks today are routed to a very low level I would seriously suggest using raw layer 2 frames, but I don't think that's a practical option these days. We should have a default port number for this application. I would like to suggest one for source and one for destination, like bootp/dhcp, since that would avoid having to dynamically assign a port from the normal IP stack. It also is necessary to make input possible before the server has seen any client packets, and helps avoid spoofing. Until the protocol is better defined we can't submit an IANA request for an official port number, but I hereby officially suggest (kudos to /dev/random) that the server (the concentrator) should run on port 4514 and the client (the host being logged) should run on port 4515. On the input side, I would like to suggest that we, telnet-style, reserve \xFF as an escape code; \xFF\xFF representing a single \xFF byte. In the spirit of DHCP, I suggest adopting a format \xFF<opcode><len>... for the special sequences, with \xFF\x00\x01<code> for SysRq-<code> and the rest for future use. The length field allows a kernel which gets a code sequence that it doesn't know to ignore it. Obviously, such a code sequence should never be broken up between multiple packets. -hpa |
|
From: Ookhoi <oo...@dd...> - 2001-09-27 14:34:35
|
Hi Ingo, > this is the first public release of the 'netconsole patch', a debugging > patch that implements kernel-level network logging via UDP packets. Is this different from the netconsole project on sourceforge? The last message on that lists seemes to be from july, and you didn't cc it. > the kernel patch (against 2.4.10 or 2.4.9-ac), and a simple user-space > tool to display netconsole messages can be found at: > > http://redhat.com/~mingo/netconsole-patches/ Can you also make older patches available for testing? The current netconsole-2.4.10-B1 doesn't seem to work for me on plain 2.4.10 or 2.4.9-ac15 patched with Rik his latest vm patch. The patch applies fine, but I can't load the module: cuddle:~# uname -a Linux cuddle 2.4.9-ac15 #1 Thu Sep 27 13:54:51 CEST 2001 i686 unknown cuddle:~# insmod netconsole dev=eth0 target_ip=0x0a604875 source_port=6666 target_port=5555 Using /lib/modules/2.4.9-ac15/kernel/drivers/net/netconsole.o /lib/modules/2.4.9-ac15/kernel/drivers/net/netconsole.o: init_module: Operation not permitted Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters The same message for plain 2.4.10, and the same when I use the script netconsole-server included in netconsole-client-20010927. I also tried it with the target_eth_byte0 thingies, with the mac address from the local nic. Target ip address is 10.96.72.117 (I hope 0x0a604875 is oke) > sample startup of the netconsole on the server: > > insmod netconsole dev=eth1 target_ip=0x0a000701 \ > source_port=6666 \ > target_port=6666 \ > target_eth_byte0=0x00 \ > target_eth_byte1=0x90\ > target_eth_byte2=0x27 \ > target_eth_byte3=0x8C \ > target_eth_byte4=0xA0 \ > target_eth_byte5=0xA8 > > and on the client: > > # ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666 > [...network console startup...] > netconsole: network logging started up successfully! > SysRq : Loglevel set to 9 > > more about features and limitations can be found under: > > Documentation/networking/netlogging.txt > > reports, comments, suggestions welcome. Somebody more or less asked this already, but, will things like SysRq work in the future? That would be great. :-) Thnx! Ookhoi |
|
From: Alastair M. <Ala...@eu...> - 2001-07-17 15:21:10
|
Hi, Is there any progress or plans to do anything? Any docs to read, work to do for a contributor - Alastair |
|
From: Ghozlane T. <gt...@pr...> - 2001-06-22 13:14:30
|
Hi, I just wanted to know if the project is still alive, and if so what are the "news" ... basicaly did a decision concerning UDP vs TCP has been done, the protocol, security, and so on... thank you, ghoz |
|
From: Ruben M. <rub...@ep...> - 2001-06-01 16:50:46
|
Here you'll find a short version of the TCP vs UDP discussion: http://kt.zork.net/kernel-traffic/kt20010302_109.html#2 Ruben ***************************************************************** Ruben Merz rub...@ep... http://in3www.epfl.ch/~rmerz Communication Systems Department dscwww.epfl.ch Swiss Federal Institute of Technology - Lausanne www.epfl.ch ***************************************************************** ------------------------------------------------- This mail sent through IMP: imap.epfl.ch |
|
From: James S. <ja...@ca...> - 2001-06-01 16:34:54
|
On Fri, 1 Jun 2001, William R Sowerbutts wrote: > On Fri, Jun 01, 2001 at 03:21:30PM +0100, James Sutherland wrote: > >On Fri, 1 Jun 2001, Ferric wrote: > > > >> hi, > >> > >> was a decision regarding which protocol (TCP|UDP) was going to be > >> used taken? if so, has the stack already been written? > > > >UDP, and not yet: still waiting for protocol definition... I'm very busy > >for the next week or two, then hope to do make a start on some code then. > > Part IB exams, eh? ;-) I've got my Part IIs starting Tuesday ... cane ... > > May I ask the reasons behind using UDP rather than TCP? Surely we will end up > reimplementing a number of the features offered by TCP such as automatic > retransmission, data integrity, rearrangement of packets that arrive > out-of-order, etcetera. Yes, there will be some duplication of effort, but remember one environment to support is boot-time - and in some cases, we have support from the BIOS (or NIC's firmware) for UDP sending, but not for TCP. There are a few other reasons, which HPA and I discussed briefly on lkml just before this project was set up on SourceForge... James. |
|
From: William R S. <wi...@so...> - 2001-06-01 14:35:52
|
On Fri, Jun 01, 2001 at 03:21:30PM +0100, James Sutherland wrote: >On Fri, 1 Jun 2001, Ferric wrote: > >> hi, >> >> was a decision regarding which protocol (TCP|UDP) was going to be >> used taken? if so, has the stack already been written? > >UDP, and not yet: still waiting for protocol definition... I'm very busy >for the next week or two, then hope to do make a start on some code then. Part IB exams, eh? ;-) I've got my Part IIs starting Tuesday ... cane ... May I ask the reasons behind using UDP rather than TCP? Surely we will end up reimplementing a number of the features offered by TCP such as automatic retransmission, data integrity, rearrangement of packets that arrive out-of-order, etcetera. Will _________________________________________________________________________ William R Sowerbutts (BtG) wi...@so... Coder / Guru / Nrrrd http://sowerbutts.com main(){char*s=">#=0> ^#X@#@^7=";int c=0,m;for(;c<15;c++)for (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));} |
|
From: James S. <ja...@ca...> - 2001-06-01 14:22:01
|
On Fri, 1 Jun 2001, Ferric wrote: > hi, > > was a decision regarding which protocol (TCP|UDP) was going to be > used taken? if so, has the stack already been written? UDP, and not yet: still waiting for protocol definition... I'm very busy for the next week or two, then hope to do make a start on some code then. James. |
|
From: Ferric <fe...@fe...> - 2001-06-01 14:18:31
|
hi, was a decision regarding which protocol (TCP|UDP) was going to be used taken? if so, has the stack already been written? best, ferric |
|
From: James S. <ja...@ca...> - 2001-05-04 08:28:27
|
On Thu, 3 May 2001, ULISSES FURQUIM FREIRE DA SILVA wrote: > > Hi, > > are you going to start this project for real soon? Hopefully :-) The first thing we need, though, is the protocol spec - not much can be done before that's written. I've got a lot on over the next month or so, but I'll be able to devote more attention to the project after that... -- Old programmers never die. They just branch to a new address. -- BSD fortune file |
|
From: ULISSES F. F. DA S. <ra9...@ic...> - 2001-05-03 20:05:04
|
Hi, are you going to start this project for real soon? -- Ulisses |
|
From: H. P. A. <hp...@tr...> - 2001-03-05 01:44:20
|
Erik Thiele wrote: > > hi. > > how do you handle a situation of overflow, i.e. > the kernel does printk too fast for the network. > > will you block printk? is this allowed? > No, the plan is to have the protocol allow for controlled buffer overrun. -hpa -- <hp...@tr...> at work, <hp...@zy...> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt |
|
From: Erik T. <er...@er...> - 2001-03-03 09:21:40
|
hi. how do you handle a situation of overflow, i.e. the kernel does printk too fast for the network. will you block printk? is this allowed? cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 GnuPG: FF96 408A 8C33 6299 D12E A547 05B0 8B68 0100 14E9 ' ` |
|
From: H. P. A. <hp...@tr...> - 2001-03-01 01:01:29
|
Pavel Machek wrote: > > What is problem with client doing reconnects? It is easy. If you get > reset, you reconnect. > Pavel Now, what if the server isn't there (as it won't be during, say, the reboot)? Yes, you can patch up all these warts, but in the end, it's really painfully complex. -hpa -- <hp...@tr...> at work, <hp...@zy...> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt |
|
From: Pavel M. <pa...@uc...> - 2001-02-24 20:07:12
|
Hi! >UDP datagram, and would make it very easy to map native console >operations -- how weird they may be -- onto the virtual screen. The >downside is that it makes server-side logging and scrollback harder. > >Thoughts on this subject? Yes. You just lost ability to count number of messages. You can't say if 50 or 500 same messages come. That might not be showstopper, however. >Once again, it will not handle interrupted connections (server >reboots, >buffer overruns) correctly -- in fact, it would have disastrous >effects. >Saying you can have a small TCP implementation is not good enough -- >the >OS on the server will implement TCP, not the small TCP derivative >capable >of handling interrupted connections. This is reason for not using >TCP. >That something looks a lot like TCP doesn't mean TCP is the right >answer. What is problem with client doing reconnects? It is easy. If you get reset, you reconnect. Pavel -- I'm pa...@uc.... "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at di...@li... |
|
From: H. P. A. <hp...@tr...> - 2001-02-22 02:27:53
|
li...@ho... wrote: > > > Don't get me wrong - I'm willing to scrap all this and work with the group > > as long as the approach is reasonable. Just relating my experiences. > > Real-world experience is *good*. I think we all have different models > of the goal we're trying to achieve, so firming that up before deciding > on a solution is a good thing. > Agreed. -hpa -- <hp...@tr...> at work, <hp...@zy...> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt |
|
From: <li...@ho...> - 2001-02-22 01:26:46
|
> Don't get me wrong - I'm willing to scrap all this and work with the group
> as long as the approach is reasonable. Just relating my experiences.
Real-world experience is *good*. I think we all have different models
of the goal we're trying to achieve, so firming that up before deciding
on a solution is a good thing.
Let me give an example protocol I thought of that's completely different
from HPA's...
The client maintains a ring buffer of output, of some convenient size, and
a 32-bit sequence number for each byte. At any time, only a small fraction
of sequence numbers are available.
A server may query the buffer (using a well-known UDP port) whenever
it wants ("please give me X bytes starting at sequence number N").
The client returns the request, what it currently has (Y bytes starting
at sequence number M), and whatever data it has that fits into the
intersection (and the MTU).
The server can ask for 0 bytes, in which case it will just be told what
the client has without getting any.
The client never retransmits. However, an optional but encouraged client
feature is the "persistent request". A server sets a flag bit in its
request, indicating that it wants the client to remember the request
until all of the data that it has asked for has come in. If the client
includes that bit in its responses, it indicates that it has remembered
the request and will be sending future unsolicited updates as long as
they fit into the window.
The window is fairly small (say, 64K limit), so the server has to refresh
its request when it's halfway gone. If the server crashes, its request will
eventually time out on the client.
A client will hopefully have space for some small number of persistent
requests.
If the client needs to throw away the buffer, it sends a final response
with the bit *clear*. This isn't guaranteed to arrive, but probably will.
The server always needs to do periodic pinging to make sure the clients
haven't gone away, and if the client doesn't support persistent requests
(it treats persistent requests as ordinary non-persistent requests, indicated
by not setting the persistent bit in the response), the server has to find
some suitable poll rate.
It can keep statistics on the output generation rate and adaptively poll
often enough to reduce the probability of overflow to a reasonable level.
If the client supports persistent requests, the server will only lose
data if *all* of the persistent replies get lost (so the server doesn't
notice the hole in its address space), or it fills the output table
so faster than the server's round-trip time.
This is very much output-oriented, although it can be augmented with
an input protocol - the client just maintains a sequence number and
accepts packets in sequence and throws them away otherwise. A client
can also accept part of a packet. In any case, it always responds with
its current sequence number.
This protocol is aiming to be as state-free as possible, to make recovery
from outages as simple as possible. The client maintains no tomers, and
never has to throttle its output. It sacrifices reliable transmission,
although it should perform very well over high-speed LANs.
|
|
From: H. P. A. <hp...@tr...> - 2001-02-22 01:15:43
|
Jim Garlick wrote: > > Ah - here is where we differ, I am planning for LinuxBIOS so I always have > the whole kernel underneath. > That's great for when that's available, but it can't be a requirement. > > Again, more complexity at the client. If you're willing to accept data > > loss, which you obviously are, then why are you worried about "a single > > point of failure"; note that the idea of the protocol is that the server > > can be rebooted or even replaced, so you could keep a hot spare available > > and switch it in place with a simple ifconfig command. > > OK, that would be good. On the single point of failure, losing a character > here and there is less critical to me than losing the whole console system... > On the other hand, if the protocol were robust enough to capture 512 nodes > oopsing at once, that would be a plus :-) I don't see why not. However, as I have pointed out before, the network is NEVER going to be a reliable way of capturing crash dumps -- there are just too many things that can go wrong. -hpa -- <hp...@tr...> at work, <hp...@zy...> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt |
|
From: Jim G. <ga...@ll...> - 2001-02-22 01:10:48
|
On Wed, 21 Feb 2001, H. Peter Anvin wrote: > Jim Garlick wrote: > > > > Maybe I'm not explaining this clearly, but it's actually quite simple: > > > > wc -l *.c > > 395 ec.c # rewrite of minicom > > 789 elancon.c # protocol + elan interface > > 542 elantty.c # tty driver, both callout and "elancon" > > 1726 total > > > > That's not what I would consider simple, and that is with the > infrastructure of a full kernel underneath. Seriously, it's a pretty > absolute requirement that this can be implemented in assembly in a few > kilobytes, for a pre-booting system. Ah - here is where we differ, I am planning for LinuxBIOS so I always have the whole kernel underneath. Still, most of the above is tty support for a getty which you won't need in the pre-boot stage, and code to deal with the comms, which is a given you need anyway... The protocol support is only a tiny part. > Again, more complexity at the client. If you're willing to accept data > loss, which you obviously are, then why are you worried about "a single > point of failure"; note that the idea of the protocol is that the server > can be rebooted or even replaced, so you could keep a hot spare available > and switch it in place with a simple ifconfig command. OK, that would be good. On the single point of failure, losing a character here and there is less critical to me than losing the whole console system... On the other hand, if the protocol were robust enough to capture 512 nodes oopsing at once, that would be a plus :-) Jim |
|
From: H. P. A. <hp...@tr...> - 2001-02-22 00:47:28
|
Jim Garlick wrote: > > Maybe I'm not explaining this clearly, but it's actually quite simple: > > wc -l *.c > 395 ec.c # rewrite of minicom > 789 elancon.c # protocol + elan interface > 542 elantty.c # tty driver, both callout and "elancon" > 1726 total > That's not what I would consider simple, and that is with the infrastructure of a full kernel underneath. Seriously, it's a pretty absolute requirement that this can be implemented in assembly in a few kilobytes, for a pre-booting system. > > As far as supporting multiple servers, there is a lot you could do but it > > would all come at considerable cost in client complexity. Multicasting, > > for example, requires that the client understands IGMP. Unicasting to > > multiple servers would require waiting for ACKs from all of them. > > I dont see unicasting as too big of a problem. Consider that you're taking > what might normally be throttled through a 9600 baud serial console and > putting it on a network, albeit shared, with several orders of magnitude more > bandwidth. Also, the approach I took was not to ack data as consoles (at > least serial) are assumed to be lossy (I do ack connect protocol), and to > actually implement the tty baud rate so senders get throttled down to 38400 > baud or whatever the user chooses to avoid overwhelming the minicom-thing. Again, more complexity at the client. If you're willing to accept data loss, which you obviously are, then why are you worried about "a single point of failure"; note that the idea of the protocol is that the server can be rebooted or even replaced, so you could keep a hot spare available and switch it in place with a simple ifconfig command. > Don't get me wrong - I'm willing to scrap all this and work with the group > as long as the approach is reasonable. Just relating my experiences. Don't get me wrong either; I appreciate your input and I'd like to come up with something reasonable. However, I'm very adamant that the client side of the protocol be simple enough that it can be implemented in the pre-boot stage. -hpa -- <hp...@tr...> at work, <hp...@zy...> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt |
|
From: Jim G. <ga...@ll...> - 2001-02-22 00:37:51
|
On Wed, 21 Feb 2001, H. Peter Anvin wrote:
> > On the architecture, it seems to me like the netcon server approach creates
> > a single point of failure where there doesn't need to be one. The way
> > I did the elan consoles was I made a range of elancon tty "callout devices"
> > which can be virtually connected to the elancon tty console device on any
> > node via an ioctl. The client user-space software then just becomes minicom
> > with support for some new tty ioctls (because the connected callout device
> > looks just like /dev/ttyS0), and it is fully peer-to-peer.
>
> This sounds like an awful lot of complexity.especially for the client.
> The client really does need to be lean and mean. To be utterly frank, a
> solution of the complexity level you seem to advocate sounds like you
> might as well go right ahead and just use ssh.
Maybe I'm not explaining this clearly, but it's actually quite simple:
wc -l *.c
395 ec.c # rewrite of minicom
789 elancon.c # protocol + elan interface
542 elantty.c # tty driver, both callout and "elancon"
1726 total
> As far as supporting multiple servers, there is a lot you could do but it
> would all come at considerable cost in client complexity. Multicasting,
> for example, requires that the client understands IGMP. Unicasting to
> multiple servers would require waiting for ACKs from all of them.
I dont see unicasting as too big of a problem. Consider that you're taking
what might normally be throttled through a 9600 baud serial console and
putting it on a network, albeit shared, with several orders of magnitude more
bandwidth. Also, the approach I took was not to ack data as consoles (at
least serial) are assumed to be lossy (I do ack connect protocol), and to
actually implement the tty baud rate so senders get throttled down to 38400
baud or whatever the user chooses to avoid overwhelming the minicom-thing.
Don't get me wrong - I'm willing to scrap all this and work with the group
as long as the approach is reasonable. Just relating my experiences.
Jim
|
![http://www.eton-tech.net/products_img/et-2010ms.gif"><span](http://www.eton-tech.net/products_img/et-2010ms.gif"><span){kind=link}