[{"_1":2,"_161":-5,"_162":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_140":141},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","routes/_layout",{"_19":-5,"_20":21,"_22":21,"_23":11,"_24":21},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_27":28,"_29":-5,"_30":11,"_31":11,"_32":33,"_34":35,"_36":-5,"_37":11,"_38":39,"_88":-5,"_89":90,"_129":-5,"_130":11,"_131":21,"_132":11,"_133":-5,"_134":11,"_135":-5,"_136":137,"_138":91,"_139":-7},"canonicalUrl","https://hub.docker.com/r/zoobab/glar150/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","zoobab","reponame","glar150","cloudBuildSource","isAutobuildsAvailable","repo",{"_40":41,"_42":43,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":55,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":74,"_79":21,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2016-03-10T12:51:34.078642Z","description","full openwrt build of the Zeromq glar150 project (zeromq+czmq+zyre+glard).","is_private","last_updated","2020-10-16T19:03:57.746397Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",1412,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","[![noswpatv3](http://zoobab.wdfiles.com/local--files/start/noupcv3.jpg)](https://ffii.org/donate-now-to-save-europe-from-software-patents-says-ffii/)\n# Glar150\n\n## Background\n\nWe bought a bunch of [GL-AR150 OpenWRT routers](http://www.gl-inet.com/ar150/) off Amazon.com, and wondered what fun we could have with these. These are tiny, cheap WiFi servers ($25). They look cool, with an antenna that makes me think of my old metal-body Ericsson R520m. Now that was a phone you could crack skulls with!\n\n## Exploring the Hardware\n\nUnlike the Ericssons of yore, the GL-AR150 (which I will call the \"Glar\" from now on, or \"Glar 150\" if you want to be specific) has no on/off switch. You provide power, it comes on. You remove power, it goes off. This works especially well with modern power packs that have auto power-on. About half the power packs we tested have \"auto power-on and then random power-off when no-one's looking\", so be warned. The Glar has a reset switch you can hold and press to reset your router configuration. It also has a rocker switch, status lights, a USB port (controllable power via GPIO), an external antenna in the version we chose, and two RJ45 sockets. All in a nice simple case. Nice!\n\n### Seeing Red\n\nOur first experiment was to run [Malamute](https://github.com/zeromq/malamute), a tiny message broker. This worked nicely. Building for OpenWRT takes a little cross-compiling black magic, yet our ZeroMQ software stack runs perfectly on this box, as it should.\n\nNext we wondered, could we attach large LEDs to those I/O pins? A real computer has flashing lights. Turns out the red rear lights from my kids' bikes take 3V, and a quick test showed the Glar could power these easily. Luckily my kids weren't paying attention, so I nabbed the lamps and we opened them up.\n\nThese bike lamps cost EUR 1.39 each, so we didn't feel bad about cutting out the on/off button and soldering wires directly onto the PCB. Let me explain briefly how we power and control the lamp. We have two wires, one feeds the PCB with power. The other takes the used electrons from the PCB and sends them to the recycle bin we call \"ground.\" The Glar opens real easy, just pull off the bottom cover and then ease out the PCB.\n\nMost of the Glar's already tiny volume is used up by legacy connectors. If we didn't have those two network plugs and the USB slot, it would fit into a case a quarter of the size. The Glar has 16MB flash and 64MB RAM, and is powered by a [32-bit MIPS core](http://www.gl-inet.com/ar-specifications/). It's not meant for heavy duty. The CPU technology is a decade old. It is cheap and low power.\n\nLet me quantify this. When we tested Malamute, we compared a Glar to a modern laptop. The workload is a mix of network I/O, memory copying, and computation. We tested on Ethernet, since it is so easy to saturate WiFi that it's useless for comparisons. The laptop can push around 200,000 messages per second between publishers and subscribers. The Glar can do around 5,000 per second.\n\nAs for power consumption, a laptop draws 10-20 Watts, whereas the Glar draws under 1 Watt. What this means in practice is that the Glar will run for 12 hours off a small LiPo battery pack. I opened up one of our little battery packs. Inside there's what looks like a camera battery. This would fit neatly inside a Glar case, methinks. Aha, looks like GLI are developing [a battery-powered version](http://www.gl-inet.com/m9331-mifi/).\n\nBack to the red light. Here's a shell script that switches it on and then off:\n\n```\necho 1 > /sys/class/gpio/gpio1/value\nsleep 1\necho 0 > /sys/class/gpio/gpio1/value\n```\n\nWe need to prepare the GPIO at startup:\n\n```\necho 1 > /sys/class/gpio/gpio1/export\necho out > /sys/class/gpio/gpio1/direction\n```\n\nControlling the lamp from C is then easy:\n\n```\nchar *value = \"1\"; // Or \"0\" to switch off\nint handle = open (\"/sys/class/gpio/gpio1/value\", O_WRONLY);\nif (handle != -1) {\n if (write (handle, value, strlen (value)) == -1)\n printf (\"can't write to GPIO 1\\n\");\n close (handle);\n}\n```\n\n### Blinken Lichten\n\nThe Glar also has three status LEDs. You can play with these using GPIO (they are GPIO 13, 15, and 0 (aka 16)). There is a preloaded kernel module that controls them, so we don't use the raw GPIO interface. Instead, we speak to this module by writing to a sysfs system device:\n\n```\n/sys/devices/platform/leds-gpio/leds/gl_ar150:wan/brightness\n```\n\nFrom left to right LEDs are called \"wan\", \"lan\", and \"wlan.\" The wlan LED is red, the other two are green. So again, from C they are easy to control:\n\n```\nchar *value = \"1\"; // Or \"0\" to switch off\nint handle = open (\"/sys/devices/platform/leds-gpio/leds/gl_ar150:wan/brightness\", O_WRONLY);\nif (handle != -1) {\n if (write (handle, value, strlen (value)) == -1)\n zsys_error (\"can't write to LED device\");\n close (handle);\n}\n```\n\nIt is possible (we think) to unload the LED module, and then control these lights through the GPIO interface, as we did for GPIO1. This would make the code more consistent. It's not worth the effort though. Note that the Glar has 16 GPIOs of which eight are standard 2.54mm (0.1\") physical pins. The other eight are wired to various bits and pieces like the rocker switch.\n\n### The Rocker Switch\n\nThe rocker switch actually has three positions on the PCB, which was confusing enough that the designers made space for just two positions on the case. You can drill out the hole to get a third position if you absolutely love the tertiary counting system. Anyhow, reading the switch is easy, it's GPIO 8:\n\n```\nint handle = open (\"/sys/class/gpio/gpio8/value\", O_RDONLY);\nif (handle != -1) {\n char value [2] = { 0, 0 };\n if (read (handle, value, 1) == 1)\n if (*value == '1')\n // Switch is off\n else\n // Switch is on\n }\n close (handle);\n}\n```\n\nNote that a value of \"1\" means the switch is at the 'Off' position. If you use the third position, you will want to read GPIO 7 as well.\n\n### Other Possibilities\n\nWe can get 3V and perhaps 50mA from the GPIO. It's enough to drive those LED bike lamps. For more demanding applications the Glar lets you control the USB power via GPIO 6. You could also connect an external power relay to switch your heating on and off remotely, for example.\n\nThe reset button uses GPIO 11 and you could (I assume, we did not test) use this as a control switch. It's probably not the thing you want to interfere with.\n\nFinally, of course, the Glar is a network animal and this is where its real power comes to play.\n\n## Building a Glar Cluster\n\nWhat's the fastest, simplest way to connect a bunch of Glars together in a cluster?\n\nI'd say (totally biased, since I wrote this project), use [Zyre](http://zyre.com). That's a clustering library built exactly for this purpose: a bunch of things on WiFi want to talk to each other. Zyre uses ZeroMQ and is written in C. There are Python and Java versions.\n\nIt is distressingly easy to use Zyre in your code:\n\n```\nzyre_node_t *zyre = zyre_new (NULL);\nzyre_set_interface (zyre, \"wlan0\");\nzyre_start (zyre);\nzyre_join (zyre, \"GLAR\");\n```\n\nThis kicks off a Zyre node and joins the GLAR group so it can chat to other nodes in the same group.\n\nBuilding Zyre for OpenWRT is a little more challenging. I don't actually know how this works, since my colleague Zoobab does this. He takes libzmq, CZMQ, Zyre, and the Glar150 code, waves his hands, and magic happens. When he gets back from lunch with my sandwich (it's been about three days now and I'm starting to get a little worried, and also hungry), we'll write some explanations.\n\nAnyhow, once Zyre is up and running it is trivial to send a message to all nodes:\n\n```\nzyre_shouts (zyre, \"GLAR\", \"%s\", \"Hello, World\");\n```\n\n## Let's Botnet\n\nI had this vision of throwing code at a network of devices. It's a lot like the Web (device = browser, code = webpage + JavaScript). It's a lot like botnets (device = your family PC, code = evil stuff).\n\nSo our first idea was to run a JavaScript engine on the Glars, and shout JavaScript at them using Zyre. *Bad idea.* JavaScript is a fine, fine language. It's just not yet ready for the embedded world. There are small Javascript engines like JerryScript. They do not build and run on the MIPS processors that many OpenWRT routers use.\n\nAfter a few days of failing to get anything remotely like JavaScript running on a Glar, we wondered. What's the simplest possible language for remote execution? I mean, these things all run root, so what's the *worst* that can happen, right?\n\nHow about shell scripts?\n\nAh, so imagine my laptop, connected to the Glar/Zyre network, doing this:\n\n zyre_shout (zyre, \"GLAR\", \"df\");\n\nWhere each node runs that command, grabs the results (`man popen` is your friend) and sends it back to the controller laptop. Turns out that works nicely. Secure? Yes, as we're on a private, secure WiFi network.\n\nEventually I'd like a proper remote control language. Something compact, safe, and threaded. In the meantime we might use more shell. Yet for now, we were distracted by the flashing lights.\n\n## More Threads\n\nWorking with lights and buttons immediately gave us a challenge. How do we deal with many devices, often with timing dependent operations like \"wait for 200msec before turning off again\" from a single thread?\n\nI mean, it's possible to do a lot of async work in a single thread. You need to set up timers and a lot of callbacks and `select()` or `epoll()` calls for network I/O. There are entire libraries that do this, like `libuv` and `libzmq`. I'm rolling with `libzmq` as it's kind of the Swiss Army Tank of lots of stuff happening at once, all over the place.\n\nThe old `libzmq` library API is as friendly as a squad of soldiers in unmarked uniforms brandishing shiny AK-74Ms. It does the job, yet you don't really want to be there when it happens. A much nicer API is [CZMQ](http://czmq.zeromq.org), which hides the cold brutality that is high-performance messaging under a cloak of charm.\n\n## The World is Our Stage\n\nOne thing CZMQ gives us, which turns out to be really useful in our demo, are *actors*. An actor is a thread that you talk to over a ZeroMQ socket. It is not a complete actor system like Erlang or Akka actors. Yet it is a really neat way of dealing with concurrency.\n\nLet me give one example of where we need an actor. When we run as a console, we talk to a number of Glars (aka the \"Robot Army\"). Our UI is simple: take one command line from the user, blast it at the robot army. The problem is that `fgets` is blocking. What we need is a non-blocking `fgets` that waits for input, and lets us talk to the robot army at the same time.\n\nSo for instance, while the user is happily typing `rm -rf /*` the console can be getting events like JOIN and LEAVE from other Zyre nodes.\n\nHere is what [the actual console actor](https://github.com/CodeJockey/glar150/blob/master/src/glar_node.c#L38) looks like:\n\n```\nstatic void\ns_console_actor (zsock_t *pipe, void *args)\n{\n zsock_signal (pipe, 0); // Tell caller we're ready\n while (!zsys_interrupted) {\n char command [1024];\n if (fgets (command, sizeof (command), stdin)) {\n // Discard final newline\n command [strlen (command) - 1] = 0;\n if (*command)\n zstr_send (pipe, command);\n }\n }\n}\n```\n\nTo start the actor we do this:\n\n```\nzactor_t *console = zactor_new (s_console_actor, NULL);\n```\n\nAnd to stop it, we do this:\n\n```\nzactor_destroy (&console);\n```\n\nWe can read one command from it (a line of text the user typed) like this:\n\n```\nchar *command = zstr_recv (console);\n```\n\nThough in practice we use a `zpoller_t` object to wait on several actors at once:\n\n```\n// Create a set of actors and a poller\nzactor_t *panel = zactor_new (panel_actor, NULL);\nzactor_t *morse = zactor_new (morse_actor, NULL);\nzactor_t *console = zactor_new (console_actor, NULL);\nzpoller_t *poller = zpoller_new (panel, morse, console, NULL);\n\n// Deal with messages from actors, until we get Ctrl-C\nwhile (!zsys_interrupted) {\n zactor_t *which = (zactor_t *) zpoller_wait (poller, -1);\n if (which)\n break; // Nothing, so poll was interrupted\n zmsg_t *msg = zmsg_recv (which);\n ...\n}\n// Destroy our objects\nzpoller_destroy (&poller);\nzactor_destroy (&panel);\nzactor_destroy (&morse);\nzactor_destroy (&console);\n```\n\n### Reading The Button State\n\nLet me show some an actor that does GPIO. We'll look at the actor that reads the button state. What the code has to do is quite simple: check the button and tell the main thread when the button changes from off to on, or vice-versa.\n\nThere is no async I/O on the button so our code is brutal: wait for a short time, check the button state, see if it changed, and repeat until the process ends.\n\nHere is the actor function for that:\n\n```\nstatic void\ns_button_actor (zsock_t *pipe, void *args)\n{\n zsock_signal (pipe, 0); // Tell caller we're ready\n int last_value = 0; // Assume button is off\n zpoller_t *poller = zpoller_new (pipe, NULL);\n\n while (!zsys_interrupted) {\n if (zpoller_wait (poller, 250))\n break; // Caller told us to terminate\n\n int handle = open (\"/sys/class/gpio/gpio8/value\", O_RDONLY);\n if (handle != -1) {\n char value [2] = { 0, 0 };\n if (read (handle, value, 1) == 1\n && last_value != value [0] - '0') {\n last_value = value [0] - '0';\n zstr_send (pipe, value);\n }\n close (handle);\n }\n }\n zpoller_destroy (&poller);\n}\n```\n\n### Morse Code Actor\n\nA separate thread (an actor, [glar_morse](https://github.com/CodeJockey/glar150/blob/master/src/glar_morse.c)) turns commands into Morse code and blinks them on the large red lamp.\n\nUsing an actor here means we can send off a Morse sequence and let it run in the background, while doing other work.\n\n## Finite State Machines\n\nWith our actor framework we have events like console input, Zyre events, and button change events coming into a single main thread. The main thread, however, has several states. We could be running as a console, or as a robot, and we could be in emergency state.\n\nA nice and robust way to handle events in different states is to use a `finite state machine`. This is a logical model that specifies each state, and each event. Here is the full state machine for the main thread. We write it as XML, so that we can use the [GSL code generator](https://github.com/imatix/gsl) to turn it into C code:\n\n```\n\n\n\n \n \n \n \n \n \n \n \n\n\n\n \n \n \n \n \n \n \n \n\n\n\n \n \n \n \n \n \n \n \n \n\n\n\n \n \n \n \n \n \n \n \n \n \n \n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n\n```\n\nThe [code generator](https://github.com/CodeJockey/glar150/blob/master/src/fsm_c.gsl) is a GSL script that takes the XML and issues C code, a long `case` statement in our case. There are other ways to make FSMs, especially using tables. This is the simplest, and fast enough.\n\n## Building the Code\n\nStill to be written.\n\n## Run a demo with multipe docker containers\n\nThe glard daemon has been rewritten to drop the GPIO blinking features at last\nZMQ hackaton.\n\nIt can now be used to launch commands on multiple slaves.\n\nA simple way to test the glard daemon is to use a docker container which spawns a glard daemon:\n\n```\n$ docker build -f Dockerfile.obs -t glard\n```\n\nYou should then have an image named \"glard:latest\" in \"docker images\".\n\nIf you want to avoid building the docker image, there is one prebuilt for you:\n\n```\n$ docker run zoobab/glar150\nglard v1.0.1 -- GL-AR150 demo'n\nI: 17-11-01 18:08:26 using interface=eth0 my_uuid=1CF2281F0C9A4DD596C29EF1EF2F5C17 my_name=1CF228\n```\n\nThen spawn 3 containers running glard:\n\n```\n$ docker run -d glard\nb6d495af00604457061bd13fce0867f097fccfe569c074c9869fb2c0c047bf4e\n$ docker run -d glard\n5af819f9d7123acc407aa6cefcb992ca2b59fc06a191b6dc4d5fd590cea95f44\n$ docker run -d glard\ncafe37cf9499d9f64f55b9154b84d93038912ae091033e2f09aecd97b71499cd\n```\n\nThen launch the fourth one with the controller \"-c\" and the interactive shell:\n\n```\n$ docker run -it glard -c\nglard v1.0.1 -- GL-AR150 demo'n\nI: 17-11-01 17:52:04 using interface=eth0 my_uuid=C3A0AA7977B943D68AD5B7E1A5B8AEB4 my_name=C3A0AA\nI: 17-11-01 17:52:04 JOINED peer=5A793D\nI: 17-11-01 17:52:04 JOINED peer=CB5DA2\nI: 17-11-01 17:52:04 JOINED peer=9EA303\n```\nYou should then type the command \"pwd\" and observer that it is launched on the\n3 slaves:\n\n```\npwd\n9EA303: /\n\nCB5DA2: /\n\n5A793D: /\n```\n\nIf you launch the \"hostname\" command, you should find the names of the 3\ncontainers that were launched earlier:\n\n```\nhostname\n5A793D: 5af819f9d712\n\n9EA303: b6d495af0060\n\nCB5DA2: cafe37cf9499\n```\n","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":21,"_83":11,"_84":11},"read","write","admin","user","storage_size",158074079,"orgData","recentTags",[91],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},"content_type","creator",12911,"full_size",76971220,"id",17376964,"images",[101],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},"architecture","amd64","digest","sha256:e9aca49a8498d8717c4b0c7b5b7b59be53fc86376ed07bdc77184698351e2463","features","","last_pulled","2026-09-30T05:56:11.797386947Z","last_pushed","2020-10-16T19:03:58Z","os","linux","os_features","os_version","size","variant","2020-10-16T19:03:57.382893Z","last_updater","last_updater_username","media_type","latest","repository",571523,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":142,"_149":150,"_136":159,"_160":11},{"_40":143,"_42":144,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":145,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":146,"_79":21,"_80":148,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":147},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_151":64,"_152":-5,"_153":-5,"_154":155},"count","next","previous","results",[156],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":157,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},[158],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},[],"canDeleteTags","actionData","errors"]

zoobab/glar150

Tags for zoobab/glar150