Opened 8 months ago

Closed 8 months ago

#1167 closed request (fixed)

Various issues in v6ops now

Reported by: robert@… Owned by: panda@…
Priority: tbd Milestone: ietf-100
Component: incoming Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

Hi,

This is on the ietf wifi, v6ops, front/right:

64 bytes from 85.10.198.82: icmp_seq=18 ttl=54 time=270.716 ms
64 bytes from 85.10.198.82: icmp_seq=19 ttl=54 time=265.144 ms
64 bytes from 85.10.198.82: icmp_seq=20 ttl=54 time=233.516 ms
64 bytes from 85.10.198.82: icmp_seq=21 ttl=54 time=252.261 ms
64 bytes from 85.10.198.82: icmp_seq=22 ttl=54 time=457.497 ms
64 bytes from 85.10.198.82: icmp_seq=23 ttl=54 time=1190.387 ms
64 bytes from 85.10.198.82: icmp_seq=24 ttl=54 time=241.118 ms
64 bytes from 85.10.198.82: icmp_seq=25 ttl=54 time=250.925 ms
64 bytes from 85.10.198.82: icmp_seq=26 ttl=54 time=272.270 ms
64 bytes from 85.10.198.82: icmp_seq=27 ttl=54 time=2100.451 ms
64 bytes from 85.10.198.82: icmp_seq=28 ttl=54 time=1390.487 ms
64 bytes from 85.10.198.82: icmp_seq=29 ttl=54 time=2885.500 ms
Request timeout for icmp_seq 32
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
Request timeout for icmp_seq 37
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
Request timeout for icmp_seq 47
Request timeout for icmp_seq 48
64 bytes from 85.10.198.82: icmp_seq=30 ttl=54 time=19277.164 ms
64 bytes from 85.10.198.82: icmp_seq=31 ttl=54 time=18312.944 ms
64 bytes from 85.10.198.82: icmp_seq=32 ttl=54 time=17385.429 ms
64 bytes from 85.10.198.82: icmp_seq=33 ttl=54 time=16529.569 ms
Request timeout for icmp_seq 53
Request timeout for icmp_seq 54
Request timeout for icmp_seq 55
Request timeout for icmp_seq 56
Request timeout for icmp_seq 57
Request timeout for icmp_seq 58
Request timeout for icmp_seq 59
^C
--- kadarka.kistel.hu ping statistics ---
61 packets transmitted, 33 packets received, 45.9% packet loss
round-trip min/avg/max/stddev = 224.028/2867.916/19277.164/5631.803 ms

I'm thrown off frequently. When I get on, DHCP(v4) doesn't always give
an address. Sending this from ietf-legacy100 now.

Using Macbook pro, Sierra latest.

Regards,
Robert

Attachments (1)

Screen Shot 2017-11-13 at 16.42.53.png (146.9 KB) - added by robert@… 8 months ago.
Added by email2trac

Download all attachments as: .zip

Change history (9)

comment:1 Changed 8 months ago by panda@…

Owner: changed from < default > to panda@…
Status: newaccepted

Hi,

Thank you for your report.

Could you please try ietf-nat64, ietf-nat64-unencrypted, or ietf-v6only?

We are sorry but we have disabled dual stack networks (i.e., ietf, ietf-legacy100, eduroam, ietf-2.4ONLY) during this v6ops meeting as per the request from v6ops WG. I think you are using radio leaked from the sibling rooms, and experiencing bad quality.

Thank you.

comment:2 in reply to:  2 ; Changed 8 months ago by robert@…

Ahh, ok, I was not here for the first couple of minutes, I'm assuming
they announced it then...

However it's still surprising that eduroam is included in this special
list... This is, in fact, breaking the functionality of a different network.

Regards,
Robert


