Custom query (799 matches)

Filters
 
or
 
  
 
Columns

Show under each result:


Results (13 - 15 of 799)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ticket Resolution Summary Owner Reporter
#1187 pending ipv6 temp address rotation(?) on win10 breaks long-lived connections panda@… tapio.sokura@…
Description
Hello,

My problem probably isn't due to the ietf-nat64 network, as I've seen 
this happen in other v6 enabled networks as well, but here goes anyway 
as a FYI:

I'm using the ietf-nat64 wifi with a Windows 10 (1709 update) client and 
my long-lived v6-tcp connections like ssh (putty client with keepalive 
set) tend to hang after some time. This has also happened to me reguarly 
on earlier versions of Windwows. For the hangup to occur it usually 
takes between tens of minutes to about an hour or two. After I login to 
the same host again, I see the v6 address I'm coming from has changed 
from the previous address.

So it looks like windows, for some reason or another, is disabling the 
old temp v6 addresses while there still are tcp connections open. It 
should not work like this, but I guess it could just be a feature in 
windows.

Other than long-lived tcp connections breaking for me, the nat64 network 
seems to be working fine. Maybe you could switch within the next couple 
of meetings to a v6 / nat64 mode on the default "ietf" network and 
provide native v4 only on a non-default ssid.

Here's an excerpt from an ipv6 enabled server log (timestamps utc+2):
Nov 14 07:31:47 rerun sshd[29389]: Accepted publickey for oh2kku from 
2001:67c:370:1998:e0f2:6c45:5267:eccb port 49682 ssh2
Nov 14 07:43:16 rerun sshd[29464]: Accepted publickey for oh2kku from 
2001:67c:370:1998:e0f2:6c45:5267:eccb port 49271 ssh2
Nov 14 08:01:32 rerun sshd[29600]: Accepted publickey for oh2kku from 
2001:67c:370:1998:f8f8:3610:14ed:9171 port 49309 ssh2
Nov 14 09:50:38 rerun sshd[29996]: Accepted publickey for oh2kku from 
2001:67c:370:1998:f8f8:3610:14ed:9171 port 63756 ssh2
Nov 14 10:21:35 rerun sshd[30090]: Accepted publickey for oh2kku from 
2001:67c:370:1998:b8f2:7bcf:5b90:7771 port 57115 ssh2
Nov 14 11:00:14 rerun sshd[30214]: Accepted publickey for oh2kku from 
2001:67c:370:1998:c834:4990:2112:ba9b port 55005 ssh2

This is from a v4-only server log, probably only the second last line 
was from a connection terminated due to address change:
2017-11-14T07:51:40.270398+02:00 woodstock sshd[28904]: Accepted 
publickey for oh2kku from 31.130.238.245 port 49279 ssh2
2017-11-14T10:34:23.665509+02:00 woodstock sshd[3739]: Accepted 
publickey for oh2kku from 31.130.238.174 port 53071 ssh2
2017-11-14T10:55:40.395275+02:00 woodstock sshd[4780]: Accepted 
publickey for oh2kku from 31.130.238.126 port 49939 ssh2
2017-11-14T11:13:12.825515+02:00 woodstock sshd[5609]: Accepted 
publickey for oh2kku from 31.130.238.126 port 55528 ssh2


This is what "ipconfig /all" on windows said a moment ago:

Wireless LAN adapter Wi-Fi:

    Connection-specific DNS Suffix  . : meeting.ietf.org
    Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7265
    Physical Address. . . . . . . . . : 10-02-B5-92-63-05
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes
    IPv6 Address. . . . . . . . . . . : 
2001:67c:370:1998:a002:1880:27bb:f006(Preferred)
    Temporary IPv6 Address. . . . . . : 
2001:67c:370:1998:c834:4990:2112:ba9b(Preferred)
    Link-local IPv6 Address . . . . . : 
fe80::a002:1880:27bb:f006%10(Preferred)
    Autoconfiguration IPv4 Address. . : 169.254.240.6(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.0.0
    Default Gateway . . . . . . . . . : fe80::1998:1%10
    DHCPv6 IAID . . . . . . . . . . . : 168821429
    DHCPv6 Client DUID. . . . . . . . : 
00-01-00-01-20-F1-DE-FB-10-02-B5-92-63-05
    DNS Servers . . . . . . . . . . . : 2001:67c:370:229::7
                                        2001:67c:370:229::6
    NetBIOS over Tcpip. . . . . . . . : Enabled
    Connection-specific DNS Suffix Search List :
                                        meeting.ietf.org

   Tapio
#1186 duplicate ietf-NAT64 no route panda@… lee@…
Description

In Canning, 6man WG during no-ipv4 experiment. At first, took a long time to attach to ietf-nat64. A couple of minutes. Then for a little while the name servers were unreachable. 2001:67c:370:229::7 2001:67c:370:229::6 Then it worked.

An hour later, I lost it again: $ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=1<PERFORMNUD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 60:c5:47:03:ac:bc inet6 fe80::62c5:47ff:fe03:acbc%en0 prefixlen 64 scopeid 0x4 inet 169.254.254.15 netmask 0xffff0000 broadcast 169.254.255.255 inet6 2001:67c:370:1998:62c5:47ff:fe03:acbc prefixlen 64 autoconf inet6 2001:67c:370:1998:c15:546f:c892:f5c3 prefixlen 64 autoconf temporary nd6 options=1<PERFORMNUD> media: autoselect status: active

en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500

options=60<TSO4,TSO6> ether b2:00:14:44:f6:e0 media: autoselect <full-duplex> status: inactive

p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304

ether 02:c5:47:03:ac:bc media: autoselect status: inactive

bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=63<RXCSUM,TXCSUM,TSO4,TSO6> ether 62:c5:47:30:76:00 Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0 maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200 root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0 ipfilter disabled flags 0x2

member: en1 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 5 priority 0 path cost 0

nd6 options=1<PERFORMNUD> media: <unknown type> status: inactive

$ traceroute6 2001:67c:370:229::7 connect: No route to host

Still had the same two name servers configured, but couldn't reach them. Switched to ietf-v6ONLY and I have access again.

#1185 pending Default Route disappears intermittently while using ietf-nat64 panda@… david.somers-harris@…
Description

While using ietf-nat64, even though the connection works at first, eventually Internet access is lost because the default route disappears.

Attached are the outputs of netstat -nr

  1. Works: route.20171114144623​ (attached)
  2. Broken: route.20171114145135​ (attached)

I reproduced this at least twice on my Mac, and also on Windows.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Note: See TracQuery for help on using queries.