What's new

REQUESTING HELP PLEASE: Use of uQMI Protocol on ASUSWRT-MERLIN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

You can mount the filesystem on your pc and compare the sizes of the firmware files between your openwrt sdcard and your noobs sdcard. if they aren't the same you can copy the firmware files from the noobs card to the openwrt card

The VC4 firmware is the same between Pi2 (brcm2709) and Pi3 (brcm2710) in Raspbian (actually all the Pi's are the same there - and pi2 and pi3 use the same kernel7.img) - it's the device tree files that are unique to each board... and unique to Raspbian and a few partners that use the Raspberry Pi Foundation kernel and bootloader...

In any event, OpenWRT is a bit different there, as they do tailor to the board, so the build has to be for that board...
 
FWIW - a number of folks know that I'm working on an alternative Linux distro outside of OpenWRT, and our own board based on Marvell - while originally targeted as an open router board, we've since pivoted more into the IoT hub play.

OpenWRT is still is our baseline for performance, and at the moment, Pi2/3 might be a target for a production release on our distro - and some development is being done on Pi outside of board specific items which allows shorter time, and perhaps wider base...
 
Here - this is built off the trunk, so it might be a bit sketchy - haven't had a chance to test it myself, as my spare card ended up being bad...

Burn that to a card and give it a try to see if it boots... opkg should be working, so if one needs to grab something there...

Sorry for a late response. Busy day AFK (away from keyboard, for the millennials that don't understand that;)) and didn't check in the forms until recently. Flashing over this badboy now... And will tinker with this as late as required. Will report back on findings. When there is a will...:D
 
FWIW - a number of folks know that I'm working on an alternative Linux distro outside of OpenWRT, and our own board based on Marvell - while originally targeted as an open router board, we've since pivoted more into the IoT hub play.

OpenWRT is still is our baseline for performance, and at the moment, Pi2/3 might be a target for a production release on our distro - and some development is being done on Pi outside of board specific items which allows shorter time, and perhaps wider base...

Definitely interested in trying that out too, in any form of hardware. Will definitely follow. Do you have a kickstarter, or the like, by chance?
 
Downloaded & verified SHA256, then flashed & verified Pi3 image as SFX noted above. (Thank you for generating that build image, by the way SFX!:))

Pi3 was booted up headless, and seemed to initialize well. Status lights on Ethernet seemed to indicate activity, and that little green evenly-pulsing status light (which I assumes means ready and awaiting input) was met with my enthusiasm. This was detected on Win10 as an "Unidentified Network" on 192.168.1.1 with automatic/DHCP enabled on desktop IPV4 settings of ethernet adapter.

No access by CMD telnet for the initial "passwd" set from hardwired Pi3 to desktop. Tried hardwired Pi3 directly to router, and changing router IP to 192.168.1.2 (DHCP pool still set above to make sure to exclude 192.168.1.1.) No dice there either. Couldn't ping in either configuration at this point.

Hooked up Pi to its own display/keyboard setup, and no perceived issues with recognizing hardware or initiating services as the boot log scrolled, with the exception of IPV6 (which was kind of expected, because not in use.)

On separate display/keyboard input: Set "passwd" to an acceptable password directly through Pi3 CLI. Attempts to ping the Pi3 were now succeeding!

Next; tried to SSH (WinSCP) from both direct ethernet hardwired to desktop and while connected to router as both root@ and admin@, with the password that I had manually set with "passwd" (and every other generic default password I could think of.) Connection process was initiated, handshake seemed successful, but authorization failed with every password.

As a final access attempt; I tried web access to LUCI http interface by 192.168.1.1, 192.168.1.1:8080, 192.168.1.1:8081 with Ethernet hardwired directly to PC. No dice, so I assumed LUCI wasn't home yet...

Tried running OPKG while running off of separate display/keyboard input. "Failed to connect" followed by "Invalid signature" errors on every package.

Rinse and repeat... and the Pi3 inaudibly laughed maniacally...:mad:


Maybe I missed something critical somewhere tonight. I got tired, frustrated, and sloppy near the end of the second attempt. I will try another rinse/repeat tomorrow when I am more clearheaded...
 
Maybe I missed something critical somewhere tonight. I got tired, frustrated, and sloppy near the end of the second attempt. I will try another rinse/repeat tomorrow when I am more clearheaded...

I know what's up there... will post how to get around this later today...

good news though, it's booting the PI3, and that's the right start...

ok - here's another spin - this time with some LUCI action...

https://dl.dropboxusercontent.com/u/9266262/openwrt_pi3_luci_sfx.zip

--------------

Some tips... sorry, as I sometimes assume more than I should...

The proper way to work is using a UART-TTY cable, and even there, the Pi3 i a bit tricky due to UART0 being assigned to BT, so we have to using the Mini-UART, and there... it's less than reliable, but setting core speed to 250Mhz helps, but that's beside the point, as we have below...

The cheater method on any Pi, which is quite easy, is to just grab an HDMI cable and USB keyboard and hook things up to an available display as the console is also available there on the Pi

Note - don't connect LAN just yet..

When it boots - hit return a couple of times, and you should get to a prompt - again, having keyboard and some kind of HDMI monitor installed.

Set a password for the root account, and reboot

Once back up - edit the /etc/config/network file, and change the LAN addr to something outside of the DHCP scope and not used by anything else...

Code:
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd95:29b7:8336::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.1.3'
        option netmask '255.255.255.0'
        option ip6assign '60'

Then you can connect the LAN, and get into LUCI via browser - http://192.168.1.3 -- it'll complain about the cert, as this is self-signed as part of the build process...

Once there - you'll have the WebGUI, and this should get a bit further...

so if everything works, you should eventually get here...

pi3_openwrt_luci.png


boot log stuff here...

http://pastebin.com/ngAD7V2y
 
Last edited:
Pi3 was booted up headless, and seemed to initialize well. Status lights on Ethernet seemed to indicate activity, and that little green evenly-pulsing status light (which I assumes means ready and awaiting input) was met with my enthusiasm. This was detected on Win10 as an "Unidentified Network" on 192.168.1.1 with automatic/DHCP enabled on desktop IPV4 settings of ethernet adapter.

I should have warned you - don't connect to the LAN at that point, as OpenWRT defaults for some odd reason to that IP and it can cause some trouble...

dummy on me...

No access by CMD telnet for the initial "passwd" set from hardwired Pi3 to desktop. Tried hardwired Pi3 directly to router, and changing router IP to 192.168.1.2 (DHCP pool still set above to make sure to exclude 192.168.1.1.) No dice there either. Couldn't ping in either configuration at this point.

Again - apologies - see note above about the "cheater method" if one doesn't have a console cable...

On separate display/keyboard input: Set "passwd" to an acceptable password directly through Pi3 CLI. Attempts to ping the Pi3 were now succeeding!

part one done - getting passwd set, and that will let things proceed... but see note about setting the LAN IP in /etc/config/network

OpenWRT really wants to be a router, not a client :D

Next; tried to SSH (WinSCP) from both direct ethernet hardwired to desktop and while connected to router as both root@ and admin@, with the password that I had manually set with "passwd" (and every other generic default password I could think of.) Connection process was initiated, handshake seemed successful, but authorization failed with every password.

Again, my bad, as perhaps the ssh session was trying to connect not to the Pi, but to something else, as the default again is 192.168.1.1, which is typically the router...

As a final access attempt; I tried web access to LUCI http interface by 192.168.1.1, 192.168.1.1:8080, 192.168.1.1:8081 with Ethernet hardwired directly to PC. No dice, so I assumed LUCI wasn't home yet...

LUCI didn't work, as it wasn't built in to the previous image, now it is...

Tried running OPKG while running off of separate display/keyboard input. "Failed to connect" followed by "Invalid signature" errors on every package.

Rinse and repeat... and the Pi3 inaudibly laughed maniacally...:mad:


opkg is a bit broke, one should probably update the /etc/opkg.conf file with the right URL, the default doesn't have that...

Also, the default doesn't have DNS assigned in any case, so hitting the repo's would fail, hence the bad sig feedback...

Give the new image a try... I appreciate your patience...
 
Last edited:
Give the new image a try... I appreciate your patience...

No way! I appreciate YOUR patience! This is how I learn new things. I bang my head in to a table in frustration, someone points out obvious things, and I commit these things to memory to use in future instances. There is always a learning curve from one thing to the next!

Downloading the image now. Flashing, and reading through your steps IN DETAIL! Will report back...starting coffee pot shortly...
 
Definitely interested in trying that out too, in any form of hardware. Will definitely follow. Do you have a kickstarter, or the like, by chance?

Not at the moment - scratching a collective itch, but at the same time, it's a deep and entrenched market for Router/AP's...

Going in the IoT space - there's a few niches that can be found that can go deep and do good things - not ready or perhaps even interested in a kickstarter at the moment - we're a bunch of old school guys (ok, old school is relative), but we're looking at some verticals - and then kick the source, at least GPL, horizontal... and that might be of value to some..

What'e interesting is that while we've been working with A53, ARMv7 runs a bit better in most cases... mostly because of the heavy optimization there with the Android smartphone camp... bigger cores might be a different story perhaps on certain ops...
 
I am up and running on the pi. I think i figured out why the passwords weren't being accepted by SSH client last night. I used thd NUMPAD without numlock on when i used passwd... but didnt see my typed input because of masking. I did it again, and got stuck for another hour. urrrg!

Now, to adjust settings and see if I can't get this seirra module running.
 
I am up and running on the pi. I think i figured out why the passwords weren't being accepted by SSH client last night. I used thd NUMPAD without numlock on when i used passwd... but didnt see my typed input because of masking. I did it again, and got stuck for another hour. urrrg!

Now, to adjust settings and see if I can't get this seirra module running.

Sounds good - hopefully the new image I rolled helped out...
 
Sounds good - hopefully the new image I rolled helped out...

YES, thank you! I am continuing to figure things out here. I've played with ASUSWRT and DD-WRT enough to be efficient...but I am stumbling around with OpenWRT. I know what most options in here can change, but it seems a bit foreign in the way access is organized. I think I need a few days to fiddle around, but not til 4AM anymore though.

First order of business is for me to figure out how to get OpenWRT to recognize the LAN port as both the WAN and LAN (for the time being), that way I can apply package updates over the net while still accessing it locally via the web interface. If that isnt possible, a simple usb to ethernet adapter will be on its way from amazon shortly.

Thank you so much for all of your help here with your advice, and building those flashable images for myself and others to utilize. I will keep you in the loop on what I find in the next few days. Promise.
 
You can mount the filesystem on your pc and compare the sizes of the firmware files between your openwrt sdcard and your noobs sdcard. if they aren't the same you can copy the firmware files from the noobs card to the openwrt card

OpenWRT is a bit different, but it's similar to Raspbian and NOOBS for that matter... bit also note that is much more platform specific - note the .dtb, but it's more than that with the the rest of the build...

Screen Shot 2016-11-27 at 12.45.12 AM.png
 
to get opkg working - it needs to be pointed at the right repo...

edit /etc/opkg.conf

add this line

http://downloads.openwrt.org/snapshots/trunk/brcm2708/generic/packages/base

and then...

opkg update

Hmm... this is still giving me an "Invalid signature" fail. Even after providing the http, and "option check_signature" between 0/1.

Since the OpenWRT Pi3 is built off the trunk - here's the latest image...

https://dl.dropboxusercontent.com/u/9266262/openwrt_pi3/openwrt_pi3_luci_sfx_112816.zip

I'll give that one a shot... Now that I'm figuring out how to make my way around the CLI and OpenWRT LuCI. ;)
 

