Flashing SAS Controller failed

[Spearfoot]

FTFY

Yikes! Hadn't seen that article! Seems like TV users were running it 24x7 and with poor password choices. Nooooooo!!!!!!!!

Still, I think @Harrison will be okay, provided s/he uses good passwords, and only runs TV for the few short hours it will take iXsystems to debug his system. I set it up here for a short time a few weeks ago so that Josh Paetzel could debug an AFP service problem.

 

[Mlovelace]

Yikes! Hadn't seen that article! Seems like TV users were running it 24x7 and with poor password choices. Nooooooo!!!!!!!!

Still, I think @Harrison will be okay, provided s/he uses good passwords, and only runs TV for the few short hours it will take iXsystems to debug his system. I set it up here for a short time a few weeks ago so that Josh Paetzel could debug an AFP service problem.

GoToMeeting or LogMeIn are the only options I'd go with for remote access support. A company like iX offering enterprise support should have access to one or both of those options.

 

[jgreco]

Yikes! Hadn't seen that article! Seems like TV users were running it 24x7 and with poor password choices. Nooooooo!!!!!!!!

Still, I think @Harrison will be okay, provided s/he uses good passwords, and only runs TV for the few short hours it will take iXsystems to debug his system. I set it up here for a short time a few weeks ago so that Josh Paetzel could debug an AFP service problem.

It isn't actually clear what the TeamViewer issue is. For obvious reasons, TV wants to downplay the issue, but until some neutral and qualified third party can analyze what's actually happened, I'd be very careful.

 

[Spearfoot]

GoToMeeting or LogMeIn are the only options I'd go with for remote access support. A company like iX offering enterprise support should have access to one or both of those options.

Perhaps they do, but I wouldn't know 'cause I'm a cheapskate running their free software on my DIY systems and haven't ever had dealings with their enterprise support.

I have had dealings with one of their developers, Josh Paetzel, who requested teamviewer access when I assisted him w/ this bug:

https://bugs.freenas.org/issues/12967

In any case, @Harrison's system is dead in the water and the old saying "Desperate times call for desperate measures" may apply. If he's anything like me, he will wait to install any remote access software until just before using it; watch it like a hawk while it's in use; and delete it immediately afterwards.

We don't know that iXsystems will need remote access to diagnose his system; I suggested installing teamviewer ahead of his appointment with the idea that it might save some time, and because I knew from personal experience that at least one iXsystem employee uses it.

Hopefully he will report back with good news after his session with iXsystems.

 

[Harrison]

Hi Guys, iX's Josh Sirrine took all of 3 mins. to diagnose the bad news that the update script I'd used "SMC2308T.NSH" was a, the wrong firmware and b, issued a "sas2flash.efi -o -e 7" which wiped the chip so yes - it's dead.

iX are helping me by replaceing the MB - not sure how this is handled yet.

The "good news", is that I was replicating to an older Supermicro, running FreeNAS-9.2.1.9 (cannot update this since the hardware doesn't support the 9.3 boot)... so in a nut shell I've made this backup server our live server.
I had to recreate the data set/cifs sharing scheme and copy the files accros as it turns out the replicated data sets are read-only & chmod can't change that.
--
On the TV thing, I wasn't aware of that 'hack' but since I use it very rearly - its installed but not starting automatically I hope we're OK.

 

[Spearfoot]

Hi Guys, iX's Josh Sirrine took all of 3 mins. to diagnose the bad news that the update script I'd used "SMC2308T.NSH" was a, the wrong firmware and b, issued a "sas2flash.efi -o -e 7" which wiped the chip so yes - it's dead.

iX are helping me by replaceing the MB - not sure how this is handled yet.

The "good news", is that I was replicating to an older Supermicro, running FreeNAS-9.2.1.9 (cannot update this since the hardware doesn't support the 9.3 boot)... so in a nut shell I've made this backup server our live server.
I had to recreate the data set/cifs sharing scheme and copy the files accros as it turns out the replicated data sets are read-only & chmod can't change that.
--
On the TV thing, I wasn't aware of that 'hack' but since I use it very rearly - its installed but not starting automatically I hope we're OK.

Thanks for letting us know, and sorry that you're having so much trouble. Hopefully the motherboard swap will go smoothly.

So... Supermicro provided a bad script? That's scary.

 

[Harrison]

I cant say Supermicro provided a bad script... rather that my MB seems a little different with an on-board SAS and since I couldn't see anything to the contary I obviously made the wrong choice to go with the Supermicro P20 firmware zip file (PH20-IT.zip) at this link:

ftp://ftp.supermicro.com/driver/SAS/LSI/2308/Firmware/IT/

If anyone else has my Supermicro motherboard "X9DR7-LN4F" Don't use this firmware (still don't know where to get the correct firmware though - sorry)

 

[Spearfoot]

I cant say Supermicro provided a bad script... rather that my MB seems a little different with an on-board SAS and since I couldn't see anything to the contary I obviously made the wrong choice to go with the Supermicro P20 firmware zip file (PH20-IT.zip) at this link:

ftp://ftp.supermicro.com/driver/SAS/LSI/2308/Firmware/IT/

If anyone else has my Supermicro motherboard "X9DR7-LN4F" Don't use this firmware (still don't know where to get the correct firmware though - sorry)

