Closed Bug 632430 Opened 15 years ago Closed 14 years ago

Intermittent AP issues in MTV1

Categories

(Infrastructure & Operations Graveyard :: NetOps, task)

Product:
Infrastructure & Operations Graveyard
Component:
NetOps
Platform:
x86
All
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: joduinn, Assigned: ravi)

Details

I'm at my desk, on "Mozilla" network, no VPN. This also happened yesterday. 1) At first I thought it was my machine, but I've rebooted my MBP a few times now, and this keeps happening. 2) I then thought it was irssi on people.m.o behaving badly, but then ping showed me this: host-6-28:~ john$ ping people.mozilla.org PING people.mozilla.com (63.245.208.169): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 64 bytes from 63.245.208.169: icmp_seq=0 ttl=61 time=3242.443 ms 64 bytes from 63.245.208.169: icmp_seq=1 ttl=61 time=2242.313 ms 64 bytes from 63.245.208.169: icmp_seq=2 ttl=61 time=1242.142 ms 64 bytes from 63.245.208.169: icmp_seq=3 ttl=61 time=241.948 ms 64 bytes from 63.245.208.169: icmp_seq=4 ttl=61 time=2.775 ms 64 bytes from 63.245.208.169: icmp_seq=5 ttl=61 time=11.854 ms 64 bytes from 63.245.208.169: icmp_seq=6 ttl=61 time=2.824 ms 64 bytes from 63.245.208.169: icmp_seq=7 ttl=61 time=2.368 ms 64 bytes from 63.245.208.169: icmp_seq=8 ttl=61 time=4.852 ms 64 bytes from 63.245.208.169: icmp_seq=9 ttl=61 time=73.092 ms 64 bytes from 63.245.208.169: icmp_seq=10 ttl=61 time=11.496 ms 64 bytes from 63.245.208.169: icmp_seq=11 ttl=61 time=2.368 ms 64 bytes from 63.245.208.169: icmp_seq=12 ttl=61 time=3.783 ms 64 bytes from 63.245.208.169: icmp_seq=13 ttl=61 time=2.133 ms 64 bytes from 63.245.208.169: icmp_seq=14 ttl=61 time=2.519 ms 64 bytes from 63.245.208.169: icmp_seq=15 ttl=61 time=2.280 ms 64 bytes from 63.245.208.169: icmp_seq=16 ttl=61 time=3.202 ms 64 bytes from 63.245.208.169: icmp_seq=17 ttl=61 time=3.157 ms 64 bytes from 63.245.208.169: icmp_seq=18 ttl=61 time=2.345 ms 64 bytes from 63.245.208.169: icmp_seq=19 ttl=61 time=4.154 ms 64 bytes from 63.245.208.169: icmp_seq=20 ttl=61 time=4.814 ms 64 bytes from 63.245.208.169: icmp_seq=21 ttl=61 time=52.093 ms 64 bytes from 63.245.208.169: icmp_seq=22 ttl=61 time=3.441 ms 64 bytes from 63.245.208.169: icmp_seq=23 ttl=61 time=4.558 ms 64 bytes from 63.245.208.169: icmp_seq=24 ttl=61 time=3.056 ms 64 bytes from 63.245.208.169: icmp_seq=25 ttl=61 time=7.711 ms 64 bytes from 63.245.208.169: icmp_seq=26 ttl=61 time=19.750 ms 64 bytes from 63.245.208.169: icmp_seq=27 ttl=61 time=4.764 ms 64 bytes from 63.245.208.169: icmp_seq=28 ttl=61 time=12.015 ms 64 bytes from 63.245.208.169: icmp_seq=29 ttl=61 time=6.816 ms 64 bytes from 63.245.208.169: icmp_seq=30 ttl=61 time=37.000 ms 64 bytes from 63.245.208.169: icmp_seq=31 ttl=61 time=8.902 ms 64 bytes from 63.245.208.169: icmp_seq=32 ttl=61 time=4.546 ms 64 bytes from 63.245.208.169: icmp_seq=34 ttl=61 time=4.920 ms 64 bytes from 63.245.208.169: icmp_seq=35 ttl=61 time=2.926 ms 64 bytes from 63.245.208.169: icmp_seq=36 ttl=61 time=5.981 ms 64 bytes from 63.245.208.169: icmp_seq=37 ttl=61 time=3.575 ms 64 bytes from 63.245.208.169: icmp_seq=38 ttl=61 time=1020.363 ms 64 bytes from 63.245.208.169: icmp_seq=39 ttl=61 time=792.276 ms 64 bytes from 63.245.208.169: icmp_seq=40 ttl=61 time=1016.555 ms 64 bytes from 63.245.208.169: icmp_seq=41 ttl=61 time=1962.445 ms 64 bytes from 63.245.208.169: icmp_seq=42 ttl=61 time=962.166 ms 64 bytes from 63.245.208.169: icmp_seq=44 ttl=61 time=12.622 ms 64 bytes from 63.245.208.169: icmp_seq=45 ttl=61 time=10.608 ms 64 bytes from 63.245.208.169: icmp_seq=46 ttl=61 time=22.150 ms 64 bytes from 63.245.208.169: icmp_seq=47 ttl=61 time=7.091 ms 64 bytes from 63.245.208.169: icmp_seq=48 ttl=61 time=3.991 ms 64 bytes from 63.245.208.169: icmp_seq=49 ttl=61 time=2.369 ms 64 bytes from 63.245.208.169: icmp_seq=50 ttl=61 time=5.038 ms .... I wasnt aware of this lagginess last week.
Guessing this goes to NetOps? (please re-shuffle if needed)
Assignee: server-ops → network-operations
Component: Server Operations → Server Operations: Netops
switched to ethernet, turned off wifi and now ping is better. All in the range of 1ms - 14ms. Either something wrong with the access point near my desk - or else my wifi in this MBP?
If you are at your desk then that AP this morning in bursts of at least 20 minutes were pushing nearly 70Mbps of sustained traffic. This could almost certainly be contributing to issues if the windows overlap. Are you or others on your team doing any large data transfers or anything that may be contributing to these traffic bursts?
Controller reset (OS upgrade today). Going to close but reopen if this happens again.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
(In reply to comment #3) > If you are at your desk then that AP this morning in bursts of at least 20 > minutes were pushing nearly 70Mbps of sustained traffic. This could almost > certainly be contributing to issues if the windows overlap. > > Are you or others on your team doing any large data transfers or anything that > may be contributing to these traffic bursts? None that I know of. Also, I overheard jhford telling dmoore he had the same problem the day before at his desk (adjacent to mine), so we three ruled out my MBP. (sorry for not adding this to the bug). Anyway, I'll watch for this again tomorrow; if its still a problem, I'll reopen.
OS: Mac OS X → All
(In reply to comment #5) > (In reply to comment #3) > > If you are at your desk then that AP this morning in bursts of at least 20 > > minutes were pushing nearly 70Mbps of sustained traffic. This could almost > > certainly be contributing to issues if the windows overlap. > > > > Are you or others on your team doing any large data transfers or anything that > > may be contributing to these traffic bursts? > > None that I know of. Also, I overheard jhford telling dmoore he had the same > problem the day before at his desk (adjacent to mine), so we three ruled out my > MBP. (sorry for not adding this to the bug). > > Anyway, I'll watch for this again tomorrow; if its still a problem, I'll > reopen. Reopening. Still getting variable ping times, and some dropped packets all morning. Like last time, at my desk, with no VPN. 64 bytes from 63.245.208.169: icmp_seq=2017 ttl=61 time=11.109 ms 64 bytes from 63.245.208.169: icmp_seq=2018 ttl=61 time=12.766 ms 64 bytes from 63.245.208.169: icmp_seq=2019 ttl=61 time=12.294 ms 64 bytes from 63.245.208.169: icmp_seq=2020 ttl=61 time=7.879 ms 64 bytes from 63.245.208.169: icmp_seq=2021 ttl=61 time=13.382 ms 64 bytes from 63.245.208.169: icmp_seq=2022 ttl=61 time=9.480 ms 64 bytes from 63.245.208.169: icmp_seq=2023 ttl=61 time=13.724 ms 64 bytes from 63.245.208.169: icmp_seq=2024 ttl=61 time=9.743 ms 64 bytes from 63.245.208.169: icmp_seq=2025 ttl=61 time=12.923 ms 64 bytes from 63.245.208.169: icmp_seq=2026 ttl=61 time=14.867 ms 64 bytes from 63.245.208.169: icmp_seq=2027 ttl=61 time=13.097 ms 64 bytes from 63.245.208.169: icmp_seq=2028 ttl=61 time=2.984 ms 64 bytes from 63.245.208.169: icmp_seq=2029 ttl=61 time=6.243 ms 64 bytes from 63.245.208.169: icmp_seq=2030 ttl=61 time=8.984 ms 64 bytes from 63.245.208.169: icmp_seq=2031 ttl=61 time=9.782 ms 64 bytes from 63.245.208.169: icmp_seq=2032 ttl=61 time=9.554 ms 64 bytes from 63.245.208.169: icmp_seq=2033 ttl=61 time=8.837 ms 64 bytes from 63.245.208.169: icmp_seq=2034 ttl=61 time=6.861 ms 64 bytes from 63.245.208.169: icmp_seq=2035 ttl=61 time=8.963 ms 64 bytes from 63.245.208.169: icmp_seq=2036 ttl=61 time=6.608 ms 64 bytes from 63.245.208.169: icmp_seq=2037 ttl=61 time=10.082 ms 64 bytes from 63.245.208.169: icmp_seq=2038 ttl=61 time=8.477 ms 64 bytes from 63.245.208.169: icmp_seq=2039 ttl=61 time=7.937 ms 64 bytes from 63.245.208.169: icmp_seq=2040 ttl=61 time=8.325 ms 64 bytes from 63.245.208.169: icmp_seq=2041 ttl=61 time=7.116 ms 64 bytes from 63.245.208.169: icmp_seq=2042 ttl=61 time=7.871 ms 64 bytes from 63.245.208.169: icmp_seq=2043 ttl=61 time=11.827 ms 64 bytes from 63.245.208.169: icmp_seq=2044 ttl=61 time=11.112 ms 64 bytes from 63.245.208.169: icmp_seq=2045 ttl=61 time=13.515 ms 64 bytes from 63.245.208.169: icmp_seq=2046 ttl=61 time=14.021 ms 64 bytes from 63.245.208.169: icmp_seq=2047 ttl=61 time=13.764 ms 64 bytes from 63.245.208.169: icmp_seq=2048 ttl=61 time=13.559 ms 64 bytes from 63.245.208.169: icmp_seq=2049 ttl=61 time=8.117 ms Request timeout for icmp_seq 2050 64 bytes from 63.245.208.169: icmp_seq=2051 ttl=61 time=13.314 ms 64 bytes from 63.245.208.169: icmp_seq=2052 ttl=61 time=5.913 ms 64 bytes from 63.245.208.169: icmp_seq=2053 ttl=61 time=12.608 ms 64 bytes from 63.245.208.169: icmp_seq=2054 ttl=61 time=15.864 ms 64 bytes from 63.245.208.169: icmp_seq=2055 ttl=61 time=12.459 ms 64 bytes from 63.245.208.169: icmp_seq=2056 ttl=61 time=11.625 ms 64 bytes from 63.245.208.169: icmp_seq=2057 ttl=61 time=13.451 ms 64 bytes from 63.245.208.169: icmp_seq=2058 ttl=61 time=14.511 ms 64 bytes from 63.245.208.169: icmp_seq=2059 ttl=61 time=14.331 ms 64 bytes from 63.245.208.169: icmp_seq=2060 ttl=61 time=10.422 ms 6
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
ICMP isn't the best test since network devices deprioritize ICMP when the load otherwise gets too high. Our connection from MTV1 out is only 100M connection and when this is reached (and it does happen often). When you combine this with being a wireless client everything seems perfectly reasonable.
Havent sat at my desk for several days, but now at my desk this morning and sad to see: $ ping people.mozilla.org PING people.mozilla.com (63.245.208.169): 56 data bytes 64 bytes from 63.245.208.169: icmp_seq=0 ttl=62 time=4.451 ms 64 bytes from 63.245.208.169: icmp_seq=1 ttl=62 time=780.577 ms 64 bytes from 63.245.208.169: icmp_seq=2 ttl=62 time=805.605 ms Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 64 bytes from 63.245.208.169: icmp_seq=3 ttl=62 time=2290.591 ms 64 bytes from 63.245.208.169: icmp_seq=4 ttl=62 time=1290.525 ms 64 bytes from 63.245.208.169: icmp_seq=5 ttl=62 time=290.447 ms 64 bytes from 63.245.208.169: icmp_seq=8 ttl=62 time=2.861 ms 64 bytes from 63.245.208.169: icmp_seq=9 ttl=62 time=955.613 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 64 bytes from 63.245.208.169: icmp_seq=10 ttl=62 time=2165.065 ms 64 bytes from 63.245.208.169: icmp_seq=11 ttl=62 time=1165.018 ms 64 bytes from 63.245.208.169: icmp_seq=12 ttl=62 time=165.009 ms 64 bytes from 63.245.208.169: icmp_seq=13 ttl=62 time=617.947 ms 64 bytes from 63.245.208.169: icmp_seq=14 ttl=62 time=1265.184 ms 64 bytes from 63.245.208.169: icmp_seq=15 ttl=62 time=2012.766 ms 64 bytes from 63.245.208.169: icmp_seq=16 ttl=62 time=1012.581 ms 64 bytes from 63.245.208.169: icmp_seq=18 ttl=62 time=165.062 ms 64 bytes from 63.245.208.169: icmp_seq=19 ttl=62 time=179.057 ms 64 bytes from 63.245.208.169: icmp_seq=20 ttl=62 time=1261.315 ms 64 bytes from 63.245.208.169: icmp_seq=21 ttl=62 time=261.220 ms Request timeout for icmp_seq 23 Request timeout for icmp_seq 24 64 bytes from 63.245.208.169: icmp_seq=22 ttl=62 time=3534.070 ms 64 bytes from 63.245.208.169: icmp_seq=23 ttl=62 time=2533.977 ms 64 bytes from 63.245.208.169: icmp_seq=24 ttl=62 time=1533.880 ms 64 bytes from 63.245.208.169: icmp_seq=25 ttl=62 time=533.688 ms 64 bytes from 63.245.208.169: icmp_seq=26 ttl=62 time=1011.315 ms 64 bytes from 63.245.208.169: icmp_seq=27 ttl=62 time=1004.878 ms 64 bytes from 63.245.208.169: icmp_seq=28 ttl=62 time=1005.851 ms 64 bytes from 63.245.208.169: icmp_seq=29 ttl=62 time=727.720 ms 64 bytes from 63.245.208.169: icmp_seq=30 ttl=62 time=751.928 ms ... If there is a better way for me to measure this, please let me know. (cc-ing others sitting nearby who also verbally confirmed problems, but didnt yet file a bug).
Whatever you do please do not unplug the AP by your desk and if you can bear with the issues stay associated at your current location. I'm going to raise support so they can troubleshoot live.
fyi: I left the ping running in background window, and now, when talking to ravi I see: 64 bytes from 63.245.208.169: icmp_seq=1167 ttl=62 time=3.901 ms 64 bytes from 63.245.208.169: icmp_seq=1168 ttl=62 time=10.460 ms 64 bytes from 63.245.208.169: icmp_seq=1169 ttl=62 time=11.496 ms 64 bytes from 63.245.208.169: icmp_seq=1170 ttl=62 time=10.490 ms 64 bytes from 63.245.208.169: icmp_seq=1171 ttl=62 time=7.708 ms 64 bytes from 63.245.208.169: icmp_seq=1172 ttl=62 time=6.753 ms 64 bytes from 63.245.208.169: icmp_seq=1173 ttl=62 time=16.095 ms 64 bytes from 63.245.208.169: icmp_seq=1174 ttl=62 time=2.732 ms 64 bytes from 63.245.208.169: icmp_seq=1175 ttl=62 time=3.828 ms 64 bytes from 63.245.208.169: icmp_seq=1176 ttl=62 time=2.209 ms 64 bytes from 63.245.208.169: icmp_seq=1177 ttl=62 time=5.180 ms 64 bytes from 63.245.208.169: icmp_seq=1178 ttl=62 time=10.604 ms 64 bytes from 63.245.208.169: icmp_seq=1179 ttl=62 time=3.008 ms 64 bytes from 63.245.208.169: icmp_seq=1180 ttl=62 time=2.421 ms 64 bytes from 63.245.208.169: icmp_seq=1181 ttl=62 time=14.824 ms 64 bytes from 63.245.208.169: icmp_seq=1182 ttl=62 time=5.822 ms Neither of us know why its improved right now, but noting here for the record. Something variable going on.
When this happens, I start pinging the gateway, 10.250.0.1, if the same dropped packets are experienced, then this is very likely the issue with the access point and takes out any other variables like the connection to MPT.
Just to throw a wild card in there -- the AP has been replaced twice. So 3 different APs have exhibited the same problem which makes me wonder if it is a location + interference + * problem. I'm going to bring up another AP for the area and put it in monitor mode to hopefully help the controller mitigate potential problem.
every time I've experienced the issue, I've been connected to the same MAC address (option click on wireless icon in OSX to show information about the AP). I'm not sure if I had any problems before it was replaced last time.
I'm getting terrible lags right now in my connectivity: 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=14 ttl=62 time=105 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=15 ttl=62 time=127 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=16 ttl=62 time=136 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=17 ttl=62 time=183 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=20 ttl=62 time=38.3 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=23 ttl=62 time=12.3 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=25 ttl=62 time=54.9 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=26 ttl=62 time=56.8 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=27 ttl=62 time=53.8 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=30 ttl=62 time=131 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=31 ttl=62 time=94.0 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=32 ttl=62 time=21.3 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=33 ttl=62 time=37.5 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=34 ttl=62 time=62.3 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=35 ttl=62 time=35.7 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=37 ttl=62 time=45.8 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=38 ttl=62 time=43.3 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=39 ttl=62 time=66.8 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=40 ttl=62 time=82.5 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=43 ttl=62 time=244 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=44 ttl=62 time=47.2 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=45 ttl=62 time=11.9 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=47 ttl=62 time=50.9 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=48 ttl=62 time=93.8 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=50 ttl=62 time=147 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=54 ttl=62 time=118 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=55 ttl=62 time=56.0 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=59 ttl=62 time=134 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=60 ttl=62 time=151 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=61 ttl=62 time=181 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=62 ttl=62 time=61.1 ms 64 bytes from people.mozilla.com (63.245.208.169): icmp_req=64 ttl=62 time=39.1 ms Sitting at 2nd floor desk.
There was just a short internet service degrade in MV. If you want to test the possibility of an AP issue I'd ping something like mv-ns01 10.250.0.21.
I have been having trouble today from Toronto. The lag is just so awful.
(In reply to comment #16) What does people.mozilla.org resolve to? Either way any intermittent issue noted in comment #15 is compounded by the path TOR1 takes to get to SCJ1. Our current link (100M) has been getting full regularly. This is being resolved by the turnup of a a larger capacity circuit which we should be switched over to sometime next week.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → INCOMPLETE
(In reply to comment #17) > (In reply to comment #16) > > What does people.mozilla.org resolve to? Either way any intermittent issue > noted in comment #15 is compounded by the path TOR1 takes to get to SCJ1. > > Our current link (100M) has been getting full regularly. This is being > resolved by the turnup of a a larger capacity circuit which we should be > switched over to sometime next week. If the larger capacity circuit did go live last month, it did not fix the problem. Still having problems today: 64 bytes from 63.245.208.169: icmp_seq=0 ttl=62 time=53.361 ms 64 bytes from 63.245.208.169: icmp_seq=1 ttl=62 time=14.267 ms Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 64 bytes from 63.245.208.169: icmp_seq=4 ttl=62 time=8.840 ms 64 bytes from 63.245.208.169: icmp_seq=5 ttl=62 time=56.953 ms 64 bytes from 63.245.208.169: icmp_seq=6 ttl=62 time=11.300 ms Request timeout for icmp_seq 7 64 bytes from 63.245.208.169: icmp_seq=7 ttl=62 time=1120.333 ms Request timeout for icmp_seq 9 64 bytes from 63.245.208.169: icmp_seq=8 ttl=62 time=2202.319 ms 64 bytes from 63.245.208.169: icmp_seq=9 ttl=62 time=1202.350 ms 64 bytes from 63.245.208.169: icmp_seq=10 ttl=62 time=202.205 ms Request timeout for icmp_seq 13 Request timeout for icmp_seq 14 64 bytes from 63.245.208.169: icmp_seq=11 ttl=62 time=4371.776 ms 64 bytes from 63.245.208.169: icmp_seq=12 ttl=62 time=3371.620 ms 64 bytes from 63.245.208.169: icmp_seq=13 ttl=62 time=2371.501 ms 64 bytes from 63.245.208.169: icmp_seq=14 ttl=62 time=1371.328 ms 64 bytes from 63.245.208.169: icmp_seq=15 ttl=62 time=371.199 ms 64 bytes from 63.245.208.169: icmp_seq=16 ttl=62 time=314.187 ms 64 bytes from 63.245.208.169: icmp_seq=17 ttl=62 time=80.835 ms 64 bytes from 63.245.208.169: icmp_seq=18 ttl=62 time=2720.873 ms 64 bytes from 63.245.208.169: icmp_seq=19 ttl=62 time=1720.814 ms 64 bytes from 63.245.208.169: icmp_seq=20 ttl=62 time=720.665 ms 64 bytes from 63.245.208.169: icmp_seq=21 ttl=62 time=1254.376 ms 64 bytes from 63.245.208.169: icmp_seq=22 ttl=62 time=254.230 ms Per comment#15, I confirmed similarly bad behavior when pinging: joduinns-Computer:~ john$ ping 10.250.0.21 PING 10.250.0.21 (10.250.0.21): 56 data bytes 64 bytes from 10.250.0.21: icmp_seq=0 ttl=64 time=503.793 ms Request timeout for icmp_seq 1 64 bytes from 10.250.0.21: icmp_seq=2 ttl=64 time=0.988 ms 64 bytes from 10.250.0.21: icmp_seq=3 ttl=64 time=0.983 ms 64 bytes from 10.250.0.21: icmp_seq=4 ttl=64 time=1.038 ms Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 Request timeout for icmp_seq 7 Request timeout for icmp_seq 8 Request timeout for icmp_seq 9 64 bytes from 10.250.0.21: icmp_seq=5 ttl=64 time=5078.587 ms 64 bytes from 10.250.0.21: icmp_seq=6 ttl=64 time=4078.590 ms 64 bytes from 10.250.0.21: icmp_seq=7 ttl=64 time=3078.494 ms 64 bytes from 10.250.0.21: icmp_seq=8 ttl=64 time=2078.328 ms 64 bytes from 10.250.0.21: icmp_seq=9 ttl=64 time=1078.153 ms 64 bytes from 10.250.0.21: icmp_seq=10 ttl=64 time=2028.944 ms 64 bytes from 10.250.0.21: icmp_seq=11 ttl=64 time=1028.875 ms 64 bytes from 10.250.0.21: icmp_seq=12 ttl=64 time=1146.392 ms 64 bytes from 10.250.0.21: icmp_seq=13 ttl=64 time=1426.781 ms 64 bytes from 10.250.0.21: icmp_seq=14 ttl=64 time=426.562 ms 64 bytes from 10.250.0.21: icmp_seq=16 ttl=64 time=1.008 ms 64 bytes from 10.250.0.21: icmp_seq=17 ttl=64 time=1.060 ms ^C --- 10.250.0.21 ping statistics --- 18 packets transmitted, 16 packets received, 11.1% packet loss round-trip min/avg/max/stddev = 0.983/1372.411/5078.587/1504.382 ms
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Summary: ping to people.m.o takes between 1ms and >3000ms → Intermittent AP issues in MTV1
I am getting this now on my loaner while connected to BSSID: 0:1a:1e:66:19:d0 host-2-120:~ jhford$ ping 10.250.1.52 PING 10.250.1.52 (10.250.1.52): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 64 bytes from 10.250.1.52: icmp_seq=0 ttl=64 time=3014.208 ms 64 bytes from 10.250.1.52: icmp_seq=1 ttl=64 time=2014.143 ms 64 bytes from 10.250.1.52: icmp_seq=2 ttl=64 time=1014.047 ms 64 bytes from 10.250.1.52: icmp_seq=3 ttl=64 time=13.916 ms 64 bytes from 10.250.1.52: icmp_seq=4 ttl=64 time=2.027 ms 64 bytes from 10.250.1.52: icmp_seq=6 ttl=64 time=1168.927 ms Request timeout for icmp_seq 9 Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 64 bytes from 10.250.1.52: icmp_seq=13 ttl=64 time=179.386 ms 64 bytes from 10.250.1.52: icmp_seq=14 ttl=64 time=0.989 ms 64 bytes from 10.250.1.52: icmp_seq=15 ttl=64 time=2.754 ms ^C --- 10.250.1.52 ping statistics --- 17 packets transmitted, 9 packets received, 47.1% packet loss round-trip min/avg/max/stddev = 0.989/823.377/3014.208/1025.656 ms
The client SSID is more important than the BSSID.
is that the same as the airport mac? if not, how do i get that? en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:24:36:ea:f0:01 inet6 fe80::224:36ff:feea:f001%en0 prefixlen 64 scopeid 0x4 inet 10.250.2.120 netmask 0xfffff800 broadcast 10.250.7.255 inet6 2620:101:8003:200:224:36ff:feea:f001 prefixlen 64 autoconf media: autoselect status: active
Assignee: network-operations → ravi
(In reply to comment #20) > The client SSID is more important than the BSSID. (In reply to comment #21) > is that the same as the airport mac? if not, how do i get that? ravi: ping? (also note: catlee is visiting MV, and had to give up on wireless and switch to wired in order to get work done. Any progress on this?)
Troubleshooting the presented issues is equivalent to trying to find a rattle of a moving car while you're the one driving it. Combined with the lack of feedback that things have gotten worse (or resolved themselves) and that every desk location has wired jacks (which can be enabled if not) this bug has taken a lower priority until the issues can be caught live for troubleshooting.
We did upgrades for bug 668562 which brought us to the bleeding edge version of the controller OS. While there are other issues (bug 670206) I'm going to close this out since it has not come up again in a month.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → INCOMPLETE
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.