OpenWrt Forum Archive

Topic: Backport AR2315 based Meraki Mini code base?

The content of this topic has been archived between 29 Apr 2018 and 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Kevin wrote:

i've been meaning to hack around with meraki's stage2 to load lzma kernels, as it's faster.

At least I got that bit to work :-)
http://wiki.openwrt.org/OpenWrtDocs/Har … 3589919b1f

Thanks for the clues - I will try changing serial port speed and renaming the rootfs partition.

the command line is hardcoded into the kernel code, search for it and you'll find it fairly easily

Without knowing what string to grep for, it's not so easy to find...

(I'd also like to avoid doing any changes to the source tree which mean I'm running something other than OpenWrt. I wonder why they don't honour the command line passed in from RedBoot?)

http://kwzs.be/~kevin/serial-console-log-openwrt.txt - example fis layout, config, and flashing procedure for unmodified openwrt (I have too much space allocated to the kernel, actually)

this is the default settings for the meraki I got, I believe they are all the same:
RedBoot> fconfig -n -l
boot_script: true
boot_script_data:
.. check_mac
.. load art_ap51.elf
.. go
.. load -h 192.168.84.9 -p 80 -m http /meraki/mini.1.img
.. exec
.. fis load stage2
.. exec

boot_script_timeout: 2
bootp: false
bootp_my_gateway_ip: 0.0.0.0
bootp_my_ip: 192.168.84.1
bootp_my_ip_mask: 255.255.255.0
bootp_server_ip: 192.168.84.9
console_baud_rate: 115200
gdb_port: 9000
info_console_force: false
net_debug: false


"Without knowing what string to grep for, it's not so easy to find..."
kevin@bart ~/src/linux-2.6.19.1/arch/mips/ar531x $ grep -n console *
prom.c:43://    strcpy(arcs_cmdline, "console=ttyS0,9600 rootfstype=squashfs,jffs2");

(Last edited by Kevin on 3 Jan 2007, 19:24)

Joyful - the Meraki Mini is now booting! The serial port speed was all it was. I was surprised not to see any garbage characters when the kernel was writing at 9600 and the terminal was set to 115200.

I see a few odd warnings:

Jan  1 00:00:16 (none) user.info : ifconfig: inet6: Unknown host
Jan  1 00:00:17 (none) user.info : ifconfig: inet6: Unknown host
...
Jan  1 00:00:23 (none) user.info kernel: wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3
Jan  1 00:00:24 (none) user.info : Interface doesn't accept private ioctl...
Jan  1 00:00:24 (none) user.info : mode (8BE2): Invalid argument

but basically it appears to be working. Yay! I've updated the documentation with what I've learned.

One problem is that out-of-the-box, the Meraki doesn't have FIS partition entries for its two main 3.25MB partitions. Rather, the locations of these two partitions are hardcoded into their stage2 bootloader and their kernel.

However, you can create these using RedBoot>, even without a serial cable if you telnet in at exactly the right time. I've documented this too. It might be simpler if there were a FIS partitioning tool that you could run from within Linux; this would give a way to upgrade a Meraki just by scp'ing a script over to it and running it.

With 8MB of flash, I do like the Meraki idea of having two firmware images concurrently loaded, to make it harder to brick when remotely upgrading. However at the moment this means further sub-partitioning of the unit (kernel 1, rootfs 1, kernel 2, rootfs 2). It would be nice if we could have a single firmware image containing kernel+squashfs root, and use the remainder of the partition for jffs2, as White Russian does on Broadcom devices.

Not sure how to implement that though. Perhaps modify the Meraki stage2 loader to read TRX files??

Finally - I do think it's worthwhile being able to create LZMA images which the stage2 loader can run, so perhaps this is worth integrating this capability into OpenWrt (it just has to prepend a length and modified CRC32)

Regards, Brian.

I do intend to add LZMA loader support. But rather than using meraki's stage2 one, I want to make our generic MIPS LZMA loader work on it...

Well I guess everything else I find now is just a Kamikaze-ism.

If I telnet into the unit then I start a process like "ping x.x.x.x", ctrl-C or ctrl-Z doesn't stop it. Even breaking the telnet session (^] close) and then telnetting in again, I find the process is still running.

I guess this is a symptom of this error, which I see when logging in:

/bin/ash: can't access tty; job control turned off

Also it looks like wpa_supplicant support is missing for 'sta' and 'wds' modes (based on comment in /lib/wifi/madwifi.sh). Also, is the 'wet' mode missing entirely? This is the one I use the most... it lets me associate with a standard access point, and have one or more wired ethernet devices use it.

Regards, Brian.

The 'wet' mode is just a hack and tends to not work very well in many situation. It involves a weird form of layer 2 nat. You should consider using wds + bridging instead...

I know about the L2 NAT and ARP trickerly; it also sets the [b]roadcast flag on DHCP requests. But there are many situations where I don't control the access point, only the client side.

Where are we with this now?  Does the OpenWRT LZMA kernel loader work yet?  Do we still need to prepend the 8-byte header to the kernel?  Can anyone recommend an easy way to flash the atheros-2.6 snapshot to the Meraki?  Is it possible to log in to the Meraki vendor firmware with SSH, SCP across a Kamikaze image, and flash it with MTD?

Any advances getting "wet" mode to work on Meraki Mini?
I keep trying since 3 weeks ...

tux wrote:

Any advances getting "wet" mode to work on Meraki Mini?
I keep trying since 3 weeks ...

The OpenWrt developers have said this will never happen. See above where nbd wrote:
"The 'wet' mode is just a hack and tends to not work very well in many situation. It involves a weird form of layer 2 nat. You should consider using wds + bridging instead..."

Unfortunately, this makes Kamikaze unusable for me :-( I use OpenWrt boxes as client bridges to standard (non-WDS) access points, and it works well.

If you need this, consider a commercial solution. The Compex WP54G with 2.0x firmware has an equivalent to WET mode which works very nicely. Works as a WPA/WPA2 client too.

OK I have to admit that I have not gone through all the source code.  The fact is at the moment I do not have the time.  I am buried at the moment and need help.

I am working on a White Paper for the Lt Governor of Illinois.  The focus of this is how communities can succeed in WIFI where the telcos have failed.  I have built hypothetical case studies for pilot programs using several different sizes of communities and hybrid non-profit/for profit business models.  In two of these possible case studies I have used the Meraki technology as a possibility.

However, there are three issues that bother me about Meraki.

1) I do not care that they are backed by Google, 98% of tech start-ups fail.  So there are a list of "What ifs" that bother me.  Meraki is as much a business service model as it is a hardware/software product.  Based upon conversations with both people in sales and engineering roles, the hardware design is dependent on the back office management of their proprietary radius server and Dashboard software.  And, so its hard to judge the total merits of the hardware, if ALL the bits (of source) are not included.  So, I would appreciate comments on usability in the event of implosion of the company.

2)  I am a little suspect of the use of a single radio in each node.  My experience in building WIFI has been using technology that allows for dual radios in each node.  One set of radios is then used to build a mesh and a second set of radios to create hot spots and user access.  Has anyone had experience actually deploying Meraki.

