[U-Boot-Users] telnet server on u-boot

[VanBaren, Gerald (AGRE)]

I've used UDP packets on other projects using NetCat (nc -u) http://netcat.sourceforge.net/ to give me an interactive console over UDP.  This works really well for command/response type interaction.  It works less well on console messages type interactions when the embedded system is spontaneously sending print messages.

Since UDP is connectionless, you need to determine when and to whom to send print messages.  As I see it, there are a couple of options:

1) Use an environment variable to set the IP address and the port of the destination.  If the env var doesn't exist or is set to 0, suppress the UDP packets.  Note that this would allow the destination to be the broadcast IP address which would be good for capturing packets, and especially usefull for using a host to log them, but bad if you have lots of embedded systems all spewing lots of messages.  It would also allow the embedded system to target a given host.

2) If the embedded system receives a packet on the console UDP port, send all console packets back to the sender.  This would allow the interaction to be triggered by an arbitrary host, but would require that host to knock on the door of the embedded system first (not good for initial power up messages).

My preference would be #1.

gvb


> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Laurent
> Mohin
> Sent: Tuesday, February 24, 2004 11:42 AM
> To: Wolfgang Denk
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] telnet server on u-boot
>
>
> Wolfgang,
>
> In message above, you wrote :
>
> > > For some remote instruments, I need to be able to have a
> telnet access
> to
> > > the boot in case of my Linux kernel and file system are
> down (after an
>
> > > upgrade for example).
> > > I don't think that u-boot provide telnet support and I
> had a look at
> > > another boot project called redboot that provide such a
> functionality.
> > > I have a couple of questions :
> > > Does anybody see another solution than telnet to control a remote
> > > instrument?
>
> > There are many solutions. You don't provide much 
> informatiuon  about
> > your  workign environment so it is difficult to make a good
> recommen-
> > dation. Standard solutions include: use a  modem  to 
> attach  to  the
> > serial  console;  use  a  terminal  server  to  attach  to
> the serial
> > console; etc.
>
> Use of a modem or a terminal server to attach to the serial
> console is not
> a good solution for me, because I hope to deploy at least
> several hundred
> of instruments. And the only link I have with them is thru Ethernet.
> That's why I'm looking for something similar as telnet.
>
> Thanks for your reply,
>
> Laurent
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************