[Battlemesh] [FCC] What hardware still works?

[Ben West]

A Nanostation taking one OpenWRT image but not another OpenWRT image
suggests a problem in the image itself, maybe not the bootloader.  Do be
mindful the Nanostation M5's have a new "XW" hardware generation.  If you
radio is an XW, you need to use the OpenWRT image compiled for that
specific platform (I believe it has "xw" in the image name).

Besides that, if it helps, I've just ordered a TL-WR1043ND new (i.e.
instead of used off Ebay), to see what number that roulette wheel settles
on.  I can report my experience back here.

Repeating a question from earlier, how about recording on a wiki the list
of working hardware, along with known work-arounds?

What would be a good venue for such wiki pages?  Any of these?

https://wiki.openwrt.org/
http://battlemesh.org/
https://wirelesspt.net/wiki/P%C3%A1gina_principal
https://libreplanet.org/wiki/Main_Page

On Wed, Feb 24, 2016 at 9:44 AM, Adam Longwill <adam.longwill at metamesh.org>
wrote:

> This thread has been very informative.
>
> But I want to get back to the original question that was asked: What works
> right now?
>
> What can be purchased right now that someone on here has purchased in the
> past month that still works?
>
> I ask because I have orders for mesh networking equipment to run on our
> PittMesh network that I need to fulfill and I have now lost confidence in
> my old standards-- TP-Link and Ubiquiti. I recently purchased a Picostation
> and a Nanostation M5 that will not flash their 14.07 Barrier Breaker images
> but will flash Nano Loco images (a workaround we have made work before) but
> at an EXCRUCIATINGLY slow pace. After abotu 2 hours the tftp transfer times
> out. If someone could shed light on the cause of this that would also be
> welcome.
>
> But what works now- right now?
>
> Adam
>
> On Wed, Feb 24, 2016 at 9:41 AM, Juliusz Chroboczek <
> jch at pps.univ-paris-diderot.fr> wrote:
>
>> > I thought the chips themselves could be built to only cryptographically
>> > accept approved firmware?
>>
>> Yes, they can and some chips are.  What we're expecting, however, is that
>> the vendors of cheap routers won't bother -- their goal is merely to get
>> FCC certification, so they'll implement the absolute minimum lockdown
>> features that they believe will get them FCC certification.
>>
>> The other hope is that ARM boards are getting cheaper at a vertiginous
>> pace, so with a little bit of luck (and a lot of hard work) the community
>> should be able to produce a usable design based on an off-the-shelf board
>> that is completely open and reasonably priced.  Right now, the main point
>> of contention is the lack of either wifi or meiniPCI on most boards --
>> wifi
>> chips need to be connected over USB, which sucks --, and the limitation to
>> just one Ethernet port.
>>
>> If you're interested in learning what mechanisms can be used to lock down
>> a fairly powerful SoC, have a read through chapter 32 of the Xilinx Zynq
>> manual:
>>
>>
>> http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
>>
>> Section 32.2.4 describes the "eFuse", which confirms what David has been
>> saying.
>>
>> Note that I'm not picking on Xilinx here (or ARM, for that matter) --
>> quite the opposite, Xilinx provide comprehensive hardware documentation
>> without registration, let alone an NDA.  Good luck finding similarly
>> detailed information about MIPS-based Broadcom chips.
>>
>> (Except that Xilinx are still not documenting the bitstream format.  Grr.)
>>
>> -- Juliusz
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>
>
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>


-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160224/16d099d1/attachment.htm>