https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #116 from Cy Schubert ---
The difference between an open AP that my rtwn(4) can associate to and one it
cannot is:
associates;
wpa_driver_bsd_associate: ssid 'KQNGN3' wpa ie len 0 pairwise 1 group 1 key
mgmt 4
Does not associa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #117 from Cy Schubert ---
(In reply to rkoberman from comment #115)
I'd be interested in seeing this line of output from wpa_supplicant -dd
wpa_driver_bsd_associate: ssid 'Golden_Pond' wpa ie len 13 pairwise 1 group 1
key mgmt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #118 from Cy Schubert ---
Under wpa_supplicant 2.9 the AP in question prints,
wpa_driver_bsd_associate: ssid 'Golden_Pond' wpa ie len 0 pairwise 1 group 1
key mgmt 4
Notice that there is no IE.
2.9 ignores the IE whereas 2.10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #119 from Cy Schubert ---
So the plot thickens.
Golden_Pond, is an open guest network I created on my DMZ AP. Removing the
guest SSID and opening up the DMZ AP entirely resolves the problem. So, what
does this mean?
An open ne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #120 from Adrian Chadd ---
Cy, does it do that on freebsd as an AP? that's ... kinda wrong?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #121 from Cy Schubert ---
(In reply to Adrian Chadd from comment #120)
I haven't tried FreeBSD as an AP yet.
The "bug" is on a Netgear router (used as a router in my DMZ). It normally has
one SSID (my wife's SSID). Adding a gu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #122 from Cy Schubert ---
(In reply to Adrian Chadd from comment #120)
Using it with an open FreeBSD hostapd AP works perfectly. wpa_ie is zero.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #123 from Cy Schubert ---
Created attachment 234848
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234848&action=edit
Remove upstream cc79eb725f7b564269619ce4a64be2a80927d392
Can everyone please try this patch. If yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #124 from Jaskie ---
(In reply to Cy Schubert from comment #123)
Tested. WiFi didn't work. /usr/sbin/wpa_supplicant -dd -i wlan1 -c
/etc/wpa_supplicant.conf.open -D bsd 2>&1 | tee output.file output (~3min)
uploaded.
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #125 from Jaskie ---
Created attachment 234857
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234857&action=edit
output from wap 2.10 patched (2 patches)
--
You are receiving this mail because:
You are on the CC lis
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Glen Barber changed:
What|Removed |Added
CC|g...@freebsd.org,|r...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #127 from Cy Schubert ---
(In reply to Jaskie from comment #125)
Thank you. A different error message to work on now. (Sadly, not being able to
reproduce this problem here is a disadvantage.)
Hypothesis: I suspect the problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #128 from Cy Schubert ---
Can everyone here please confirm security/wpa_supplicant also does not work.
The port has disabled P2P support by default while base has it enabled.
--
You are receiving this mail because:
You are on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #129 from Adrian Chadd ---
heh, we shouldn't have p2p enabled until we have support for it. :-)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #130 from Cy Schubert ---
Yeah, it's not the issue anyway. Read my next post.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #131 from Cy Schubert ---
Hi Jackie,
Reviewing one of your previous outputs (wpa_out_p1) we see:
wlan0: Automatic auth_alg selection: 0x1
No supported operating classes IE to add
wlan0: Trying to associate with 70:d9:31:0e:2c:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #132 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3e8eb5c7f4909209c042403ddee340b2ee7003a5
commit 3e8eb5c7f4909209c042403ddee340b2ee7003a5
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #133 from Adrian Chadd ---
hm, so if the WPA IEs are /actually/ making it into the TXed frames and it's
not a net80211 / driver bug somehow ew.
Yes, it's common to have open + WPA VAPs. Heck, I do it at home sometimes for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #134 from Cy Schubert ---
Yes, but should it add those frames to the open VAP too?
Can you check your equipment for the same "feature?"
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #135 from Adrian Chadd ---
a) it doesn't on a tplink
b) it should not, no
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #136 from Adrian Chadd ---
oh crazy q - are the VAP MAC addresses different? Between the WPA and open
VAPs?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #137 from Cy Schubert ---
WRT one of my Netgear APs, no, they do not share the same MAC. However the 2.4
GHz and 5 GHz secondary VAPs share the same channel as their primary VAPs.
Makes sense as the device has two radios.
The o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #138 from Jaskie ---
(In reply to Cy Schubert from comment #131)
I don't understand the tech stuff and code behind this. But I can confirm that
there is only one WiFi hosted. We have different WiFi setup at different
workplace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #139 from J.R. Oldroyd ---
Would a wireshark or tcpdump with radiotap on to view the beacon management
frames be of any use here?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #140 from Cy Schubert ---
No, tcpdump will dump no packets, even in monitor mode, during scan and
association.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #141 from J.R. Oldroyd ---
(In reply to Cy Schubert from comment #140)
Won't the beacons be the same both before and after association as far as the
WPA IEs are concerned?
So dump the radiotap after association using the worki
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #142 from Adrian Chadd ---
So, the way this works is:
* during scan the net80211 stack just stores the beacons itself as scan results
* then it passes them up to wpa_supplicant via an ioctl
* then wpa_s uses the initial scan re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #143 from J.R. Oldroyd ---
(In reply to Adrian Chadd from comment #142)
Very useful info, thanks.
Except, I would point out that at the moment, I am on:
iwm0:
and I can dump my beacons after association using tcpdump.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #144 from Adrian Chadd ---
yup, once you've associated you can dump beacons on your current channel. :-)
You just can't get a dump of all the beacons on all the channels during scan!
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #145 from Bjoern A. Zeeb ---
(In reply to Adrian Chadd from comment #144)
While diverting from the actual topic; on Intel that still depends on what you
tell the firmware even after assoc (also depends on PS and other things).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #146 from Cy Schubert ---
Created attachment 234903
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234903&action=edit
Proof of Concept solution
Please try this proof of concept solution. It's a bit of a hack but if i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #147 from Cy Schubert ---
I will put my work on hold until the POC solution has been tested here.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #148 from Jaskie ---
(In reply to Cy Schubert from comment #146)
FINALLY, confirmed, wpa_supplicant worked after applying the two patches
(attachment 234807 and 234903).
I don't know if you still need it, but I got tcpdump bea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #149 from Jaskie ---
Created attachment 234915
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234915&action=edit
tcpdump beacons from wpa
tcpdump beacons from wpa 2.9 and patched 2.10 (patches from attachment 234807
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #150 from Cy Schubert ---
Thank you. I'll take a look at them.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #151 from Cy Schubert ---
Even though the patch is hackish, I may commit it in the interim to resolve
this ticket while working on a long term solution. The code this patch touches
is 14 years old so, obviously it is not the cau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #152 from Cy Schubert ---
This is definitely a wpa_supplicant 2.10 problem. Testing this on Fedora 36
results in the same error on an open secondary VAP when the primary VAP is
configured for WPA.
--
You are receiving this mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #153 from groenv...@acm.org ---
Short of a patch, Neel Chauhan's hack in bug #262183 to disable WPA
supplication
works for me on current:
# sysrc ifconfig_wlan0="ssid OPENSSID DHCP"
# service netif restart
John
groenv...@acm.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #154 from Cy Schubert ---
(In reply to groenveld from comment #153)
Did you try the Proof of Concept Solution patch, at
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234903 and the prerequisite
patch at https://bugs.freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Status|Open|In Progress
--- Comment #155 from Cy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Summary|wpa_supplicant fails to |wpa_supplicant 2.10 fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #156 from Cy Schubert ---
This also affects the security/wpa_supplicant and security/wpa_supplicant-devel
ports.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #157 from Jaskie ---
(In reply to Cy Schubert from comment #152)
I test on another laptop running Debian sid with wpa 2.10 (more here:
https://tracker.debian.org/pkg/wpa) and there is no problem. But the wireless
card is diffe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #158 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0fe8af4b2ae8b926e400f4b6eb6dbab43a91b21c
commit 0fe8af4b2ae8b926e400f4b6eb6dbab43a91b21c
Autho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #159 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1ecfe31e4272aad957eca983b48c783658a5e608
commit 1ecfe31e4272aad957eca983b48c783658a5e608
Autho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #160 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8784898e9a6d18c1d9eda42c207fda0092f84233
commit 8784898e9a6d18c1d9eda42c207fda0092f84233
Autho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #161 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7f8db05c3e87eab16e6f107b6ce94f16e4b1e75a
commit 7f8db05c3e87eab16e6f107b6ce94f16e4b1e75a
Autho
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #162 from Jaskie ---
Do I now wait for the commits to get into pkg repository? How do I track if
it's made into pkg repository?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #163 from Cy Schubert ---
(In reply to Jaskie from comment #162)
There are two parts to this. wpa_supplicant exists in the base FreeBSD and it
exists in ports.
For base, I will add the PR to the commit log message. You will se
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #164 from J.R. Oldroyd ---
This may have something to do with the problem...
diff --git a/contrib/wpa/wpa_supplicant/wpa_supplicant.c
b/contrib/wpa/wpa_supplicant/wpa_supplicant.c
index cf990f5a8f8..ba2dd470071 100644
--- a/con
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #165 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #164)
I doubt it because this code was in wpa_supplicant since 2013:
commit 8b3b803ab9fe69650da7e3b2ee9e44f0f054ee0a
Author: Arif Hussain
AuthorDate: Wed O
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #166 from J.R. Oldroyd ---
I saw that the code was there for ages.
I should perhaps have said that I am now at a place where there is a cable
modem with a primary SSID with WPA/RSN and a secondary SSID which is OPEN. So
I have
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #167 from J.R. Oldroyd ---
Ziggo-gastF69A115 92:5c:34:09:73:bb1 54M -83:-96 100 E
APCHANREP APCHANREP HTCAP WME BSSLOAD
ZiggoF69A115 d4:6e:0e:34:09:d46 54M -57:-96 100
EP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #168 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #166)
Agreed, still worth looking at. I'll look at that tonight or tomorrow. It
certainly would be a more elegant fix than the hackish workaround.
--
You are re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #169 from Cy Schubert ---
Created attachment 235029
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235029&action=edit
Try ext IE first
(In reply to J.R. Oldroyd from comment #164)
Having had a chance to study this t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #170 from J.R. Oldroyd ---
(In reply to Cy Schubert from comment #169)
Sorry, Cy, but your refined patch in attachment "Try ext IE first" does not
work. I have just tested it to confirm.
You call wpa_bss_get_ie_ext(), which c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #171 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #170)
Thanks for testing. It worked properly here, telling us there are differences
between your AP and mine here.
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Attachment #234903|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #173 from J.R. Oldroyd ---
Yes, that works since it is the same as comment #164.
Further clarification...
In your earlier revised patch, the first test:
if (!bss)
probably should have been:
if (bss)
because the origin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #174 from Bjoern A. Zeeb ---
(In reply to Cy Schubert from comment #172)
I believe the patch is wrong and is simply masking the real problem.
WLAN_EID_EXT_CAPAB is named WLAN_EID_EXT_* but like WLAN_EID_EXT_SUPP_RATES and
WLAN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #175 from J.R. Oldroyd ---
(In reply to Bjoern A. Zeeb from comment #174)
Hmm.
I am looking at IEEE 802.11-2016 in section 9.4.2.1 (pg 784).
Element ID 127 is defined as:
Extended Capabilities (see 9.4.2.27)
Element
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #176 from J.R. Oldroyd ---
Additional info before I go...
If I use the original code and allow the ext_capab IE to be added in the
"Workaround" section, these are the 13 octets that are added. Values in (hex,
dec):
DEBUG wpas
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #177 from Cy Schubert ---
I started from scratch, again.
Try this:
1. rm -rf /usr/obj/usr/src/amd64.amd64/usr.sbin/wpa
2. cd /usr/src/usr.sbin/wpa
3. make obj
4. make depend
5. make includes
6. make
7. make install
Run the te
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #178 from Cy Schubert ---
If you're running 13.1-RELEASE, add the following to usr.sbin/wpa/Makefile.inc
diff --git a/usr.sbin/wpa/Makefile.inc b/usr.sbin/wpa/Makefile.inc
index 5ce7dee4d2c5..24098bafb002 100644
--- a/usr.sbin/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #179 from Cy Schubert ---
The above instructions only work for iwn(4). Unfortunately rtwn_usb(4) is still
broken regardless.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #180 from Jaskie ---
(In reply to Cy Schubert from comment #179)
Do you want my test result on my ath? Do I just have to change
usr.sbin/wpa/Makefile.inc and no patches?
--
You are receiving this mail because:
You are on the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #181 from Cy Schubert ---
(In reply to Jaskie from comment #180)
Don't worry, it's no longer needed. I will be pushing the workaround patch
sometime tomorrow and will MFC it to stable/13 and stable/12 three days later.
re@ will
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #182 from J.R. Oldroyd ---
I think that the workaround patch is the wrong approach.
If there are many folk clamoring for a fix, then okay, commit it. But I don't
get the sense that this is that urgent is it?
What I found in y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #183 from J.R. Oldroyd ---
Latest findings...
The code in wpas_populate_assoc_ies() in the "Workaround" section calls
wpas_build_ext_capab() to create this extended capabilities IE.
wpas_populate_assoc_ies() in turn calls wpas
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #184 from J.R. Oldroyd ---
And the difference in wpas_ext_capab_byte() is due to the fact that in 2.10
various configuration options such as CONFIG_MBO and CONFIG_WNM and several
others are enabled while they appear to be disabl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #185 from J.R. Oldroyd ---
The populated IE which, according to the comments, appears to be intended as a
response to be transmitted, is being handed to wpa_drv_associate() where it is
handed to wpa_driver_bsd_associate().
wpa_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #186 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #183)
You're talking about upstream commit 2e06cef80a, which worked around
misbehaving MBO/OCE APs that use RSN without PMF. A full revert of that
upstream commit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #187 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #185)
That code has been there since 2008.
^6fc6879bd (Jouni Malinen2008-02-27 17:34:43 -0800 1265)if
(params->wpa_ie_len &&
^6fc6879bd (Jouni Ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #188 from J.R. Oldroyd ---
Yes, the code has been there for ages.
However, in 2.10 additional CONFIG_XYZ options are enabled which result in the
generation of an IE that wasn't being generated before. That IE is (correctly
or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #189 from Bjoern A. Zeeb ---
(In reply to J.R. Oldroyd from comment #188)
I think what you really want to do, rather than excluding the one element, is
to call get_ie() and search for the one you are actually interested in
chec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #190 from Bjoern A. Zeeb ---
(In reply to Bjoern A. Zeeb from comment #189)
There's a potential follow-up problem then that we need to make sure that the
way net80211 gets the packets out is also correct.
I am thinking of ieee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #191 from J.R. Oldroyd ---
Created attachment 235049
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235049&action=edit
patch to have wpa_driver_bsd_associate() check for WLAN_EID_RSN IE before
setting WPA
That's a be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
J.R. Oldroyd changed:
What|Removed |Added
Attachment #235049|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
J.R. Oldroyd changed:
What|Removed |Added
Attachment #235050|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #194 from Cy Schubert ---
Both new patches are incorrect.
The first last night, in comment #188 resolves the secondary VAP issue but
regresses association to the primary VAP configured with WPA-PSK.
The patch in comment #192 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #195 from J.R. Oldroyd ---
(In reply to Cy Schubert from comment #194)
Please try the 2nd update of the attachment patch (comment #193). It is
working for me for both the primary with WPA2 and the secondary OPEN.
But, the pat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #196 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #195)
This associates to the primary and secondary VAPs however only the primary can
dhclient obtain an IP, not through the secondary VAP. This BTW is the same
pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #197 from J.R. Oldroyd ---
(In reply to Cy Schubert from comment #196)
I am posting this reply while associated with the secondary OPEN VAP here. My
previous comment was while associated with the primary WPA2 VAP.
I do note t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #198 from Cy Schubert ---
I think what is needed is to remove the IE, similar to what replace_ie() does
except to just remove it.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #199 from J.R. Oldroyd ---
I'm not sure what exactly you mean by that.
But, in answer to my own question in comment #193, it looks like I now also
need to check for wpa_bss_get_vendor_ie WPA_IE_VENDOR_TYPE in order to know if
W
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
J.R. Oldroyd changed:
What|Removed |Added
Attachment #235051|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #201 from Cy Schubert ---
(In reply to J.R. Oldroyd from comment #200)
Good work! Works perfectly.
Ideally this should be done outside of the driver, but, we're in a bit of a
time crunch. This should move ahead. We can post th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #202 from Cy Schubert ---
Proposed commit log message:
Author: J.R. Oldroyd
AuthorDate: Sat Jul 2 11:15:31 2022 -0700
Commit: Cy Schubert
CommitDate: Sun Jul 3 09:15:15 2022 -0700
wpa_supplicant: Resolve secondar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #203 from Bjoern A. Zeeb ---
(In reply to Cy Schubert from comment #202)
I think this is highly suggestive and I am not sure other drivers would have
similar problems due to the other nature of the 802.11 stack.
Also avoid "I"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
J.R. Oldroyd changed:
What|Removed |Added
Attachment #235053|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #205 from J.R. Oldroyd ---
FWIW, I have been testing using the iwm(4) driver.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #206 from Cy Schubert ---
I took a look at the Red Hat bugzilla to attempt to duplicate it here.
Primary VAP is WPA2 RSN AES, secondary VAP is OPEN: works with the secondary
VAP.
Primary VAP is WPA2 RSN AES, secondary VAP is W
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #207 from Cy Schubert ---
Tested with WEP.
Comparing this with an archlinux driver_nl80211 IE bugfix, applying the patch
to driver_bsd is appropriate.
--
You are receiving this mail because:
You are on the CC list for the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #208 from groenv...@acm.org ---
(In reply to J.R. Oldroyd from comment #200)
Patch applied against security/wpa_supplicant-devel
and worked with Marriott_Lobby:
# sysrc wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
# s
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #209 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=775611ea11db0973fd8b7aef0f5eb527308efd05
commit 775611ea11db0973fd8b7aef0f5eb527308efd05
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #210 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=b3916c7a8d2599e99fabdc1735b095ff5a9f9381
commit b3916c7a8d2599e99fabdc1735b095ff5a9f9381
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #211 from Jaskie ---
(In reply to J.R. Oldroyd from comment #204)
Sadly, it does not seem work for me. This is what I did:
# cd /usr/src
# git reset --hard release/13.1.0
# patch -C -p1 < ~adam/235055.patch && patch -C -p1 <
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #212 from Cy Schubert ---
(In reply to Jaskie from comment #211)
patch -C only checks the patch. And running patch -C twice checks it twice. It
doesn't install the patch.
cd /usr/src
git apply /some/patch/file
The make obj an
401 - 500 of 2545 matches
Mail list logo