But your X9DR7-LN4F uses the same LSI 2308 chip that my X10SL7-F uses, according to Supermicro's website. It just doesn't make sense that it wouldn't work...

 

[Harrison]

That's what I thought. I'd read and re-read that original thread on updating the firmware even before iX refered me to it. But obviously I made the wrong choice, we know "where" I went wrong, just not why.
* you can't beleave the stress this caused me. I'm fortunate we're a very small company and my colleagues bear with me when things get cocked-up.

 

[maglin]

Wow I'm in amazment that TeamViewer is saying it experienced a DDOS attack. I thought most all administrators have put in place rules and timers to stop DDOS attacks. I'm glad I never used TV.

 

[Mirfster]

Glad, I use WebEx. :)

 

[jgreco]

Wow I'm in amazment that TeamViewer is saying it experienced a DDOS attack. I thought most all administrators have put in place rules and timers to stop DDOS attacks. I'm glad I never used TV.

There aren't "rules" or "timers" that can "stop DDOS attacks." If I decide to target you with 100 gigabits of junk traffic, your site is kaput. In fact it takes significantly less traffic to do a carefully targeted take-down in many cases.

However, it appears that something *else* may have happened to TV that may have compromised ... something ... that is allowing bad guys to identify its clients and access their systems. This probably goes beyond simple "bad passwords" but who knows.

If we could standardize encryption for VNC, then VNC and reverse VNC would be the obvious choices for cutting out the middleman. Middlemen serve as juicy targets for being compromised, because compromising them results in a bonanza of access, whereas searching for and breaking something like VNC on each individual system is tedious and difficult, especially if it is properly protected.

 

[Spearfoot]

There aren't "rules" or "timers" that can "stop DDOS attacks." If I decide to target you with 100 gigabits of junk traffic, your site is kaput. In fact it takes significantly less traffic to do a carefully targeted take-down in many cases.

However, it appears that something *else* may have happened to TV that may have compromised ... something ... that is allowing bad guys to identify its clients and access their systems. This probably goes beyond simple "bad passwords" but who knows.

If we could standardize encryption for VNC, then VNC and reverse VNC would be the obvious choices for cutting out the middleman. Middlemen serve as juicy targets for being compromised, because compromising them results in a bonanza of access, whereas searching for and breaking something like VNC on each individual system is tedious and difficult, especially if it is properly protected.

The article you posted -- or one of the comments, I don't remember which -- suggested that someone may have changed teamviewers nameservers, and thus was able to re-route all of their traffic. Yikes!

 

[jgreco]

The article you posted -- or one of the comments, I don't remember which -- suggested that someone may have changed teamviewers nameservers, and thus was able to re-route all of their traffic. Yikes!

If that happened, which is possible based on the last change date of 6/2, that'd be a bad thing. Poorly operated DNS, not flagged to prevent deletes, transfers, or updates. Isn't particularly confidence-inspiring that they have any sense of security about their infrastructure.

 

[Spearfoot]

We should start a separate "Teamviewer Bashing" thread...

 

[Harrison]

I'd just like to close this thrad on a happy note... I received a replacement MB from iX and bingo everything is back up and running, so now my backup freeNAS - which we had switched to as our 'live' file server, is resyncing to this unit and should be ready to go live again from Monday.
Many, many thanks to iX
My only 'thing' is I wish I knew where I originally went wrong...?

 

[Mlovelace]

I'd just like to close this thrad on a happy note... I received a replacement MB from iX and bingo everything is back up and running, so now my backup freeNAS - which we had switched to as our 'live' file server, is resyncing to this unit and should be ready to go live again from Monday.
Many, many thanks to iX
My only 'thing' is I wish I knew where I originally went wrong...?

Well based on what you explained earlier, the SM script used "sas2flash -o -e 7", which according to the LSI manual, should have been"sas2flash -o -e 6". So, I don't believe it was your fault. For future reference, I would use the firmware directly from Avago(LSI).

 

[Spearfoot]

Well based on what you explained earlier, the SM script used "sas2flash -o -e 7", which according to the LSI manual, should have been"sas2flash -o -e 6". So, I don't believe it was your fault. For future reference, I would use the firmware directly from Avago(LSI).

I'm still not satisfied about this. The only difference between sas2flash options 6 and 7 is that the latter erases the manufacturing area; both delete the same flash regions otherwise:

Also, I used Supermicro's SMC2308T.NSH script successfully on my X10SL7-F, which uses the same LSI 2308 chip:

Code:

echo -off
sas2flash.efi -o -e 7
cls
sas2flash.efi -f 2308T204.ROM
sas2flash.efi -b mptsas2.rom
sas2flash.efi -b x64sas2.rom
cls
sas2flash.efi -o -sasaddhi 5003048

It just doesn't make any sense that the flash failed!

But despite this mystery, I'm glad that @Harrison has his system up and running.

 

[Mirfster]

If I recall, I have only used the "7" option when I was desperate. I think that it is similar to using "megarec -writesbr sbrempty.bin" (where you have a viable "sbrempty.bin" file available...).

I think the "7" option also erases the SAS Address on the card, so one would want to make sure to get that and write it down first.

Of course, I could always be wrong in my recollection...

 

[Stux]

sbrempty.bin is 256 bytes of zero