On 2017-11-13 14:03, IETF Tickets/NOC wrote:
> #1167: Various issues in v6ops now
> ---------------------------+--------------------------------
>       Reporter:  robert@…  |                Owner:  panda@…
>           Type:  request   |               Status:  accepted
>       Priority:  tbd       |            Milestone:  ietf-100
>      Component:  incoming  |           Resolution:
>       Keywords:            |  My Current Location:
> My MAC  Address:           |                My OS:
> ---------------------------+--------------------------------
> Changes (by panda@…):
> 
>  * owner:  < default > => panda@…
>  * status:  new => accepted
> 
> 
> Comment:
> 
>  Hi,
> 
>  Thank you for your report.
> 
>  Could you please try ietf-nat64, ietf-nat64-unencrypted, or ietf-v6only?
> 
>  We are sorry but we have disabled dual stack networks (i.e., ietf, ietf-
>  legacy100, eduroam, ietf-2.4ONLY) during this v6ops meeting as per the
>  request from v6ops WG. I think you are using radio leaked from the sibling
>  rooms, and experiencing bad quality.
> 
>  Thank you.
> 
> --
> Ticket URL: <https://tickets.meeting.ietf.org/ticket/1167#comment:1>
> IETF Tickets/NOC <https://tickets.meeting.ietf.org>
> IETF Meeting Tickets - NOC pages
> 

comment:3 Changed 8 months ago by jim@…

Robert - We disabled ALL dual stack networks. Eduroam is dual stack, and thus was included. This is just for V6OPS (and 6MAN). And yes, it was announced at the outset of the meeting, along with a plea to not use the "leaking" dual-stacks, as it negatively impacts other WGs.

comment:4 in reply to:  4 ; Changed 8 months ago by robert@…

Hi,

Even though I disagree with what happened about eduroam, I'll get over
it :-)

More to the point: in maprg (same room as v6ops) v4 connectivity is
restored, but it has its moments where I sit at front/left on 5GHz:

64 bytes from 85.10.198.82: icmp_seq=501 ttl=54 time=8463.573 ms
64 bytes from 85.10.198.82: icmp_seq=502 ttl=54 time=9266.093 ms
64 bytes from 85.10.198.82: icmp_seq=503 ttl=54 time=10867.865 ms
64 bytes from 85.10.198.82: icmp_seq=504 ttl=54 time=13116.326 ms
64 bytes from 85.10.198.82: icmp_seq=505 ttl=54 time=12146.471 ms
64 bytes from 85.10.198.82: icmp_seq=506 ttl=54 time=11298.318 ms
64 bytes from 85.10.198.82: icmp_seq=507 ttl=54 time=10441.009 ms
64 bytes from 85.10.198.82: icmp_seq=509 ttl=54 time=8470.137 ms
64 bytes from 85.10.198.82: icmp_seq=510 ttl=54 time=7641.225 ms
64 bytes from 85.10.198.82: icmp_seq=511 ttl=54 time=6651.807 ms
64 bytes from 85.10.198.82: icmp_seq=512 ttl=54 time=5678.690 ms
64 bytes from 85.10.198.82: icmp_seq=513 ttl=54 time=4720.679 ms
64 bytes from 85.10.198.82: icmp_seq=514 ttl=54 time=3726.288 ms
64 bytes from 85.10.198.82: icmp_seq=515 ttl=54 time=2757.639 ms
64 bytes from 85.10.198.82: icmp_seq=516 ttl=54 time=1769.012 ms
64 bytes from 85.10.198.82: icmp_seq=517 ttl=54 time=776.806 ms
64 bytes from 85.10.198.82: icmp_seq=518 ttl=54 time=225.355 ms
64 bytes from 85.10.198.82: icmp_seq=519 ttl=54 time=556.042 ms
64 bytes from 85.10.198.82: icmp_seq=520 ttl=54 time=236.794 ms
64 bytes from 85.10.198.82: icmp_seq=521 ttl=54 time=518.004 ms
64 bytes from 85.10.198.82: icmp_seq=522 ttl=54 time=10206.951 ms
64 bytes from 85.10.198.82: icmp_seq=525 ttl=54 time=8445.225 ms
64 bytes from 85.10.198.82: icmp_seq=526 ttl=54 time=7479.710 ms
64 bytes from 85.10.198.82: icmp_seq=527 ttl=54 time=6551.058 ms
64 bytes from 85.10.198.82: icmp_seq=528 ttl=54 time=5654.276 ms
64 bytes from 85.10.198.82: icmp_seq=529 ttl=54 time=4660.950 ms
64 bytes from 85.10.198.82: icmp_seq=530 ttl=54 time=3661.385 ms
64 bytes from 85.10.198.82: icmp_seq=531 ttl=54 time=2667.757 ms
64 bytes from 85.10.198.82: icmp_seq=532 ttl=54 time=1667.190 ms
64 bytes from 85.10.198.82: icmp_seq=533 ttl=54 time=697.378 ms
64 bytes from 85.10.198.82: icmp_seq=534 ttl=54 time=6080.881 ms
64 bytes from 85.10.198.82: icmp_seq=535 ttl=54 time=17476.127 ms
64 bytes from 85.10.198.82: icmp_seq=536 ttl=54 time=16477.129 ms
64 bytes from 85.10.198.82: icmp_seq=537 ttl=54 time=16285.884 ms
64 bytes from 85.10.198.82: icmp_seq=538 ttl=54 time=17121.261 ms
64 bytes from 85.10.198.82: icmp_seq=539 ttl=54 time=16133.366 ms
64 bytes from 85.10.198.82: icmp_seq=540 ttl=54 time=15244.333 ms
64 bytes from 85.10.198.82: icmp_seq=541 ttl=54 time=14462.379 ms
64 bytes from 85.10.198.82: icmp_seq=542 ttl=54 time=13499.193 ms
64 bytes from 85.10.198.82: icmp_seq=543 ttl=54 time=12609.123 ms
64 bytes from 85.10.198.82: icmp_seq=544 ttl=54 time=17762.244 ms
64 bytes from 85.10.198.82: icmp_seq=545 ttl=54 time=17901.255 m

