This is partially a follow up to a previous problem I've been having with a Mikrotik SXT SQ Lite5.
Following the AREDN documentation, and recommendations on OpenWRT, I was able to successfully downgrade the RouterOS version to the recommended version 6.45.8. I can log into the node via the Mikrotik suite of tools and access the node's settings. I can also change the boot device settings to try-ethernet-once-then-nand in preparation for using Tiny PXEserver. Protected Routerboot is not enabled and the boot protocol is bootp.
In my configuration, I have a Netgear FS108 dumb switch between my laptop (with Tiny PXEserver) and the Mikrotik node (using the supplied PoE adapter, of course....). I set my laptop to a static IP address of 192.168.1.10 (net mask 255.255.255.0). When I start Tiny PXEserver, the static IP address is recognized properly and everything looks as it should per the AREDN documentation.
I renamed the appropriate AREDN 3.24.6.0 kernel file to rb.elf as required.
I navigated to the rb.elf location, configured Tiny PXEserver as shown in the documentation and enabled the Online switch.
I powered up the node in the Etherboot configuration by holding down the reset switch and waiting for the communication sequence to begin. The Tiny PXEserver low window indicates:
DHCP'd request received and shows the MAC address for the node
DHCP'd BOOTP REQUEST
DHCP'd ACK sent and shows the IP pool starting address.
Regardless of how long I hold down the reset button after seeing the above three DHCP'd messages, I never get the TFTPd: DoReadFile: rb.elf message in the log window.
Watching the LEDs on the dumb switch, I notice that both sets of LEDs blink very rapidly, and in synchronization, after the DHCP'd ACK message shows up. Regardless of how long I wait, nothing changes on either the LED blink pattern or the Tiny PXEserver log window. The only way to stop the blink pattern is to cycle power on the Mikrotik node.
I've successfully used Tiny PXEserver with Ubiquiti nodes in the past and received the desired TFTP'd message to start the installation process on the node. There just seems to be something strange going on with the Mikrotik nodes.
What am I missing here?
Following the AREDN documentation, and recommendations on OpenWRT, I was able to successfully downgrade the RouterOS version to the recommended version 6.45.8. I can log into the node via the Mikrotik suite of tools and access the node's settings. I can also change the boot device settings to try-ethernet-once-then-nand in preparation for using Tiny PXEserver. Protected Routerboot is not enabled and the boot protocol is bootp.
In my configuration, I have a Netgear FS108 dumb switch between my laptop (with Tiny PXEserver) and the Mikrotik node (using the supplied PoE adapter, of course....). I set my laptop to a static IP address of 192.168.1.10 (net mask 255.255.255.0). When I start Tiny PXEserver, the static IP address is recognized properly and everything looks as it should per the AREDN documentation.
I renamed the appropriate AREDN 3.24.6.0 kernel file to rb.elf as required.
I navigated to the rb.elf location, configured Tiny PXEserver as shown in the documentation and enabled the Online switch.
I powered up the node in the Etherboot configuration by holding down the reset switch and waiting for the communication sequence to begin. The Tiny PXEserver low window indicates:
DHCP'd request received and shows the MAC address for the node
DHCP'd BOOTP REQUEST
DHCP'd ACK sent and shows the IP pool starting address.
Regardless of how long I hold down the reset button after seeing the above three DHCP'd messages, I never get the TFTPd: DoReadFile: rb.elf message in the log window.
Watching the LEDs on the dumb switch, I notice that both sets of LEDs blink very rapidly, and in synchronization, after the DHCP'd ACK message shows up. Regardless of how long I wait, nothing changes on either the LED blink pattern or the Tiny PXEserver log window. The only way to stop the blink pattern is to cycle power on the Mikrotik node.
I've successfully used Tiny PXEserver with Ubiquiti nodes in the past and received the desired TFTP'd message to start the installation process on the node. There just seems to be something strange going on with the Mikrotik nodes.
What am I missing here?
Denis
On the Mikrotik, once you see the DHCP messages, release the button.
Sometimes flashing with an older version of the kernel (try 3.22.12.0 for example) will get you to the "doread" then you can continue by using the sysupgrade you want. I don't know why but sometimes an older file is needed.
Ed
I've tried performing the installation with and without a dumb switch and ended up with the same result. Let me try an older version of the kernel and see if it can be recognized.
The log shows that the mANTbox sends a request and gets an answer. But the answer seems not to be what was expected.
Wireshark shows that the reply packet seems to contain the right answers (server address, file name, etc). But the mANTbox does not start to download and just sends the next request.
Recently, I had a similar behavior with a hap lite (which I sent back under warranty).
Hope this helps.
Orv W6BI
Because I currently use the AP for a test with the original SW I was not able to flash AREDN back. But because both, TFTP and Netinstall showed the same problem, I assume that it will work when I flash AREDN back (and I will use your tip)
A colleague (a longtime Mikrotik consultant) told me that Netinstall does not work with all PC drivers and sometimes has issues with Wireshark drivers.
Can you elaborate on this? Are you referring to the settings in Tiny PXEServer? Does this refer to changing the settings on the IP Pool start/size line?
I was able to get one of the units running by shutting off the firewall on my laptop computer. The recent version of AVG Free is insidious; it gets into EVERYTHING on my Windows 10 system. Once the firewall issue was resolved, the install went according to the AREDN documentation.
The second unit, however, is still giving me fits. I can successfully get to the step where the kernel image is loaded into RAM, awaiting the final installation step of uploading the sysupgrade file. After the sysupgrade file installs, however, the node never reboots automatically afterwards.
I next tried using the alternate upload method with WinSCP and PuTTY. Again, I could successfully load the kernel image into RAM and then issue the command line (shown in the documentation) for the final sysupgrade file.
PuTTY displays the following messages:
Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed
An error message box then pops up:
PuTTY Fatal Error
Remote side unexpectedly closed network connection
Does anyone know what's going on here?