Custom query (828 matches)
Results (40 - 42 of 828)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1189 | not broken | Re: ESSIDs at IETF 100 | ||
| Description |
For now I copy tickets @ meeting.ietf.org and remove 6MAN WG list from
subsequent follow-ups.
One ticket: I connected on ietf-v6only some years ago and since then I
got a DNS IPv6 resolver name frozen in my Windows. That makes that my
computer some times issues IPv6 DNS requests on other networks that are,
err... "IPv4 only". That is worrying for the network protectors. I
would like to no longer get such DNS IPv6 address frozen in my Windows
whenever I travel to IETF, thank you.
Second ticket: the IETF ESSIDs are friendly to MAC users and
non-friendly to Windows users.
Third ticket: security: the steps of "Uncheck Validated Server Sert" and
of the use of a public ietf/ietf username/password, and the use of a
binary IETF WiFi manager at 1x-config.org unknown to Symantec is highly
questionable.
Details below.
Alex
Le 14/11/2017 à 08:31, joel jaeggli a écrit :
> On 11/14/17 14:59, Alexandre Petrescu wrote:
>>
>>
>> Le 14/11/2017 à 07:24, Warren Kumari a écrit : [...]
>>
>>> Nope. We have the legacy SSIDs because some people apparently
>>> had issues connecting to encrypted SSIDs (because of old OS /
>>> broken wpa_supplicant, etc) - this wasn't issue with certs, but
>>> rather providing a solution for those who are unable to do WPA
>>> enterprise / have old cards, etc.
>>
>> Well - sorry, but all these reasons seem light for me.
>>
>> I have Windows 7 which is not old. Updated regularly from
>> Microsoft and from employer IT.
>
> Mainstream support ended January 13, 2015. It works, if you were
> looking for a more streamlined experience, the user experience has
> improved a bit since then, it has not been backported.
It's good to know.
I am more conservative than streamlined in terms of computer use. Just
as "ls" and "cp" stay same, the Windows experience should stay same.
>
>> The WPA_supplicant comes from original. It is widely accepted at
>> many other hotspots.
>>
>> My laptop is very well able to do WPA enterprise, and WPA2
>> Enterprise.
>>
>> The laptop is a Dell E7440, 2 or 3 years old. I dont accept to
>> call that old. What makes laptops old is when they break; they
>> often break because of mechanically moving parts like hd, but this
>> one is SSD.
>>
>> Rather, I suspect there is a preference at the Access Point to
>> favorise Macintosh variations of WiFi Clients, rather than
>> Windows.
>
> There's no obvious basis for that assertion.
See below. Basically: why the Windows users must do some manipulation
in order to make it work, but the Mac users no? That's preference.
>> I also wonder why my Windows complains that the cert emmitted by
>> IETF is "not configured as a valid anchor". Should I manually
>> install that cert? If so, that is little reasonable to ask.
> https://tickets.meeting.ietf.org/wiki/IETF100network
I think the page needs could be improved. It does not detail
"ietf-hotel" in the table, it says "5GHz" where it should say "5.4", etc.
The Windows pdf says either "ietf" or "ietf-2.4ONLY". It does not say
"ietf-v6ONLY".
The Windows pdf says at last page "Click here" on the "Configure next to
Secured password (EAP-...)" but it does not say you should continue and
further uncheck "Use Automatically my Windows Username and Password".
If you dont do that the connection does not work.
The worst is that the Windows pdf says "Uncheck this box 'Validate
Server Certificate". And then recommends to use username password
ietf/ietf published on a public web page.
Is it ok to _not_ validate Server Certificates?
Is it ok to encrypt with a password that everyone knows?
They only ask this manipulation for Windows, not for Mac. This is a
sign the AP gives preference to Mac users. BEcause the MAC users dont
have to do anything about this.
If I were to configure APs at IETF I would give equal preference to
every OS : no need to update drivers check boxes install software.
> https://802.1x-config.org/?idp=137&profile=101
Thanks again, I downloaded it. It's for Windows. Why not for Mac?
Right after download, my Enterprise anti-virus Symantec claims it has
not enough information to ensure it's good. Some reputation alert
saying Symantec never saw this file (attached). So I dont trust it.
I can trust the logo IETF puts on that page, trust the fact that it
mixes French and English, but mechanically speaking, the mechanism does
not inspire confidence.
> Cher utilisateur de IETF,
>
> Now that you have downloaded and installed a client configurator, all
> you need to do is find a IETF hotspot in your vicinity and enter your
> user credentials (this is our fancy name for 'username and password'
> or 'personal certificate') - and be online!
I dont have a 'personal certificate', where can I get one?
> Quelque soit le problème que vous pourriez éventuellement rencontrer,
> ou pour totu autre renseignement, veuillez contacter le centre de
^^^^ tout
> support de IETF. Ils diagnostiqueront le problème ou vous apporteront
> toute autre aide qui pourrait être nécessaire. Vous pouvez les
> joindre en utilisant l'un des moyens décrits ci dessus.
It leads to this
https://tickets.meeting.ietf.org/
Needs to log in...
Alex
(who once got a virus through Bluetooth at an IETF meeting :-)
>
>> Alex
>>
>>> There was an assertion made that some people were not using
>>> nat64 and were using ietf-legacy were easier, and so there should
>>> be parity, and so the ietf-nat64-unencrypted was created. We are
>>> changing the name of the ietf-legacyXXX network at each meeting
>>> because we don't people who connected to it at a previous meeting
>>> to become sticky to it and keep joining -- it requires a specific
>>> action at each meeting for the user to choose the unencrypted
>>> network -- we'd all prefer that people use the encrypted
>>> network...
>>>
>>>
>>>
>>> And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
>>>
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>>
>>>
IETF IPv6 working group mailing list
>>> ipv6@ietf.org <mailto:ipv6@ietf.org> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> <https://www.ietf.org/mailman/listinfo/ipv6>
>>> --------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
--
>>> I don't think the execution is relevant when it was obviously a
>>> bad idea in the first place. This is like putting rabid weasels
>>> in your pants, and later expressing regret at having chosen those
>>> particular rabid weasels and that pair of pants. ---maf
>>
>> --------------------------------------------------------------------
>>
>>
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>>
>
|
|||
| #1187 | pending | ipv6 temp address rotation(?) on win10 breaks long-lived connections | ||
| 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 | ||
| 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
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
$ 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. |
|||
Note: See TracQuery for help on using queries.
