Netonix Forums

So on logging in, I see the following in the web UI:



On ssh-ing in, I have this:

Code: Select all

admin@192.168.4.170's password:

BusyBox v1.19.4 (2017-03-07 13:42:37 EST) built-in shell (ash)
Enter 'help' for a list of built-in commands.


Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault


I can CTRL-C out of that and land at a normal shell.

This is a WS-12-250-AC running 1.4.8.

What's going on with this thing?

if you land at a normal shell, run through the tftp firmware recovery process.

Corrupted config, looks like.

Actually, I have a better idea of what's going on here. This is a new unit, so default user/pass. And while the UI states that the VLAN IPs are not routable and for "watchdog only", they are in fact very routable and I see a single ssh login yesterday that's not from an IP I recognize. So I think some bot was trying to turn this into part of a Mirai botnet or something and has screwed it up. I have my config saved off via the auto-tftp feature, and I have "config.json" in /www.

Just want to be clear, if I transfer the firmware to the switch and leave it in /tmp, this should allow a reflash of the firmware:

admin@265_Canal_Interior:/tmp# firmware_update /tmp/wispswitch-1.4.8.bin

As for the config, what do I need to ensure is in place so that on reboot I'm going to see the config loaded? I do have both config.json and the .ncfg file (which is a tarfile basically).

sporkman wrote:Just want to be clear, if I transfer the firmware to the switch and leave it in /tmp, this should allow a reflash of the firmware:

admin@265_Canal_Interior:/tmp# firmware_update /tmp/wispswitch-1.4.8.bin

Yes.

sporkman wrote:As for the config, what do I need to ensure is in place so that on reboot I'm going to see the config loaded? I do have both config.json and the .ncfg file (which is a tarfile basically).

You don't have to do anything, firmware_upgrade will take care of it.

I would suggest using v1.4.9 not v1.4.8

Eric Stern wrote:

sporkman wrote:Just want to be clear, if I transfer the firmware to the switch and leave it in /tmp, this should allow a reflash of the firmware:

admin@265_Canal_Interior:/tmp# firmware_update /tmp/wispswitch-1.4.8.bin

Yes.

sporkman wrote:As for the config, what do I need to ensure is in place so that on reboot I'm going to see the config loaded? I do have both config.json and the .ncfg file (which is a tarfile basically).

You don't have to do anything, firmware_upgrade will take care of it.

Firmware update seemed to run OK, but left switch in a state where it's powering connected devices (and power was not lost to the devices), but all ports appear down (I have a view into 3 ports from connected equipment, and no links on any).

Oh, and there's a UPS with a PDU on site. Oh, and the Netonix and the Cisco are plugged into passthrough/non-UPS ports, so I don't get to see what happens on a cold boot until tomorrow. Starting the hunt for a null-modem cable. IIRC, but we have tons of the blue cisco cables and those are "rollover" cables. I would think putting two of those back to back with an RJ45 coupler would get me the right cable with the right gender on each end.

edit: log of update process:

Code: Select all

admin@265_Canal_Interior:/tmp# firmware_upgrade wispswitch-1.4.8.bin
Unpacking firmware ...
cat: can't open '/tmp/config/model': No such file or directory
Running preflash script ...
Unlocking /dev/mtd8 ...
Writing from redboot_recovery_config to /dev/mtd8 ...
grep: /tmp/dmesg.boot: No such file or directory
Unlocking linux ...
Writing from kernel.img to linux ...
23%
46%
69%
93%
100%
Updating FIS entry linux
Unlocking FIS directory ...
Writing from fisdir to FIS directory ...
Unlocking Redundant FIS ...
Writing from redundant_fisdir to Redundant FIS ...
Unlocking rootfs ...
Writing from rootfs.img to rootfs ...
4%
8%
13%
17%
21%
26%
30%
34%
39%
43%
47%
52%
56%
60%
65%
69%
73%
78%
82%
86%
91%
95%
99%
100%
Unlocking /dev/mtd8 ...
Writing from redboot_config to /dev/mtd8 ...
Running postflash script ...
Done!
admin@265_Canal_Interior:/tmp# Fssh_packet_write_wait:


