Closed Bug 542309 Opened 10 years ago Closed 10 years ago

wifi in panic room significantly less reliable than wifi outside of panic room

Categories

(mozilla.org Graveyard :: Server Operations, task, major)

ARM
Maemo
task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aki, Assigned: dmoore)

References

Details

currently unable to retrieve IP address.

Previously, all morning, wgets to ftp.mozilla.org timed out after 3600 seconds, and I wasn't able to ssh or ping into the devices from staging-mobile-master.build.mozilla.org though joduinn verified they were networked.

(Unable to give more detailed logs as I am currently unable to retrieve IP addresses in the room with the n810s.)
These devices worked fine on MozillaBuild wifi just before being carried into the faraday cage
Blocks: 538523
Severity: normal → major
From dmoore:

"Wireless is back up in the RF room. What I had thought was a bad fiber transceiver was actually a bad fiber crossconnect. We've moved to a new fiber pair and the network is back up. The mobile devices already in the room have successfully received IP addresses via DHCP."

Thanks Derek!

I am able to ssh in to one of the n810s. Rebooting to reconnect to buildbot; hopefully these'll go green at some point.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Can't ssh into any of the panic room n810s.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: panic room network borked → unable to SSH into devices in RF Room
Summary: unable to SSH into devices in RF Room → wifi in panic room significantly less reliable than wifi outside of panic room
I changed the summary to reflect the issue we're tracking in this bug - your summary sounds like a dup of bug 542865 now.  Is it?
I can't currently connect the n810s in the panic room to wifi, despite rebooting and manually attempting to connect.

The RF room aka panic room was put in place because we theorized that the competing wifi SSIDs were killing the n810s.  The RF room was going to be the magic bullet.  However, many of the n810s outside are working, none of the n810s inside are working.  This has been the case since we moved the n810s into the room.  Whether it's difficulty sshing in, very very slow throughput (between 0 and ~1.5kb/s) or just not being able to reconnect to the wifi network.

I don't think it's any one thing.  We need all of it to work for the n810s inside to be at least as reliable as the n810s outside.
Assignee: server-ops → dmoore
I was able to remotely diagnose a problem with the wireless bridging while in Phoenix last week, but it wasn't until this morning that we were able to install a temporary access point replacement.

At this time, all the n810s are online.

In the future, we also need to ensure that they aren't SSID-hopping over to Mozilla-Build when someone opens the door. When I came down today, the RF room door was open. The n810s could see Mozilla-Build, but with poor signal strength. Please take whatever measures might be necessary to keep them from associating to anything but the RF Room SSID.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 542865
the door was not working the last time I used it.
(In reply to comment #8)
> the door was not working the last time I used it.


Confirmed, it's out of order and forced open. We'll address that separately.
Cool, I just sshed into maemo-n810-09 (responsive) and ran wget and got 500-600 kbps.  We'll need to monitor this over time but this is looking much better than I've seen it.  Thanks Derek!
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.