3) and this is the issue that REALLY bugs me.  OK so I am really biased and suspect all vendors who use Linux and FOSS for the creation of commercial products.  I am not totally happy with some of the answers I have gotten from people at Meraki about their compliance with the GPL.  I know these guys have a great reputation, part of the roof top project and all, so I want to believe them.  But believing people has gotten the Open Source community into a whole lot of grief over the years.  I have been getting the answer "we can not show you full source as some components use proprietary technology."

Its real simple, just because you sign an agreement with a company to use their proprietary stuff are you all of a sudden immune from observing the GPL.

So, I have a few questions for those of you who have really peeled back the layers of the posted Meraki source code.  The only way to tell is to look at the code and comments, which I do not have time to do.  I want to give Meraki a fair shake.

1- Does it appear that have observed both the OpenWRT license and the Linux license by fully releasing ALL source code?  Are there holes in their released code?

2- Please make a judgment if their developments were possible to develop without looking at the source code of Linux first? 

You can post here, but I would appreciate you to also email me at jeff@gerhardt.org

If you are being paid for your research, then IMNSHO you should probably do your own homework.

The Meraki source code is available for download, and you can easily compare it to the OpenWrt SVN repository. You can also buy a unit for a few $$ and analyse what binaries are there.

> The Meraki source code is available for download

yeah, but it sounds like it's not the same source code that's used to build the units they sell, since no one is able to boot a Meraki with source built from their tarball.  And that is a GPL violation.

It's probably not a particularly important violation, given the rest of the field.  It doesn't seem to be holding back openwrt's port, from what I've read here.  And my impression is that other manufacturers violate the GPL much more flagrantly.  But it is a violation: the GPL doesn't say anything about being friendly or supporting the community or showing off your competence or selling stuff for cheap.  It says only that anyone who buys a Meraki is entitled to (a) get a copy of the source *used to build the Meraki he or she bought*, not old source, no unstable development source, (b) that the source given must include all ``build scripts'', and (c) one can make more copies himself and give them to anyone without asking Meraki.  It sounds like we've more or less verified (a) and (b) have not happened.

> I know these guys have a great reputation, part of the roof top project and all, so I want to believe them.

Who says they have a great reputation?

Participating in a famously-blogged project, appearing to be smart and productive, producing good code, selling one of the easiest-to-port OpenWRT platforms for a low price, don't equate to having a good reputation for following the GPL.

Lots of brilliant, productive people like to say ``I have no time for politics'' and through this impatience become the craven accomplices of the worst sorts of exploitive investment banker scum.  Part of me finds these people reprehensible, and part of me sort of wishes to join them.

The discussion might have continued from here.