Even though this is copied directly to OPKG.CONF, it still goes to the wrong http?...weird.

OPKG.CONF
Code:
src/gz base http://downloads.openwrt.org/snapshots/trunk/brcm2708/generic/packages/base
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay


Console output:
Code:
/etc$ opkg update
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/generic/packages/base/Packages.gz.
Collected errors:
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/base/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/kernel/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/telephony/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/packages/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/routing/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/luci/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/management/Packages.gz, wget returned 8.
Updated list of available packages in /var/opkg-lists/base.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/base/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/kernel/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/telephony/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/packages/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/routing/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/luci/Packages.gz.
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm2708/bcm2710/packages/management/Packages.gz.
 
Last edited:
Found out why it was redirecting me. Each package folder needed to be individually referenced in OPKG.CONF, and not just the "base" folder.

Got package list updated, and... the packages needed to run QMI modem are not available in this build. Damn... Going to just have to pony up, and learn how to compile drivers for Raspbian. haha.
 
So, thankfully I set this older laptop up earlier in the year to dual boot in to OpenSUSE Leap 4.2.1, but only briefly used it...hoping to find GobiNet and GobiSerial in the repository or figure out compiling it for OpenSUSE (or cross-compile for the Pi3.) If I can get it working from this laptop, but not the Pi3, it still isn't an ideal solution...but I could do a stand-alone build on a cheaper mITX board built with some less-costly components to act as the main gateway...
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top