heater, you can just edit the post and remove the link iirc.
Your pic is pretty much what i have currently. My rhs router to the internet is my xoom tablet acting as a hotspot.
i dont have any direct (ethernet) connections to it - they are all via wifi just like your debian pc.
your lhs router (sta) is my wr703n openwrt box and i have the ethernet connection to my pc (your debian pc).
I am excited because while it taken quite some time to get this far, i have learnt a lot, and realised i know less than i thought
Today i am going to try wget.
Do you know how to find out my internet ip address? i realise it will change each time i logon to the internet with my tablet.
if i can find this out, maybei can login via my iphone/safari and interogate my router for the led state.
I can't see how to remove the old thumbnail attachment though.
If you go to http://www.speedtest.net/ you will see the IP address that the internet sees from your connection in the speed test console.
You won't be able to get to your router on that address unless you have set up some port forwarding and static leases in your upstream router. Your xoom as far as I can tell. As I described earlier.
And it's always possible that if you are connected over 3G your phone provider won't allow incoming connections anyway.
Grrr...Had to up date the diagram. How does one delete an attachment from a post? Like the old diagram for example.
Sorry Loopy, despite what I said I have set one static IP address. Not in a router but in my PC. It has eth0 set to 192.168.2.2 so as to access the peer router box.
Hi,
I am getting my particular problems sorted out.
To put it simple, I just did not configure the /etc/config/network file correctly.
I won't go into a long story about why or how, but one is supposed to do revise BOTH the /etc/config/wireless and the /etc/config/network files immediately after loading the OpenWRT firmware and going over to a login via SSH.
1. At first I only modified the wireless file, DID NOT do anything to the network file.
2. And then, I changed the /etc/config/network listing for LAN to a DCHP client, when I should have not done so AND should have added an item called WAN with the DCHP client instead.
And so, I spent quite a bit of time ferreting out how the /etc/config/wireless and /etc/config/network files are supposed to work and their proper configuration. (I was paranoid that I was going to brick my MR3020).
All is well. And I suspect that what I learned will help others avoid similar mistakes.
BTW, OpenWrt does seem to include a directory under the /etc that provides examples of proper configuration. I will have to get back to youall with the exact name. But it is a very helpful reference.
I have already provided a file that includes my WRONG configuration. Attached is the same, but only for the /etc/config/network. You will NOTE that there are only TWO items "config interface ...." items in the /etc/config/network file [LOOPBACK and LAN], and there should be a third, [WAN].
$ pwd
/home/heater/propeller/propgcc/loader
$ make clean
make[1]: Entering directory '/home/heater/propeller/propgcc/loader/sdloader'
make[1]: Leaving directory '/home/heater/propeller/propgcc/loader/sdloader'
$ OS=linux CC=mipsel-openwrt-linux-uclibc-gcc make
....bla bla lots of output...
$ file bin/linux/*
bin/linux/bin2c: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
bin/linux/dir-created: empty
bin/linux/propeller-elf-image-size: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
bin/linux/propeller-load: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
$ scp propeller-load root@192.168.2.1:root@192.168.2.1's password:
propeller-load 100% 131KB 130.8KB/s 00:00
On the router:
root@OpenWrt:~# ./propeller-load
usage: propeller-load
[ -b <type> ] select target board (default is 'default:default')
[ -p <port> ] serial port (default is to auto-detect the port)
[ -P ] list serial ports with Propeller chips
[ -Q ] list available serial ports
[ -I <path> ] add a directory to the include path
[ -D var=value ] define a board configuration variable
[ -e ] write the program into EEPROM
[ -r ] run the program after loading
[ -g ] set up the program for debugging after loading
[ -s ] write a spin .binary file for use with the Propeller Tool
[ -x ] write a .pex binary file for use with the SD loader or SD cache
[ -l ] write a program to the sd card and use the SD loader
[ -z ] write a program to the sd card and use the SD cache
[ -f ] write a file to the SD card
[ -t ] enter terminal mode after running the program
[ -t<baud> ] enter terminal mode with a different baud rate
[ -q ] quit on the exit sequence (0xff, 0x00, status)
[ -v ] verbose output
[ -S ] slow down the loader by adding 5 microseconds delay
[ -S<n> ] slow down the loader by adding <n> microseconds delay
[ -? ] display a usage message and exit
<name> elf or spin binary file to load
Target board type can be either a single identifier like 'propboe' in which case the subtype
defaults to 'default' or it can be of the form <type>:<subtype> like 'c3:ram'.
Variables that can be set with -D are:
clkfreq clkmode baudrate reset rxpin txpin tvpin
cache-driver cache-size cache-param1 cache-param2
sd-driver sdspi-do sdspi-clk sdspi-di sdspi-cs
sdspi-clr sdspi-inc sdspi-start sdspi-width spdspi-addr
sdspi-config1 sdspi-config2 eeprom-first
Value expressions for -D can include:
rcfast rcslow xinput xtal1 xtal2 xtal3 pll1x pll2x pll4x pll8x pll16x k m mhz true false
an integer or two operands with a binary operator + - * / % & | or unary + or -
all operators have the same precedence
The -b option defaults to the value of the environment variable PROPELLER_LOAD_BOARD.
The -p option defaults to the value of the environment variable PROPELLER_LOAD_PORT
if it is set. If not the port will be auto-detected.
The 'sd loader' loads AUTORUN.PEX from an SD card into external memory.
It requires a board with either external RAM or ROM.
The 'sd cache' arranges to run AUTORUN.PEX directly from the SD card.
It can be used on any board with an SD card slot.
root@OpenWrt:~#
It runs! I have no way to test it at the moment and it needs hacking up to drive a GPIO for reset.
I'll try and make some instructions for doing this that should work with any routers processor architecture. I had to hack the Makefile a bit to get it to fly.
Hi,
I am working through cleaning up my installation muddle.
In the process, I have run 'opkg update' <enter> and then 'opkg list' <enter> while in a capture mode.
This allows me to get a complete list of software packages in the opkg repository. Apparently, without capture, the list is too long from my serial port buffer in PuTTY.
IOW, this is about the only easy way to get a fresh and reliable shopping list of packages to choose from.
I am delighted to see all that I wish for and much more.
There is even a copy of Ipython, if Python is what you are after.
1. There is 4th for the OpenWrt (oh my!)
2. There is Minicom
3. There is Picocom
4. There is Ser2lan
5. There is Stty
and much more... I suggest that you use your Search feature in a text editor to locate whatever you desire.
$ pwd
/home/heater/propeller/propgcc/loader
$ make clean
make[1]: Entering directory '/home/heater/propeller/propgcc/loader/sdloader'
make[1]: Leaving directory '/home/heater/propeller/propgcc/loader/sdloader'
$ OS=linux CC=mipsel-openwrt-linux-uclibc-gcc make
....bla bla lots of output...
$ file bin/linux/*
bin/linux/bin2c: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
bin/linux/dir-created: empty
bin/linux/propeller-elf-image-size: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
bin/linux/propeller-load: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
$ scp propeller-load root@192.168.2.1:root@192.168.2.1's password:
propeller-load 100% 131KB 130.8KB/s 00:00
On the router:
root@OpenWrt:~# ./propeller-load
usage: propeller-load
[ -b <type> ] select target board (default is 'default:default')
[ -p <port> ] serial port (default is to auto-detect the port)
[ -P ] list serial ports with Propeller chips
[ -Q ] list available serial ports
[ -I <path> ] add a directory to the include path
[ -D var=value ] define a board configuration variable
[ -e ] write the program into EEPROM
[ -r ] run the program after loading
[ -g ] set up the program for debugging after loading
[ -s ] write a spin .binary file for use with the Propeller Tool
[ -x ] write a .pex binary file for use with the SD loader or SD cache
[ -l ] write a program to the sd card and use the SD loader
[ -z ] write a program to the sd card and use the SD cache
[ -f ] write a file to the SD card
[ -t ] enter terminal mode after running the program
[ -t<baud> ] enter terminal mode with a different baud rate
[ -q ] quit on the exit sequence (0xff, 0x00, status)
[ -v ] verbose output
[ -S ] slow down the loader by adding 5 microseconds delay
[ -S<n> ] slow down the loader by adding <n> microseconds delay
[ -? ] display a usage message and exit
<name> elf or spin binary file to load
Target board type can be either a single identifier like 'propboe' in which case the subtype
defaults to 'default' or it can be of the form <type>:<subtype> like 'c3:ram'.
Variables that can be set with -D are:
clkfreq clkmode baudrate reset rxpin txpin tvpin
cache-driver cache-size cache-param1 cache-param2
sd-driver sdspi-do sdspi-clk sdspi-di sdspi-cs
sdspi-clr sdspi-inc sdspi-start sdspi-width spdspi-addr
sdspi-config1 sdspi-config2 eeprom-first
Value expressions for -D can include:
rcfast rcslow xinput xtal1 xtal2 xtal3 pll1x pll2x pll4x pll8x pll16x k m mhz true false
an integer or two operands with a binary operator + - * / % & | or unary + or -
all operators have the same precedence
The -b option defaults to the value of the environment variable PROPELLER_LOAD_BOARD.
The -p option defaults to the value of the environment variable PROPELLER_LOAD_PORT
if it is set. If not the port will be auto-detected.
The 'sd loader' loads AUTORUN.PEX from an SD card into external memory.
It requires a board with either external RAM or ROM.
The 'sd cache' arranges to run AUTORUN.PEX directly from the SD card.
It can be used on any board with an SD card slot.
root@OpenWrt:~#
It runs! I have no way to test it at the moment and it needs hacking up to drive a GPIO for reset.
I'll try and make some instructions for doing this that should work with any routers processor architecture. I had to hack the Makefile a bit to get it to fly.
Salutations!!!! Excelsior !!!
Of course, this is the D-Link compile version, but I am looking forward to an Antheros version for the WR703N and MR3020 coming soon.
Did you create an opkg package to install it? Or did you find another way to load the executable?
++++++++
I may have a working Forth interface withing an hour or two. Opkg packages are quite painless to manage and I suspect I can just install Minicom and have it up and running. I will report back very very soon.
No. I have no idea how to create an opkg. Perhaps I'll look into it at some point. Somehow an opkg is actually many packages, one for every router architecture supported !
I just compiled the thing using the openwrt tool chain and used scp to copy the executable to the router:
I think that is actually the only file we need on the router for getting regular Spin or other binaries into a Propeller.
BUT for those crazy C setups that use all kinds of different external memory hardware on the Prop there is a ton of other files required. I'll try those out if an when I see the basic loader working.
I had to hack the loaders Makefile a bit to get this compiled but I should be able to write some instructions for building it that anyone could follow easily for their own brand of router.
If you can tell me exactly which OpenWRT binary you have flashed your box with I can probably make a loader for you here quite quickly.
Hmmm. Well if you don't have to use the OpenWrt opkg approach and it works, it is a lot easier for Propeller users to share, develop, and maintain over the long haul.
I have Minicom successfully installed, but haven't gotten my Wifi and RS232 sorted out quite yet for connecting the RS232 with a Propeller. Until I get the Wifi connection back, it would be a disaster to shut out the Serial Console from the RS232 for other purposes (I am unsure what I'd have to do to get it back)
The Wifi does connect via LuCi and SSH when it is working right. That is the lynch pin to hyjacking the RS232 port.
More later. I am having a lot of fun and looking forward to having Propeller in Forth with a direct wifi access 24/7. There are many times that home automation projects have been abandoned just because I didn't care for the idea of having CAT5 cables spread all over my living space.
The WR703N or MR3020 can sit with the Propeller and next to an electrical outlet. I even already have a 12VDC gel cell backup power configuration that would hold the Propeller board and MR3020 as well with a few relays, maybe a sensor or two. I have some LM35 sensors for temperature.
... if you don't have to use the OpenWrt opkg approach and it works, it is a lot easier for Propeller users to share, develop, and maintain over the long haul.
That's what I have been saying for ages.
Now, which OpenWRT binary did you load to your router?
heater, you can just edit the post and remove the link iirc.
Your pic is pretty much what i have currently. My rhs router to the internet is my xoom tablet acting as a hotspot.
i dont have any direct (ethernet) connections to it - they are all via wifi just like your debian pc.
your lhs router (sta) is my wr703n openwrt box and i have the ethernet connection to my pc (your debian pc).
I am excited because while it taken quite some time to get this far, i have learnt a lot, and realised i know less than i thought
Today i am going to try wget.
Do you know how to find out my internet ip address? i realise it will change each time i logon to the internet with my tablet.
if i can find this out, maybei can login via my iphone/safari and interogate my router for the led state.
Check out curl and wget to get the public IP, you can put the command in a shell script as well, here are some examples:
Get your external IP address using the curl command :
$ curl ifconfig.me
$ curl ip.appspot.com
$ curl icanhazip.com
Get your external IP address using the wget command :
$ wget -q -O - ifconfig.me
$ wget -q -O - ip.appspot.com
$ wget -q -O - icanhazip.com
I only loaded the Minicom opkg package as it should do everything I need. I normally use Minicom over a USB2SER to communicate with a Propeller in Forth.
I did a preliminary run of the Minicom by entering 'minicom -s' at the prompt (this is the setup mode) and it came right up with all the configuration slots empty. If you don't know Minicom, it might help to play with it on another Linux machine to figure out how to setup. But there isn't really much to do.
1. input a path to /dev/ttyANTH0
2. set the baud rate, bits and parity according to the desired target.
3. exit set up and set if it will interact to bring up a Forth prompt.
**************************************************************
Everything was going so wellll................ until I decide to clean up the /etc/config/network and /etc/config/wireless.
Now my wifi login protocol is going haywire.
And so, I keep stubbling foward. I still have the RS232 Serial Console to fix my messes.
I can no longer access openwrt.org with Chrome. Firfox throws a hissy fit about security but lets me continue if I say it's OK to do so.
This is what Chrome says:
Cannot connect to the real openwrt.org
Something is currently interfering with your secure connection to openwrt.org.
Try to reload this page in a few minutes or after switching to a new network. If you have recently connected to a new Wi-Fi network, finish logging in before reloading.
If you were to visit openwrt.org right now, you might share private information with an attacker. To protect your privacy, Chrome will not load the page until it can establish a secure connection to the real openwrt.org.
Well yes I have recently conected to a new WIFI network, I just built it! But what's all this about "finish logging in"?
Is this an issue with my router set up here, or something up with openwrt.org?
I could have sworn it worked yesterday...
This is probably because the router you're connected to has the time/date wrong, so anything time/date sensitive like in this case ssl certificates (have expire date) will complain about expired or wrong information, try to correct the time and date on the router and try again.
I think Heater worked through the browser problem. He explained that it was old security certificates.
+++++++++++ More progress. --- very very close to Milestone ONE - LAN to Serial to Forth on the Propeller.
Heater is also very very close to achieving Milestone TWO - Loading Propeller binaries via an OpenWrt wifi router.
I have managed to once again get out of another 'shut out' mess due to my trying to reconfigure /etc/config/wireless and /etc/config/network in what I thought should be the correct way. I just rolled everything back to my original set up.
I certainly have a lot more to learn about configuring routers, but for now that is all being set aside.
++++++++++++++++++++
This clean up gave me an opportunity to try out Minicom with the actual serial port - /dev/ttyANTH0.
Proceedure
I had to go into it with 'minicom -s' and then open the menu for Serial Port Setup and select Item A.
In Item A, I put in /dev/ttyATH0
and exited the menu system
Success.. with an external Loopback (Tx wired to Rx), I get an echo of my keyboard input at the screen. When I disconnect the wiring, no echo.
I did leave the Serial Console active to see how it interfers with communicaitons. If I hit <enter>, the Serial Console will take my keyed in material as a command and respond accordingly. This is what should happen with a loopback. What happens in another setup would be different, but would also mess with the Minicom's main purpose.
So, NOW is the time for me to verify I have a running Propeller Board with Forth.
Then I will turn off the Serial Console and connect the Propeller Board.
And finally test to see if Minicom will communicate without problems... baud rate is set at 115200 8N1.
This is probably because the router you're connected to has the time/date wrong,
I seriously hope this is not the case. No router between me and the servers I'm talking to should have anything to say about security. Routers should just route my packets. They have nothing to say about the validity of certificates or any other crypto mechanism I use.
It is possible that the time/date was wrong on my PC I guess. But I have not notice such.
Was I the only one who had this problem?
Anyway. It seems to have gone away. I have not touched any times or dates anywhere.
Loopy,
Why are you so reticent about telling me which OpenWRT firmware binary you loaded into your router?
+++++++++++++
Physical Loopback is working fine with Minicom inside the MR3020, but I can't seem to get the Propeller Proto Board loading with Forth at 115200 baud 8n1 to respond.
The same board works fine with a USB2SER plugged into it.
The reason I ask is because I am going to try and build that image from the source code and tool chain provided by OpenWRT. I just wanted to be sure I built the right thing.
Then I can use the resulting cross compiler to build a Propeller loader.
If that works on your router, and Cluso's, then I will continue with the next steps.
I was surprised to find that your routers are also MIPs machines and not ARM.
BTW, if you do provide a binary -- I can simply plug a PropPlug in the USB port and that may program the Propeller without having to bother with any additional GPIO.
The RS232 port at /dev/ttyATH0 seems to be quite attached to the Serial Console functions due to choices in the Kernel compile.
While I can turn off most of it, it seems that the Standard Error output dumps to the Serial Console regardless of changing the /etc/inittab.
Loopy, last time (a week or so ago) I had a problem like that (boards not talking) was the old TX/RX/RX/TX mixup.........but I'm sure you checked that (and flipped them anyway just in case)
I have tested all the hardware, gotten all the software set up and tested; but seem to have hit a snag with direct TTL from the MR3020 to the Propeller Protoboard.
1. The MR3020 ttl RS232 works fine with Minicom and a hardwire loopback attached to the far end of the RS232 cable at 115200 8N1.
2. The Propeller Proto Board with Forth loaded works fine via a USB2SER when connected to my notebook's terminal program.
3. The MR3020 in Serial Console mode works fine with the USB2SER when connected to my notebook's terminal program.
BUT...
when I connect the MR3020 directly to the Propeller Protoboard, nothing.
It seems like a TTL level incompatibility. I don't have a scope to confirm. But both the Propeller Protoboard and the MR3020 RS232 port are very happy to operate at 115200 8n1 with the USB2SER. So I just do NOT get what is going on.
Maybe I will discover something I overlooked.. later today.
****************
@Heater
I downloaded your Propeller-load.tgz for later evaluation. I presume this is an ar71xx targeted binary that you have provided.
$ file propeller-load-mips*
propeller-load-mips_24kec+dsp: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
propeller-load-mips_34kc: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
The "24kec+dsp" loader runs on my router. The "34kc" does not.
I'm hoping that is the other way around for you guys!
Well of course, I'm a dumb Smile.... "mipsel" is for operating in little endian mode on the MIPS processor. As opposed to "mips" which is big endian. Notice how the "file" command above tells you that in it's output "LSB" vs "MSB". Unlike Intel x86 the MIPS processors can do both.
This is similar to "arm" and "armel" GCC compilers for ARM.
Oh boy. My head was nearly on a plate again this morning.
In the middle of the night I had this great idea to add a port forwarding rule to allow the web server on my PC to be reached from the internet.
Easy right? Just go to Luci->Network->Firewall->Port Forwards and fill in the ports and address...Done it a thousand times before on other routers.
Hit "save and apply". BOOM no more internet connectivity from my PC or anywhere. No more ssh'ing in on 192.168.1.1
Being lazy I just reflashed the thing, got basic internet connection back and went to sleep.
In the morning it was time to reenable the WIFI connection. Easy right? Just go to Luci->Netork->WIFI, enable WIFI and set the ESSID/key.
Again. BOOM no more internet connectivity from my PC or anywhere. No more ssh'ing in on 192.168.1.1
WTF?
Of course I may have done something dumb. I can't see it, and WIFI enabling worked fine the other few times I have done it in Luci.
Except for one little detail. On both these occasions I had a propeller-load binary on the box. It is possible that caused the file system to fill up causing Luci to fail when rewriting configs.
The really dumb thing here is ignoring the rule "Never ever mess with a working system unless you really have to!"
@Heater
Hmmm.... shut out completely?
I thought I was the only one that was getting off into that patch of weeds.
My own impressions are that there may be some sort of disconnect (a bug maybe?) between the three configuration methods - [a] direct editing of the /etc/config/ files via VI, the cgi method of configuration, [c] the use of LuCi.
And so I have tried to rely of the lowest means, direct editing of the /etc/config files. But it is important to restart the service you reconfigure. This can be done selectively, but I just use 'reboot' and do it in a wholesale fashion.
There are some configuration pages that are Must Read material that I have yet to master. Here are the links
I haven't at all mastered network design and configuration.
And at one point yesterday, when rewriting configuration to the /etc/config/wireless and /etc/config/network files, it seems to have rolled back from 192.168.3.1 being my MR3020 network to 192.168.1.1 (the default). I am not sure if I typed something wrong, or if the reconfiguration caused the device to refer squashfs for the settings rather than the jffs2 updates.
My old EEEpc 701-4G had a similar squashfs/jffsh2 configuration. And jffsh2 may require large blocks of data be rewritten when updated. So this could be a source of some odd reconfiguration behaviors.
Just remember that squashfs never changes and sits there to be referred to many times and in many ways. In fact, you might have gained entry over your RS232 port, dumped jffsh2 and started anew without resorting to reflashing an image from afar.
++++++++++++++
BTW, monitor your memory available as you load items in. A full file system will cause a lockup. On my device, OpenWRT claims it will also launch a blinking LED. But I can't be sure what you have done with your LEDs at this point.
I will take a look at my remaining available memory before I load your binaries. (And even then, I will keep an eye on what might happen.) You need to have 32K extra space (and maybe more) for the Propeller binary. And you may need to purge any binary before trying another or you just eventually run out of memory.
Locking yourself out of somewhere by changing network configuration is an occupational hazard. It's another reminder of what I said about that "labyrinth with mines".
I think you will find that the OpenWRT guys expect you to use uci when configuring things over a command line rather than hacking on config files. They did not go to all the trouble to make it for nothing. It does ensure that you don't get any typos in the configs and provides a means to apply and make the changes active.
I think you will find that Luci uses uci. There is a reason she is called Luci.
As for file system usage. Yep, best to keep an eye on it. We are so spoiled with tera bytes on PC's we tend to forget about it.
The propeller-loader I have here is 120KBytes after stripping out symbols. df on the router tells me I have all of 156K free without the loader. Eeek!
@Heater
And I seem to have noticed (but I am not 100% at this point) that changes made via the UCI are not always reflected as updates to the respect /etc/config/ files.
Sorry, but I have not had the time to investigate this... but it might be true. There seems to be some EEPROM or persistent registers that might be directly written to.
Yes, LuCi is an extension of UCI over http in a mysterious (to me) secure manner. But it doesn't seem to allow all and everything that a Command Line can do.
I suspect that Cluso and myself have quite a bit more space to work with. After loading Minicom, I still have roughly 650Kbytes available.
Tight spaces are wonderful for teaching computers. You have to look for better solutions rather than just feed the bloat. And you gain a lot of knowledge of computer history along the way. This is why I like the headless Linux setup herein. The whole GUI is yet another big distraction to learning the basic backbone of computers.
Comments
Your pic is pretty much what i have currently. My rhs router to the internet is my xoom tablet acting as a hotspot.
i dont have any direct (ethernet) connections to it - they are all via wifi just like your debian pc.
your lhs router (sta) is my wr703n openwrt box and i have the ethernet connection to my pc (your debian pc).
I am excited because while it taken quite some time to get this far, i have learnt a lot, and realised i know less than i thought
Today i am going to try wget.
Do you know how to find out my internet ip address? i realise it will change each time i logon to the internet with my tablet.
if i can find this out, maybei can login via my iphone/safari and interogate my router for the led state.
If you go to http://www.speedtest.net/ you will see the IP address that the internet sees from your connection in the speed test console.
You won't be able to get to your router on that address unless you have set up some port forwarding and static leases in your upstream router. Your xoom as far as I can tell. As I described earlier.
And it's always possible that if you are connected over 3G your phone provider won't allow incoming connections anyway.
Hi,
I am getting my particular problems sorted out.
To put it simple, I just did not configure the /etc/config/network file correctly.
I won't go into a long story about why or how, but one is supposed to do revise BOTH the /etc/config/wireless and the /etc/config/network files immediately after loading the OpenWRT firmware and going over to a login via SSH.
1. At first I only modified the wireless file, DID NOT do anything to the network file.
2. And then, I changed the /etc/config/network listing for LAN to a DCHP client, when I should have not done so AND should have added an item called WAN with the DCHP client instead.
And so, I spent quite a bit of time ferreting out how the /etc/config/wireless and /etc/config/network files are supposed to work and their proper configuration. (I was paranoid that I was going to brick my MR3020).
All is well. And I suspect that what I learned will help others avoid similar mistakes.
BTW, OpenWrt does seem to include a directory under the /etc that provides examples of proper configuration. I will have to get back to youall with the exact name. But it is a very helpful reference.
I have already provided a file that includes my WRONG configuration. Attached is the same, but only for the /etc/config/network. You will NOTE that there are only TWO items "config interface ...." items in the /etc/config/network file [LOOPBACK and LAN], and there should be a third, [WAN].
On the PC: On the router:
root@OpenWrt:~# ./propeller-load usage: propeller-load [ -b <type> ] select target board (default is 'default:default') [ -p <port> ] serial port (default is to auto-detect the port) [ -P ] list serial ports with Propeller chips [ -Q ] list available serial ports [ -I <path> ] add a directory to the include path [ -D var=value ] define a board configuration variable [ -e ] write the program into EEPROM [ -r ] run the program after loading [ -g ] set up the program for debugging after loading [ -s ] write a spin .binary file for use with the Propeller Tool [ -x ] write a .pex binary file for use with the SD loader or SD cache [ -l ] write a program to the sd card and use the SD loader [ -z ] write a program to the sd card and use the SD cache [ -f ] write a file to the SD card [ -t ] enter terminal mode after running the program [ -t<baud> ] enter terminal mode with a different baud rate [ -q ] quit on the exit sequence (0xff, 0x00, status) [ -v ] verbose output [ -S ] slow down the loader by adding 5 microseconds delay [ -S<n> ] slow down the loader by adding <n> microseconds delay [ -? ] display a usage message and exit <name> elf or spin binary file to load Target board type can be either a single identifier like 'propboe' in which case the subtype defaults to 'default' or it can be of the form <type>:<subtype> like 'c3:ram'. Variables that can be set with -D are: clkfreq clkmode baudrate reset rxpin txpin tvpin cache-driver cache-size cache-param1 cache-param2 sd-driver sdspi-do sdspi-clk sdspi-di sdspi-cs sdspi-clr sdspi-inc sdspi-start sdspi-width spdspi-addr sdspi-config1 sdspi-config2 eeprom-first Value expressions for -D can include: rcfast rcslow xinput xtal1 xtal2 xtal3 pll1x pll2x pll4x pll8x pll16x k m mhz true false an integer or two operands with a binary operator + - * / % & | or unary + or - all operators have the same precedence The -b option defaults to the value of the environment variable PROPELLER_LOAD_BOARD. The -p option defaults to the value of the environment variable PROPELLER_LOAD_PORT if it is set. If not the port will be auto-detected. The 'sd loader' loads AUTORUN.PEX from an SD card into external memory. It requires a board with either external RAM or ROM. The 'sd cache' arranges to run AUTORUN.PEX directly from the SD card. It can be used on any board with an SD card slot. root@OpenWrt:~#It runs! I have no way to test it at the moment and it needs hacking up to drive a GPIO for reset.
I'll try and make some instructions for doing this that should work with any routers processor architecture. I had to hack the Makefile a bit to get it to fly.
I am working through cleaning up my installation muddle.
In the process, I have run 'opkg update' <enter> and then 'opkg list' <enter> while in a capture mode.
This allows me to get a complete list of software packages in the opkg repository. Apparently, without capture, the list is too long from my serial port buffer in PuTTY.
IOW, this is about the only easy way to get a fresh and reliable shopping list of packages to choose from.
I am delighted to see all that I wish for and much more.
There is even a copy of Ipython, if Python is what you are after.
1. There is 4th for the OpenWrt (oh my!)
2. There is Minicom
3. There is Picocom
4. There is Ser2lan
5. There is Stty
and much more... I suggest that you use your Search feature in a text editor to locate whatever you desire.
Salutations!!!! Excelsior !!!
Of course, this is the D-Link compile version, but I am looking forward to an Antheros version for the WR703N and MR3020 coming soon.
Did you create an opkg package to install it? Or did you find another way to load the executable?
++++++++
I may have a working Forth interface withing an hour or two. Opkg packages are quite painless to manage and I suspect I can just install Minicom and have it up and running. I will report back very very soon.
No. I have no idea how to create an opkg. Perhaps I'll look into it at some point. Somehow an opkg is actually many packages, one for every router architecture supported !
I just compiled the thing using the openwrt tool chain and used scp to copy the executable to the router:
I think that is actually the only file we need on the router for getting regular Spin or other binaries into a Propeller.
BUT for those crazy C setups that use all kinds of different external memory hardware on the Prop there is a ton of other files required. I'll try those out if an when I see the basic loader working.
I had to hack the loaders Makefile a bit to get this compiled but I should be able to write some instructions for building it that anyone could follow easily for their own brand of router.
If you can tell me exactly which OpenWRT binary you have flashed your box with I can probably make a loader for you here quite quickly.
I have Minicom successfully installed, but haven't gotten my Wifi and RS232 sorted out quite yet for connecting the RS232 with a Propeller. Until I get the Wifi connection back, it would be a disaster to shut out the Serial Console from the RS232 for other purposes (I am unsure what I'd have to do to get it back)
The Wifi does connect via LuCi and SSH when it is working right. That is the lynch pin to hyjacking the RS232 port.
More later. I am having a lot of fun and looking forward to having Propeller in Forth with a direct wifi access 24/7. There are many times that home automation projects have been abandoned just because I didn't care for the idea of having CAT5 cables spread all over my living space.
The WR703N or MR3020 can sit with the Propeller and next to an electrical outlet. I even already have a 12VDC gel cell backup power configuration that would hold the Propeller board and MR3020 as well with a few relays, maybe a sensor or two. I have some LM35 sensors for temperature.
All good fun.
Now, which OpenWRT binary did you load to your router?
Check out curl and wget to get the public IP, you can put the command in a shell script as well, here are some examples:
Get your external IP address using the curl command :
$ curl ifconfig.me
$ curl ip.appspot.com
$ curl icanhazip.com
Get your external IP address using the wget command :
$ wget -q -O - ifconfig.me
$ wget -q -O - ip.appspot.com
$ wget -q -O - icanhazip.com
http://www.shellhacks.com/en/What-is-my-Public-IP-address
I did a preliminary run of the Minicom by entering 'minicom -s' at the prompt (this is the setup mode) and it came right up with all the configuration slots empty. If you don't know Minicom, it might help to play with it on another Linux machine to figure out how to setup. But there isn't really much to do.
1. input a path to /dev/ttyANTH0
2. set the baud rate, bits and parity according to the desired target.
3. exit set up and set if it will interact to bring up a Forth prompt.
**************************************************************
Everything was going so wellll................ until I decide to clean up the /etc/config/network and /etc/config/wireless.
Now my wifi login protocol is going haywire.
And so, I keep stubbling foward. I still have the RS232 Serial Console to fix my messes.
This is probably because the router you're connected to has the time/date wrong, so anything time/date sensitive like in this case ssl certificates (have expire date) will complain about expired or wrong information, try to correct the time and date on the router and try again.
+++++++++++
More progress. --- very very close to Milestone ONE - LAN to Serial to Forth on the Propeller.
Heater is also very very close to achieving Milestone TWO - Loading Propeller binaries via an OpenWrt wifi router.
I have managed to once again get out of another 'shut out' mess due to my trying to reconfigure /etc/config/wireless and /etc/config/network in what I thought should be the correct way. I just rolled everything back to my original set up.
I certainly have a lot more to learn about configuring routers, but for now that is all being set aside.
++++++++++++++++++++
This clean up gave me an opportunity to try out Minicom with the actual serial port - /dev/ttyANTH0.
Proceedure
I had to go into it with 'minicom -s' and then open the menu for Serial Port Setup and select Item A.
In Item A, I put in /dev/ttyATH0
and exited the menu system
Success.. with an external Loopback (Tx wired to Rx), I get an echo of my keyboard input at the screen. When I disconnect the wiring, no echo.
I did leave the Serial Console active to see how it interfers with communicaitons. If I hit <enter>, the Serial Console will take my keyed in material as a command and respond accordingly. This is what should happen with a loopback. What happens in another setup would be different, but would also mess with the Minicom's main purpose.
So, NOW is the time for me to verify I have a running Propeller Board with Forth.
Then I will turn off the Serial Console and connect the Propeller Board.
And finally test to see if Minicom will communicate without problems... baud rate is set at 115200 8N1.
This is where I got it:
http://www.ebay.com/itm/321377517019?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Sounds like good progress.
januxnet, I seriously hope this is not the case. No router between me and the servers I'm talking to should have anything to say about security. Routers should just route my packets. They have nothing to say about the validity of certificates or any other crypto mechanism I use.
It is possible that the time/date was wrong on my PC I guess. But I have not notice such.
Was I the only one who had this problem?
Anyway. It seems to have gone away. I have not touched any times or dates anywhere.
Loopy,
Why are you so reticent about telling me which OpenWRT firmware binary you loaded into your router?
That looks like a great deal. Looking forward to seeing how it goes.
Why? I guess I didn't understand the question. I replied that I loaded the minicom opkg package, but I guess you want to know which firmware.
I used the latest Attitude Adjustment. V12.09
openwrt-ar71xx-generic-tl-mr3020-v1-squashfs-factory.bin
as found in a link on this page http://wiki.openwrt.org/toh/tp-link/tl-mr3020 See the Installation Section.
+++++++++++++
Physical Loopback is working fine with Minicom inside the MR3020, but I can't seem to get the Propeller Proto Board loading with Forth at 115200 baud 8n1 to respond.
The same board works fine with a USB2SER plugged into it.
I did turn off the Serial Console in /etc/initab per this ===> http://morethanuser.blogspot.tw/2012/10/rs232-on-openwrt-mr3020.html
"Change file /etc/inittab, comment out serial console initialization (example below), save and reboot your router."
# ttyATH0::askfirst:/bin/ash --login
OK thanks.
The reason I ask is because I am going to try and build that image from the source code and tool chain provided by OpenWRT. I just wanted to be sure I built the right thing.
Then I can use the resulting cross compiler to build a Propeller loader.
If that works on your router, and Cluso's, then I will continue with the next steps.
I was surprised to find that your routers are also MIPs machines and not ARM.
The RS232 port at /dev/ttyATH0 seems to be quite attached to the Serial Console functions due to choices in the Kernel compile.
While I can turn off most of it, it seems that the Standard Error output dumps to the Serial Console regardless of changing the /etc/inittab.
Best wishes.
If you have PropPlug that shows up as /dev/tty/USBxx then it's even possible that with this one loader executable you will be ready to program a Prop.
Do you have a way to test if a PropPlug does show up when you plug it into the USB port?
Attached is a propeller loader which I hope has been compiled with the right compiler and options for your routers.
It will need unpacking. I'm not sure if this can be done on the router itself. So on the PC:
$ tar -xvzf propeller-load.tgz
Then transfer to your router:
$ scp propeller-load root@a.b.c.d:
Then login in to your router and see if it runs:
#./propeller-load
No, it does not understand using GPIO for Prop reset yet.
It possibly, maybe will work over a USB/Serial connection. Like a PropPlug.
Yes, they are MIPs processors.
heater, is the binary you generated for propeller loader the same as yours? I think it might be as there might be no real differences????
Welcome to the fray Mike. That's a good price.
I have tested all the hardware, gotten all the software set up and tested; but seem to have hit a snag with direct TTL from the MR3020 to the Propeller Protoboard.
1. The MR3020 ttl RS232 works fine with Minicom and a hardwire loopback attached to the far end of the RS232 cable at 115200 8N1.
2. The Propeller Proto Board with Forth loaded works fine via a USB2SER when connected to my notebook's terminal program.
3. The MR3020 in Serial Console mode works fine with the USB2SER when connected to my notebook's terminal program.
BUT...
when I connect the MR3020 directly to the Propeller Protoboard, nothing.
It seems like a TTL level incompatibility. I don't have a scope to confirm. But both the Propeller Protoboard and the MR3020 RS232 port are very happy to operate at 115200 8n1 with the USB2SER. So I just do NOT get what is going on.
Maybe I will discover something I overlooked.. later today.
****************
@Heater
I downloaded your Propeller-load.tgz for later evaluation. I presume this is an ar71xx targeted binary that you have provided.
What?! Nobody tried to run their loader yet. Shameful.
I now have compilers for two openwrt architectures:
For Atheros AR7xxx:
toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/bin/mips-openwrt-linux-gcc
For RaLink:
toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-gcc
They produce very similar looking propeller-loaders:
$ ls -l propeller-load-mips*
-rwxr-xr-x 1 heater heater 133984 Jul 26 10:09 propeller-load-mips_24kec+dsp
-rwxr-xr-x 1 heater heater 133960 Jul 26 10:07 propeller-load-mips_34kc
$ file propeller-load-mips*
propeller-load-mips_24kec+dsp: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
propeller-load-mips_34kc: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), not stripped
The "24kec+dsp" loader runs on my router. The "34kc" does not.
I'm hoping that is the other way around for you guys!
Well of course, I'm a dumb Smile.... "mipsel" is for operating in little endian mode on the MIPS processor. As opposed to "mips" which is big endian. Notice how the "file" command above tells you that in it's output "LSB" vs "MSB". Unlike Intel x86 the MIPS processors can do both.
This is similar to "arm" and "armel" GCC compilers for ARM.
In the middle of the night I had this great idea to add a port forwarding rule to allow the web server on my PC to be reached from the internet.
Easy right? Just go to Luci->Network->Firewall->Port Forwards and fill in the ports and address...Done it a thousand times before on other routers.
Hit "save and apply". BOOM no more internet connectivity from my PC or anywhere. No more ssh'ing in on 192.168.1.1
Being lazy I just reflashed the thing, got basic internet connection back and went to sleep.
In the morning it was time to reenable the WIFI connection. Easy right? Just go to Luci->Netork->WIFI, enable WIFI and set the ESSID/key.
Again. BOOM no more internet connectivity from my PC or anywhere. No more ssh'ing in on 192.168.1.1
WTF?
Of course I may have done something dumb. I can't see it, and WIFI enabling worked fine the other few times I have done it in Luci.
Except for one little detail. On both these occasions I had a propeller-load binary on the box. It is possible that caused the file system to fill up causing Luci to fail when rewriting configs.
The really dumb thing here is ignoring the rule "Never ever mess with a working system unless you really have to!"
Hmmm.... shut out completely?
I thought I was the only one that was getting off into that patch of weeds.
My own impressions are that there may be some sort of disconnect (a bug maybe?) between the three configuration methods - [a] direct editing of the /etc/config/ files via VI, the cgi method of configuration, [c] the use of LuCi.
And so I have tried to rely of the lowest means, direct editing of the /etc/config files. But it is important to restart the service you reconfigure. This can be done selectively, but I just use 'reboot' and do it in a wholesale fashion.
There are some configuration pages that are Must Read material that I have yet to master. Here are the links
http://wiki.openwrt.org/doc/uci/network
http://wiki.openwrt.org/doc/uci/wireless
http://wiki.openwrt.org/doc/uci
I haven't at all mastered network design and configuration.
And at one point yesterday, when rewriting configuration to the /etc/config/wireless and /etc/config/network files, it seems to have rolled back from 192.168.3.1 being my MR3020 network to 192.168.1.1 (the default). I am not sure if I typed something wrong, or if the reconfiguration caused the device to refer squashfs for the settings rather than the jffs2 updates.
My old EEEpc 701-4G had a similar squashfs/jffsh2 configuration. And jffsh2 may require large blocks of data be rewritten when updated. So this could be a source of some odd reconfiguration behaviors.
Just remember that squashfs never changes and sits there to be referred to many times and in many ways. In fact, you might have gained entry over your RS232 port, dumped jffsh2 and started anew without resorting to reflashing an image from afar.
++++++++++++++
BTW, monitor your memory available as you load items in. A full file system will cause a lockup. On my device, OpenWRT claims it will also launch a blinking LED. But I can't be sure what you have done with your LEDs at this point.
I will take a look at my remaining available memory before I load your binaries. (And even then, I will keep an eye on what might happen.) You need to have 32K extra space (and maybe more) for the Propeller binary. And you may need to purge any binary before trying another or you just eventually run out of memory.
Ah yes, the brior patch!
Locking yourself out of somewhere by changing network configuration is an occupational hazard. It's another reminder of what I said about that "labyrinth with mines".
I think you will find that the OpenWRT guys expect you to use uci when configuring things over a command line rather than hacking on config files. They did not go to all the trouble to make it for nothing. It does ensure that you don't get any typos in the configs and provides a means to apply and make the changes active.
I think you will find that Luci uses uci. There is a reason she is called Luci.
As for file system usage. Yep, best to keep an eye on it. We are so spoiled with tera bytes on PC's we tend to forget about it.
The propeller-loader I have here is 120KBytes after stripping out symbols. df on the router tells me I have all of 156K free without the loader. Eeek!
And I seem to have noticed (but I am not 100% at this point) that changes made via the UCI are not always reflected as updates to the respect /etc/config/ files.
Sorry, but I have not had the time to investigate this... but it might be true. There seems to be some EEPROM or persistent registers that might be directly written to.
Yes, LuCi is an extension of UCI over http in a mysterious (to me) secure manner. But it doesn't seem to allow all and everything that a Command Line can do.
I suspect that Cluso and myself have quite a bit more space to work with. After loading Minicom, I still have roughly 650Kbytes available.
Tight spaces are wonderful for teaching computers. You have to look for better solutions rather than just feed the bloat. And you gain a lot of knowledge of computer history along the way. This is why I like the headless Linux setup herein. The whole GUI is yet another big distraction to learning the basic backbone of computers.
Have you been remembering to "commit" the changes you make in uci?
Like "uci commit network"
For sure Lucy does not give access to all possibilities. That is in the nature of GUIs.
Wow! 650KBytes. That is is enough for anyone. As someone famous is supposed to have said.