Re: B593s-22 Multicast Upgrade Tool.exe
George
Typical firmware upgrade for any entwork applicance is done via web-interface. The obvious catch in that is, that you need to authenticate, move to a suitable page and upload a file to accomplish that. In rare cases, hardware has an "upgrade mode", which allows you to inject a new firmare to the device without any proper authentication. For hacking, this opens a completely new avenue. If one could modify a firmware (and sign it), it would be possible to unlock locked devices, unlock features, or introduce new functionality.
Getting the box to the upgrade mode sounds easy:
turn power off from the device, keep WPS and Wi-Fi buttons pressed, kick on the power and at a suitable time release the Wi-Fi button. Then normal boot process is stopped and the box will wait for a firmware file to be delivered to it. In reality, it's bit tricky. Possible to do, but bit tricky.
Make sure you'll allow outgoing traffic to multicast address 224.0.0.119. For any layman, that looks like just another IP-address, but it isn't one. It is in multicast address range and will be handled differently by TCP/IP-stack.
As all you TCP/IP savvy people know, multicast works no matter what your computer's IP-address is. That being said, I still recommend you change the computer's IP-address to network 192.168.8/24 which is used by the E5186. It is done from control panel (the screen shots are from Windows 10):
Serial console logs indicate, that you'll have 0,850 seconds from power-on to words "not in router upgrade mode" to be logged. So, I strongly suggest, that you'll keeps WPS and Wi-Fi buttons when you flip the power switch.
Your window-of-opportunity to release the Wi-Fi -button is between 0,850 and 1,890 seconds from power-on. If you release earlier, it's same as not pressing them at all. If you'll press them longer, you'll get the phrase "not in router upgrade mode" to the log, meaning that you failed.
If your blue LED keeps lit, like this:
Then everything is still ok. I cannot reproduce that every time, but I successfully updated firmwares with that status also. The idea is, that the blue LED keeps lit.
When your upgrade is completed and you're ready to power off the router, LEDs will look like this:
The Wi-Fi LED will go on and off slowly. It will keep doing that forever or until you power of the unit, whichever comes first.
When you a have few extra minutes, could you build a RaspberryPi3 version of the current ROOter tester? My RaspberryPi2 is working exceptionally well as my everyday router, but I'm getting ready to deploy an outdoor "closely-coupled" version using an RPi3.
Strangely, I am unable to flash a TP-Link WR1043ND v4, which actually runs on GO 2017-10-10.
Firmware file is lede-wr1043nd-v4-GO2017-12-15.bin but I get the error message:
"The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform."
Am I missing something?
Align the center of the 2-1/2" holes for the IP32 air vents with the center of the closure buckles, and be sure they're centered left-to-right on the door. There's just enough clearance for the rings you'll be screwing on from the inside if you've measured and marked carefully.
Mark the 1" hole for the Amphenol waterproof Ethernet connector 44/64" down from the sealing lip and centered. Mark the two 5/8" holes for the panel mount "N" antenna connectors 44/64" down as well, and centered in the remaining spaces on the sides of the Amphenol connector.
Mount the RaspberryPi3 to the Bud Internal Board on the fourth row down from the top by creating an additional hole just to the right of the last hole in the fourth row. The holes on the left side of the RPi will use standard holes present in the board. The mounting board hole for the lower right RPi mounting hole will also be a specially drilled hole just to the right of the last hole in the row it lines up with. The two new holes on the right side are necessary to create the room needed for the right angle USB RPi power cord. The RPi should be mounted with 2.5mm x 25mm stand-offs from the parts kit. Use nuts from the kit on the back side.
The USB modem enclosure (with the modem already installed inside it!) should be mounted as high as possible on the internal board. It should butt up against the 25mm stand-offs and be centered left-to-right under the RPi. Line it up with existing internal board holes, but be prepared to slightly drill the bottom one, as they don't line-up perfectly. I needed to use 2.5mm x 8mm fasteners that I had from a previous computer build with more nuts from the stand-off kit.
With the USB modem enclosure shifted to the right just like the RPi, this creates room for the PoE splitter to be mounted on its side just to the left of the modem and lined-up with the bottom of the modem enclosure. 3M VHB tape or other strong double stick material works well.
Now's a good time to route the USB cable from the modem enclosure to one of the RPi USB ports. Also, connect the right angle USB to DC barrel connector adapter. The internal board can now be screwed into its threaded inserts in the box. The Amphenol Ethernet connector should be removed at this point, as it blocks the bottom screw on the internal board. Re-install Amphenol connector when the board is screwed down.
Route the 18" Ethernet cable from the Amphenol connector to the PoE Splitter. Connect the captive Ethernet cable from the PoE splitter to the RPi Ethernet. Connect the PoE splitter power cable to the DC adapter you already connected to the RPi. Connect the RP-SMA connectors from the N panel mount connectors to the USB modem enclosure.
All you need now is an SD card flashed with the latest RPi3 version of ROOter, a SIM card from your cellular data provider and a 24V PoE power inserter or 24V PoE splitter. And, of course, don't forget to connect the antennas!
I'm using each one of these parts in other deployed projects, so I'm confident of their functionality. This is a new build though, and I'm still working on the rooftop MIMO antenna mount. I likely have the completed setup deployed and in everyday use after the first of the year.
Nice and neat. Are you using the pi3 as the dhcp server as well and just using an AP on the other end? I run a similar setup but I would rather just have the pi3 act as a dumb AP with the mc7455 and pass the ip to my router inside the house. So far the only thing I know to do is put my inside router in the dmz of the rooter router.
It's a huge issue for me which is why I only use it to bring the internet into my home where I use my nighthawk r7800. I just wish I could get the rooter router to pass the public ip instead of doing the dmz.
At the moment, I'm still using a Cradlepoint as my primary inside (DHCP) router, with a RaspberryPi2 running ROOter and an MC7455 modem strictly as a WAN device. The Cradlepoint has gigabit Ethernet which is must for me too. I use a Ubiquiti UniFi AC Lite for all WiFi.
The new build that I've been documenting, is aimed at getting the modem "closely-coupled" with MIMO yagi antennas. I'd like to use that ROOter router ultimately as my primary DHCP server, though it's not mandatory. I use another RPi running Pi-hole as my DNS server and Ubiquiti UniFi controller.
Which brings me to my point. Back in the early days of gigabit Ethernet, before I had a router capable of it, I added an unmanaged gigabit switch. This was some years ago, but IIRC this gave me gigabit Ethernet for all devices connected to that switch, and for file transfers between devices on that switch. Extrapolating to now, an AP with gigabit WiFi should enjoy that same performance as long as it's on that switch, or cascaded from that switch. In other words, if your entire network is connected one way or another to gigabit switches it shouldn't matter if your DHCP router is merely "Fast" Ethernet.
As far as having a gigabit switch with all devices hooked up to it, I may be wrong but I believe each packet still needs to go through the gateway which in most cases is the router unless you have a switch capable of layer 2/3 routing in which case the clients are given the gateway IP defined on that managed switch as it's gateway.
It'll be interesting to see what other feedback we get on this! It's been long enough since I had that type of setup I could easily be wrong. In my case, another layer of NAT really doesn't bother me, since none of the cellular providers I use give me a public IP anyway.
The RPi is a dynamite way to manage an MC7455 (Cat 6 w/CA), which I use (and have tested) with Verizon, AT&T and Sprint just by changing the SIM and the APN in ROOter. I'm currently getting 60-75Mbps on the download from Sprint, just using a window mount Netgear MIMO antenna. My upload speeds need work, which is part of the motivation for the rooftop MIMO yagi setup. The ROOter OpenVPN client capability is another huge plus for me.
I then issued the AT command AT+CFUN=0 to put the EM7430 into low power mode. Connection Monitoring detected that the connection was lost and successfully turned LPM off and remade the connection.
Agreed, the DHCP server/router should only be concerned with allocating IP addresses in this respect, and not meddle with intra network communication. If the 100Mb/s is at the edge of your network (as the gateway to the Internet) then that limit will only come into play for devices plugged into it.
Not the latest, but the "preview" to the latest (8meg.zip) which is basically the same I built with 17.01.4. I do have it doing the modem reconnect and that is what I have been using in the past weeks. I get 2-3 disconnects a day and ROOter is able to reconnect in about 30 second duration.
b1e95dc632