This was ~10 minutes ago, since then it seems fine.

Regards,
Robert

On 2017-11-13 14:21, IETF Tickets/NOC wrote:
> #1167: Various issues in v6ops now
> ---------------------------+--------------------------------
>       Reporter:  robert@…  |                Owner:  panda@…
>           Type:  request   |               Status:  accepted
>       Priority:  tbd       |            Milestone:  ietf-100
>      Component:  incoming  |           Resolution:
>       Keywords:            |  My Current Location:
> My MAC  Address:           |                My OS:
> ---------------------------+--------------------------------
> 
> Comment (by jim@…):
> 
>  Robert - We disabled ALL dual stack networks. Eduroam is dual stack, and
>  thus was included. This is just for V6OPS (and 6MAN). And yes, it was
>  announced at the outset of the meeting, along with a plea to not use the
>  "leaking" dual-stacks, as it negatively impacts other WGs.
> 
> --
> Ticket URL: <https://tickets.meeting.ietf.org/ticket/1167#comment:3>
> IETF Tickets/NOC <https://tickets.meeting.ietf.org>
> IETF Meeting Tickets - NOC pages
> 

comment:5 Changed 8 months ago by panda@…

Can you tell us your BSSID and IPv4 address so that we can investigate further? I suspect it was due to high load or bad air quality.

comment:6 in reply to:  6 ; Changed 8 months ago by robert@…

Hi,

See the attached image.

Regards,
Robert


On 2017-11-13 16:33, IETF Tickets/NOC wrote:
> #1167: Various issues in v6ops now
> ---------------------------+--------------------------------
>       Reporter:  robert@…  |                Owner:  panda@…
>           Type:  request   |               Status:  accepted
>       Priority:  tbd       |            Milestone:  ietf-100
>      Component:  incoming  |           Resolution:
>       Keywords:            |  My Current Location:
> My MAC  Address:           |                My OS:
> ---------------------------+--------------------------------
> 
> Comment (by panda@…):
> 
>  Can you tell us your BSSID and IPv4 address so that we can investigate
>  further? I suspect it was due to high load or bad air quality.
> 
> --
> Ticket URL: <https://tickets.meeting.ietf.org/ticket/1167#comment:5>
> IETF Tickets/NOC <https://tickets.meeting.ietf.org>
> IETF Meeting Tickets - NOC pages
> 

Screen Shot 2017-11-13 at 16.42.53.png

Changed 8 months ago by robert@…

Added by email2trac

comment:7 Changed 8 months ago by panda@…

I have looked through the association log and found that your device had been associated with an AP on the left-back side of the room. It resulted in bad radio quality and experience. Around 16:10, your device moved to a better AP on the front side. So, the quality issue you reported seemed to be caused by roaming failure from far-side AP to near AP for several minutes.

Thank you.

comment:8 Changed 8 months ago by panda@…

Resolution: fixed
Status: acceptedclosed

Hi,

I'm closing this ticket as this problem has been fixed now. If you see new issues please reopen this ticket or open additional tickets.

Thank you.
Hirochika Asai

Note: See TracTickets for help on using tickets.