SLR 8000 LAN issues

[shag]

Earlier this week, colleagues & I replaced a MTR3000 with a new SLR8000. For some reason we had issues connecting the SLR to the LAN - the port wouldn't come up even though we've tested it using a laptop on both ends (laptop to switch, laptop to SLR). We've determined that it doesn't like Auto-negotiate so we forced it at 100Mbps Full Duplex, which in theory resolved the issue. The IPSC network was working fine for a while.

Fast forward to yesterday evening, the hardware link flapped 5 times according to the switch's log (physical port down, physical port up, DHCP request, DHCP assign). The repeater was unreachable by ping even though the port was up. Before anyone asks, the repeater has a static IP address in the DHCP server, and yes, we replaced the cabling.

I had to shut/no shut the port for it to work again. I didn't have time to wireshark it but I'm assuming the IP stack was dead or in a zombie state.

Has anyone seen such behaviour on SLRs? I've also heard something about a SLR5700 on another site that kept locking up and would obviously lose Ethernet connectivity as well (on a completely different site & network config). I believe the two issues are unrelated but I'm still thinking we might be beta-testing the SLR series IP connectivity.

 

[Astro Spectra]

Yes, the "port flap issue". Happens all the time with the '5700. I have not yet updated from R01.01.04 to the firmware that came out 13.5 but that's next. The best fix so far is to run them on DC and use a decent switch or router (like Cisco) where you can remotely shut/no shut the port connected to the repeater and fix the port speed to bypass auto negotiate.

The new firmware is R02.06.05.x for SLR5700. Be careful with the intital R2.6, from the release notes: SLR5700 with 12V DC power is disabled after upgrade to R2.6, this was supposed to be fixed in R02.06.05.0002. Latest version on new 5700 shipments is R02.06.00.08 (four in over the last month).

 

[shag]

Thanks, appreciate it. So let me get this straight:

The best fix so far is to run them on DC

So this port flap bug has some relation to the AC PSU, or am I misinterpreting this?

The only thing I can remember is FSB11088 for the '5700, which mentions the DC power supply issue with R02.06.00.07. Fix is a codeplug version upgrade IIRC, but newer firmware should obviously fix that.

Do we know what's triggering the port flap other than Ma M's stellar QA process?

 

[Astro Spectra]

Sorry if I gave that impression. The DC fix just stops the repeater from losing the correct setting once it is actually right. It protects against power dips that cause re-negotiation if you don't have a UPS.

The DC Power supply bug in early R2.6 was unrelated but was my warning that the above precaution would break if that was the firmware in your machine.

IMHO the port flap is caused my the handler code for the Ethernet port connected to the TI OMAP CPU. QA yes but more specifically the coders.

 

[shag]

Got a 5700 back from the depot with a new PA, and they flashed R02.06.00.08 on it. Not sure why they haven't gone straight to the newer stuff.

Back to the 8000: Data messages (e.g. radio checks or similar) from the IPSC side seems to crash the IP interface. Need to flap it from the switch to return to service. Interesting...


Sent from my iPhone using Tapatalk

 

[com501]

2.06.00.08 is most current flash. 2.40.xx is older. Yes, Moto has screwed with the version numbers.