Hi Tom,
No telneting isn't a problem if I do it manually. And I can run other
multi-line scripts just fine.
How about "sleep"?
Is the problem as Jamie mentioned that busybox-msh telnet cannot be used
with input from a pipe?
To list at large: Is there a way around this?
The board I was using before that could run the telnet subshell script
was the Atmel NGW100. I have a few of them here and it seems all have
failed one way or another. I was able to get one to boot long enough
to get the following info about the kernel used:
Board: Atmel NGW100
Image Name: Linux-2.6.18-atngw
Image Type: AVR32 Linux Kernel Image (gzip compressed)
Data Size: 912607 Bytes = 891.2 kB
Regrettably, this not tell us how its Linux was configured. It does not
tell us what services were enabled/disabled.
However..
If you have the source tree, you should be able to run "make xconfig" to
get a blow by blow description of your Linux-2.6.18-atngw's
configuration. To be on the safe side, run "make xconfig" on a copy of
your source tree.
Bob Furber
Tom
----- Original Message ----- From: "Bob Furber" <b...@steroidmicros.com>
To: "uClinux development list" <uclinux-dev@uclinux.org>
Sent: Tuesday, March 10, 2009 1:40 PM
Subject: Re: [uClinux-dev] ( subshell ) | telnet -->not workingon
WildFireucLinux
Hi Tom,
I used the subshell like this (I think the parens are necessary):
( sleep 1; echo username; sleep 1; etc... ) | telnet 10.0.0.24 23
I am not familiar with scripts in brackets. In fact, I know little
about scripting. And I do not have access to a uClinux board right now.
However, I do know that the uClinux loaded on the WildFireMod happily
executes scripts. On startup it executes /etc/rc. If you have uClinux
loaded in flash, try running prep-sdcard.sh which will partition a SD
card and echo its progress.
And I need the last line to tell where to telnet to. When I telnet
in manually, I can do it successfully with or without the port
number (23) at the end.
So, telnetting is NOT a problem?
To answer you question, it seems nothing works in the subshell. I
tried putting sleep 1000; in there and it still took about a half
second to return the prompt, with no error reported.
So, "sleep" may be the problem?
Also thought it may just be telneting in really fast, so I put in a
command to cp a file that exits on the remote server to a new
filename, but it didn't work, so I don't think it's telneting or
sleeping. I don't see anything printed to the console, so I don't
think echo is working in the subshell either.
..yet etc/rc merrily echos every time you boot uClinux...
For example, say I call my scrip t-net, here's what my session looks
like:
# ./t-net
#
only after about 1/2 second or so after entering 't-net'
Forgive my ignorance, but, could the bracketed script be part of the
problem? Can you test a couple of conventional multi-line scripts?
On a different uClinux system I could watch the whole telnet session
in real time on the console as the script ran.
What shell was it running? Do you have access to its uClinux
configuration? What shell does it use? What services are
enabled/disabled?
If you can figure all this out, you should be able to configure
uClinux for the WildFireMod exactly the same.
Bfn,
Bob Furber
Tom
----- Original Message ----- From: "Bob Furber" <b...@steroidmicros.com>
To: "uClinux development list" <uclinux-dev@uclinux.org>
Sent: Tuesday, March 10, 2009 11:49 AM
Subject: Re: [uClinux-dev] ( subshell ) | telnet --> not workingon
WildFireucLinux
Hi Tom,
Thanks for the help. I tried enabling msh (I think it was already
enabled...when it boots up it says BusyBox...(msh)). And I put
the #!/bin/msh as the header, but it still didn't work.
Could we ask you to be a little more specific: Can you tell us what
part of your script did not work by removing lines?
The script you claim is causing grief was:
#!/bin/sh
sleep 1;
echo username;
sleep 1;
echo pwd;
sleep 1;
echo [various commands];
sleep 1;
echo exit | telnet 10.0.0.25 23 <-- Not sure about this line
Does it sleep?
Does it echo?
What happens if you remove the last line?
Although there are numerous scripts in
.../Vendors/Intec/WildFireMod/ which are happily executed by the
WildFireMod/uClinux, I could not find any that "sleep" and there
are none that "telnet". So, some experimentation is in order to
narrow down the services that have not been enabled.
Bfn,
Bob Furber
Would appreciate any more advice, also in regards to what version
of Linux I should load onto one of our PC's in order to tweak the
kernel, and if creating a dual-boot XP/Linux PC would be OK.
Thanks,
Tom
----- Original Message ----- From: "Bob Furber"
<b...@steroidmicros.com>
To: "uClinux development list" <uclinux-dev@uclinux.org>
Sent: Monday, March 09, 2009 7:41 PM
Subject: Re: [uClinux-dev] ( subshell ) | telnet --> not working
on WildFireucLinux
Tom,
I'm having difficulty telneting withing a subshell script like
this:
#!/bin/sh
( sleep 1; echo username; sleep 1; echo pwd; sleep 1; echo
[various commands]; sleep 1; echo exit ) | telnet 10.0.0.25 23
The above worked fine on our Atmel board running uClinux, but it
isn't working on our Motorola board (specifically the WildFire
board which uses the MCF5282).
The WildFire board is running firmware from here:
ftp://ftp.sbctools.com/pub/uClinux/WildFire/wildfire-uC-firmware.zip
And here are the two files I put on, following the above
instructions:
For anyone wishing to help Tom,
1) linux.gz.bin
The linux image to load in flash
2) jffs2.img.bin
The romfs image to load in flash ..using dBUG>dnfl linux.gz.bin
jffs2.img.bin
..which install both these images in flash using TFTP.
I can telnet just fine manually, but need to have the board to
do it automatically via a subshell script. Does anyone know why
the subshell script wouldn't be working?
My guess is that the BUSYBOX_MSH needs to be tweaked to offer the
services you need.
On a LinuxPC make a copy of your uClinux source tree. Then run
make xconfig. Select Vendor Intec & platform WildFireMod. Then go
into the "Kernel/Library/Defaults section and select 'y' for
"Customize Vendor/Users Settings" and, possibly "Update Default
Vendor Settings". Then click "Main Menu" which will return you to
the main menu where you can "Save and Exit". But now you will be
prompted with a lengthy "kernel configuration dialog".
A lot of the options here are self explanatory, and they also
contain some documentation. See the bottom of the window when you
select and option for more information. The key concept here is
"if in doubt leave out" ..or leave it as it is.
After going through all of these options carefully (using the
existing boards as a template) you can exit this part of the
configuration by selecting File?Quit and then saying "Yes" to
save changes. After this dialog disappears another dialog with a
bunch of buttons appears for selecting the user applications to
include by default in the final image ..such as BusyBox, Network
Applications, etc..
Each of these buttons contains lists of applications that can be
included by default. Same as before, use the existing Intec board
as a template for selecting these applications. You can see the
existing configurations for other boards by performing a "make
xconfig" on an existing directory.
The trick here is knowing which options to enable and what
dependencies there might be. Here is where this uClinux list can
be very helpful.
There are comments in
uClinux.../Vendors/Intec/WildFireMod/Makefile which help you
configure this makefile to either build a SD-card image or a
flash image. I recommend the flash image because this leaves your
SD card exclusively for datalogging and data storage.
Once you think the kernel is configured the way you want, enter
"make" and your PC will grind away for a long time as it builds
the updated linux and romfs images.
Forgive me for this very brief summary. If you need more support
in the mechanics of configuring and building your kernel, please
contact me directly. But, if you need support figuring out what
services to include and how to configure them, this list could be
very helpful.
Bfn,
Bob Furber
Thank you,
Tom
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
