Huawei E3372 with OpenWRT#
Sat, 12 Nov 2016 22:25:34 +0000
I've just moved house. The new house has no broadband or even phone
line, and when I last asked about the progress of getting a line
connected I was told that "Your order is currently in the newsites
stage and the offsite ducting has started" and it was going to take
most of a month before I could even start ordering broadband.
Which means I need mobile broadband stuff. I looked on Ebay for USB
LTE sticks, and I looked on comparison sites for cheap data SIM-only
deals, and ended up with a Huawei E3372h. To make this work with
OpenWRT took a couple of evenings swearing at it, so here's the end
result: note that all of these things were for me sufficient but may
not be to you necessary.
- I flashed the current OpenWRT snapshot for my device (TP-Link
TL-WR842ND, an ar71xx variant). (Quite likely the latest release
version would do just as well, but this was part of aimless "why does
it not work" casting around, and I can't be bothered to downgrade it
- I installed these packages:
- I amended the 'WAN' clause in `/etc/config/network` to look like the following:
config interface 'WAN'
option proto 'ncm'
option apn 'everywhere'
option ifname 'wwan0'
option pdptype 'IP'
option device '/dev/ttyUSB0'
option delay 15
- I tried a whole load of other stuff but it was all dead ends. In
particular, there was no need to do anything with reflashing the
stick to different firmware versions or Web UI versions, and there
was no need to mess around with manual
usb_modeswitch stuff: there
is a mode switch involved but OpenWRT already knows how to do it
I get about 12-17Mb/s (over wireless, sitting next to the router)
according to fast.com which is not superfast
considering the hardware is supposed to be capable of 150Mb/s and the
package I'm paying for is "up to 60Mb/s". There may still be
something I'm missing in the configuration. Whether I spend much more
time looking at it is going to depend mostly on how much faff it takes
to get proper broadband installed. It might be a while
I can't believe it's not buttons#
Thu, 13 Oct 2016 23:03:30 +0000
"Second will be some slightly nicer play/next/previous buttons". As
predicted. I don't claim they're pretty, just that they're an advance
on what went before.
Next: through a combination of dogfooding and Agile backlog
reprioritisation, I as the product owner and customer representative
have determined that I as the development team should next tackle
"make it not behave apparently randomly when adding tracks to the
playqueue after it has played what was previously in the queue".
Maybe in the process I can reduce the number of arbitrary reference
cursors that are littered thoughout it.
Wed, 12 Oct 2016 23:02:46 +0000
In between my ongoing attempts to buy a
I am still playing on and off with making Sledge into a thing I might
actually want to use. First on the list is showing the
currently-playing track name and not just its length. Second will be
some slightly nicer play/next/previous buttons. Third, maybe making
it more robust against pressing "refresh". Ongoing and not yet
finished, stripping out the cheesy CSS text shadows etc to make it
look less like a 1990s OSF/Motif application and more like "flat UI" -
a design trend of which I thoroughly approve. I will be terribly
disappointed when the fashion pendulum swings back towards requiring
artistic skills for a web page to look modern, because (as you can
see) I have none.
(Why is this blog entry titled "Plank"? What else would you call a
Mostly because I like to see my referrers#
Wed, 21 Sep 2016 21:56:44 +0000
I can think of no security justification for encrypting the pages
served by this site: the data is public, viewing it is unlikely to get
you arrested in most jurisdictions, it doesn't have any kind of forms
or upload facilities or anything - but, I would like to see
referers(sic) in my server logs. So now it's all HTTPS, using the
rather fantastic Let's Encrypt service.
Let me know if you see anything broken as a result (i.e. anything
broken that wasn't already broken) or can think of a principled reason
by which I can justify the (admittedly rather paltry) time I spent on
Giving clojurescript the boot#
Mon, 19 Sep 2016 21:58:57 +0000
Recently I decided to unearth
and fix enough of the bugs in it that I will actually want to use it
day-to-day, and because changing only one thing at a time is too easy
I thought I'd try updating all its dependencies and moving it from
Leinginen to the new shiny Boot Clojure build
First impressions of Boot:
- it appears to be a much more general purpose build tool than
Leiningen in that it prefers you to compose your build process from
self-contained parts instead of being a battalion of special-cases.
- the documentation of how to do ordinary things (like "build a jar file that you can give to someone who doesn't have Clojure already") is somewhat lacking
- Googling won't save you either: accounts of its use on third-party sites are often written for older versions
Point 1 is in my judgment so far a compelling reason to perservere
through the pain of points 2 and 3.
I did a little gist already for making an uberjar with
and you should definitely pay attention to line 25. But today I want
to talk about defining your own tasks, and as an example I'm going to add
support for building Clojurescript.
The well-informed reader will know that there is already a Boot task
to compile ClojureScript
programs on Github. I chose
not to use this, mostly because I was getting error messages I didn't
understand and also partly because the Clojurescript Quick
page so strongly recommends understanding the fundamentals of
compiling Clojurescript before plugging in a tool-based workflow.
So. Here are some things you may or may not already know about Boot
if you've previously been using it by cargo-cult:
- You tell Boot what you want it to do by composing tasks into a build
- Each task defines a handler .
A handler accepts a fileset, does something (e.g. compiles some
files to create output files) and then calls the next handler with a
new fileset which represents the passed fileset plus the result of
whatever it did. It's a lot like Ring nested middleware. The first
handler in the pipeline gets a fileset consisting only of the input
files (your project source files), calls the second which calls the
third etc, and once all the nested handlers have run then the
returned fileset contains all the output files.
- From the end-user or even the task author's point of view, filesets
are immutable. Handlers never directly change or create files
in the project directory - instead they always create a new fileset,
and Boot copies/moves files around in temporary directories behind
your back to maintain the abstraction. As a task writer you don't
have to care too much how this works: there are functions to map
between fileset entries and the full pathname you should use to read
the corresponding file; also to create a new temporary directory for
output and then to add the files in that directory to a fileset.
And here are some things about the Clojurescript compiler which
probably should be apparent from reading the Quick Start and the code
it refers to:
- The compiler API lives in ns
and the important bits are
which creates a 'compilable object' from the directories/files you give it,
which does the compilation.
- Contrary to anything you might have thought by reading the doc
inputs - it does not accept "a list", it accepts multiple
arguments. If you have a list you will need to use
apply here. I
wasted a lot of time on this by not reading the code properly.
So, how do we marry the two up? Look upon my
ye mighty and despair ....
A task is a function that returns a middleware, which is a function
that returns a handler. This is not super-obvious from the code on
display here, because we're using a small piece of handy syntax sugar
with-pre-wrap which lets us provide the body of the handler
and returns a suitable middleware.
What else? Not much else. This code lives in the
namespace and gets
. We have to override and/or augment what the user passes for
output-dir to make sure it ends up somewhere it'l
get added to the fileset instead of writing straight into the project
working directory. And I haven't decided how to do a repl yet. I
will probably add that (one way or another) before merging the
das-boot branch into