So power cycle didn't bring it back - power light is on but none of the ethernet ports are lit.

Should I assume I'm going to be doing this? viewtopic.php?f=17&t=1073&p=22902&hilit=recovery

Is that the most current version of the recovery instructions? What's the difference between "recovery.tgz" and a normal firmware download?

How do you get the switch into the mode described in that post or do I assume that it's going to be waiting there at the firmware prompt.

Or is this something else entirely?

What does only the power LED being lit indicate?

I see there are multiple "resets", once these folks make their way back from Microcenter in Brooklyn with a DB9-F - DB9F null cable I guess I'll know whether I need the full recovery or not.

http://forum.netonix.com/viewtopic.php? ... tory#p2398

edit: Also, if I'm in via console and that's my only access, is there a way to restore the config via the console (I have the .ncfg file).

Just a few questions my responses in bold:

sporkman wrote:So power cycle didn't bring it back - power light is on but none of the ethernet ports are lit.

Should I assume I'm going to be doing this? viewtopic.php?f=17&t=1073&p=22902&hilit=recovery#p22902
Assumption is the mother of all screwups..

Is that the most current version of the recovery instructions? What's the difference between "recovery.tgz" and a normal firmware download?
It is the most current. if you run into trouble I've done it a few times, can offer assistance. I recommend TeraTerm as it's free and allows xcopy transfers (will take some time, though)

How do you get the switch into the mode described in that post or do I assume that it's going to be waiting there at the firmware prompt.

Will probably depend on where you land up - control C (probably more than once) over the console port immediately following powerup will break to the redboot> prompt, as will a crash when loading firmware - if you miss, and kernel loads, and you end up at a kernel prompt, reboot <cr> and then mashing control C repeatedly should get you where you need to be.

Or is this something else entirely?
Tough to say, console output is how we diagnose many issues

What does only the power LED being lit indicate?
That 3.3v rail is up and running and powergood signals are asserted

I see there are multiple "resets", once these folks make their way back from Microcenter in Brooklyn with a DB9-F - DB9F null cable I guess I'll know whether I need the full recovery or not.

viewtopic.php?f=17&t=1073&p=22902&hilit=recovery#p22902

edit: Also, if I'm in via console and that's my only access, is there a way to restore the config via the console (I have the .ncfg file).

Will have to ask Eric, but once restored you'll have the GUI, your switch will answer at 192.168.1.20..

Quick one - based on your answer that I shouldn't assume the thing is totally bricked, go ahead with the two factory resets (hold reset until after the red LED cycling, if that doesn't bring it back, then the "long" reset - power-on with button held in, hold for 20 seconds)?

I need to have $work send me one of their minis for home here so I can play with this stuff in-person...

To recap, this is how I'm seeing what happened:

- some bot hit this thing on one of the VLAN IPs
- in trying to install itself/spread, it wiped out a good portion of /tmp
- the "switch" binary (which does all kinds of things, from acting as the "friendly" shell, to collecting stats as a daemon) freaks out and segfaults if the /tmp/config directory is empty and if some things it wants to see in /tmp are missing
- the "firmware_update" process reported success, so there should(??) be a valid image on this thing
- perhaps the firmware update process didn't generate a default config because the switch was in a state the script was not expecting?

Should have my TeamViewer laptop w/serial available soon.

Best reset in this case would be remove power, press reset button, apply power, wait 45 seconds, release button. Let it sit for a couple minutes, watch the boot crawl, have a coke.

Also worth noting 6-mini does not have a user accessible serial port - there's one there, but you have to void your warranty to get to it :)

Doubt you'll need teamviewer, you seem like a pretty intelligent sort.