https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #25 from Jaskie ---
I did this steps in both 13.0 and 13.1:
% doas service netif stop wlan0
% doas mv /var/db/dhclient.leases.wlan0{,.bak}
% doas service netif start wlan0
% doas tcpdump -i wlan0 -w OUT.bpf -s 0
% doas ifconfi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Bjoern A. Zeeb changed:
What|Removed |Added
Status|New |Open
--- Comment #27 from Bjoern
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #26 from Bjoern A. Zeeb ---
(In reply to Jaskie from comment #25)
when looking at the first dicover packets between 13.0 and 13.1 I see no
obvious differences:
% diff -up dhcp-discover-13.*.txt
--- dhcp-discover-13.0.txt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #28 from J.R. Oldroyd ---
The ARPs from the router are almost certainly due to the previous good 13.0
boot.
I also see (using tcpdump and tshark) that the DHCPDISCOVER datagrams are the
same between the 13.0 and 13.1 files.
If
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #29 from J.R. Oldroyd ---
The other obvious thing to check is, is the network working when configured
manually?
Use the same values you get from the 13.0 boot for the IP and router. Then
boot under 13.1 and configure manually:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #30 from Jaskie ---
I followed all your suggestions and did the tests below with a fresh biot 13.1,
dhclient cache was removed beforehand:
# ifconfig wlan0 10.134.138.51 netmask 255.255.128.0
# route add default 10.134.255.254
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #31 from J.R. Oldroyd ---
(In reply to Jaskie from comment #30)
I notice you're associated again with the bssid which requires WPA auth:
ssid WHU-STU channel 5 (2432 MHz 11g ht/20) bssid 70:d9:31:0e:2c:00
regdomain 96 i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #32 from Jaskie ---
(In reply to J.R. Oldroyd from comment #31)
I would not say this is a problem. As I mentioned in my last reply,
/etc/rc.conf, /etc/wpa_supplicant.conf and /etc/sysctl.conf are identical
between 13.0 and 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #34 from Jaskie ---
(In reply to Jaskie from comment #32)
Network is still down if I omit bssid or assign bssid=fc:b6:98:f6:12:80 for it.
On the other hand, the laptop was left on all day after arp -d and still
nothing. I thin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #35 from Jaskie ---
(In reply to Bjoern A. Zeeb from comment #33)
I assigned bssid=fc:b6:98:f6:12:80 in /etc/wpa_supplicant.conf again, made sure
it worked in 13.0. And below are terminal inputs (% as PS1) and outputs in
13.1:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #33 from Bjoern A. Zeeb ---
(In reply to Jaskie from comment #32)
After failure check the last 100 lines (or whatever is reasonable based on
timestamp) of the ls -lart /var/log logfiles messages probably mostly; see
if there
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #36 from Jaskie ---
I followed suggestion from J.R. Oldroyd and copied /usr/sbin/wpa_supplicant
from 13.0-p11 to 13.1 and network is finally working! Should this bug report be
re-assigned?
--
You are receiving this mail becaus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Bjoern A. Zeeb changed:
What|Removed |Added
Summary|WiFi stops working after|WiFi stops working after
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #37 from rkober...@gmail.com ---
I am surprised to see this issue as the initial message showed both 13.1 and
13.0 to be associated with an SSID "WHU-STU". I should have looked more closely
as I missed that they are the same SSID
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #38 from rkober...@gmail.com ---
BTW, this appears to have nothing specifically to do with the AR9285. It is
likely fundamental to the wpa supplicant when dealing with a some modern APs.
In my case, I was seeing it on an Intel AX
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 #39 from Cy Schubert ---
Created attachment 234478
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234478&action=edit
Correctly call pcap_next_ex
This patch failed to make it into 13.1-RELEASE and fixes the problem.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #40 from Cy Schubert ---
I suggest we add the patch to releng/13.1 and publish an errata.
--
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
Cy Schubert changed:
What|Removed |Added
Assignee|c...@freebsd.org |rel...@freebsd.org
--- Comment #41
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #42 from Jaskie ---
Unfortunately the fixntou mentioned doesn't seem to solve my issue. I followed
J.R. Oldroyd's guide and did the following test by compiling WPA:
cd /usr/src
git clone https://git.freebsd.org/src.git .
git s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Assignee|rel...@freebsd.org |c...@freebsd.org
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Severity|Affects Some People |Affects Many People
--
You are rece
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Attachment #234478|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #44 from Jaskie ---
(In reply to Cy Schubert from comment #43)
I am sorry I am having some trouble testing the two patches. I am not very
familiar with the process of applying patches from different branches. However
I followed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Assignee|c...@freebsd.org |rel...@freebsd.org
--- Comment #45
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #46 from Jaskie ---
(In reply to Cy Schubert from comment #45)
Do I need only one patch? I thought I needed two, but I didn't figure out where
t find them and how to apply and verify the expected change.
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #47 from Jaskie ---
(In reply to Cy Schubert from comment #45)
So I finally tested the patch you mentioned with the help of J.R. Oldroyd by
git cherry-picking. Well, it didn't work either. This is what I did:
cd /usr/src/
git
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #48 from Cy Schubert ---
(In reply to Jaskie from comment #35)
Looking at these messages, wpa_supplicant has associated with the AP.
Can you try an experiment, please.
When this condition occurs,
ifconfig wlan0 -- and record
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #49 from Jaskie ---
(In reply to Cy Schubert from comment #48)
This is all the output:
# doas service netif start wlan0
# ifocnfig wlan0
wlan0: flags=8843 metric 0 mtu 1500
ether 1c:4b:d6:ca:3e:ac
inet 0.0.0.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Assignee|rel...@freebsd.org |wireless@FreeBSD.org
--- Comment #50
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #51 from rkober...@gmail.com ---
The main indicator of the problem is that the mode is set to the rather
unlikely value of DS/1Mb. This has only been reported on attempts to connect to
public access APs. In one case I believe tha
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #52 from Jaskie ---
(In reply to rkoberman from comment #51)
Yes, it is indeed a campus network I am working with.
And I already did a bisect, see comment 44 in this PR for details.
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Assignee|wireless@FreeBSD.org|c...@freebsd.org
--- Comment #53 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #54 from Cy Schubert ---
For anyone following on, the ioctl sent to wlan0 has an op of -1. The SIGABRT
core dump will allow me to follow the stack to the routine that sets op to -1,
hence the invalid argument.
--
You are recei
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 #55 from Cy Schubert ---
As per our private email thread, were you able to run the wpa_supplicant
provided that will produce a core dump?
--
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 #56 from Cy Schubert ---
The current theory is that wpa_supplicant doesn't work with newer Atheros
NICs/driver. The SIGABRT core dump will tell us where in the stack the bad
argument to ioctl() is generating the bad argument. Th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #57 from Adrian Chadd ---
... I don't think the AR9285 stuff has changed in a long time. And most of the
ioctls are handed by net80211 first.
Do you need me to jump in and dig into it a bit more? Or are y'all ok?
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #58 from Jaskie ---
(In reply to Adrian Chadd from comment #57)
By all means, jupm in please. I am currently trying to get a coredump file
using the wpa Cy Schubert provided. I have in /etc/sysctl.conf:
kern.corefile=/var/core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #59 from J.R. Oldroyd ---
One additional data point.
I am now at a location with a laptop with an AR9280 chip. I just did a 13.1
upgrade on it.
This one associates just fine with the hostap here, Ethernet MCS mode 11ng.
I re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #60 from Cy Schubert ---
Considering you can't get a dump, let's see if the ath(4) driver can give us a
hint.
Run this DTrace script prior to starting wlan0.
#!/usr/sbin/dtrace -s
fbt::ath_ioctl:entry {
print(*args[0]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #61 from Adrian Chadd ---
hey wait a sec, I'm seeing different configurations between wpa-supplicant on
13.0 and 13.1. (ie, out of ifconfig.)
the fact ifconfig isn't saying MANUAL for roam is a big red flag to me. One of
the th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #62 from Bjoern A. Zeeb ---
(In reply to Adrian Chadd from comment #61)
Why don't you read a bit backwards; around comment #44 would tell you.
--
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 #63 from Adrian Chadd ---
Ok, it really does look like incomplete testing. :(
Please compile the kernel w/:
IEEE80211_DEBUG
ATH_DEBUG
AH_DEBUG
ATH_DIAGAPI
... I think that should be enough to get all the good debugging that y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #64 from Bjoern A. Zeeb ---
(In reply to Adrian Chadd from comment #63)
Again, I think it might be good to remind people that the kernel was ruled out
given an 13.0 user land on a 13.1 kernel works just fine if I understand the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #65 from Adrian Chadd ---
Yes, I think it's more likely some ioctl ordering or contents issue. Doing
net80211 debugging though may shed some light on what's being done.
(I'd stick a dtrace rule on the net80211 ioctl handle, not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #66 from Cy Schubert ---
That's why I asked for a DTrace. The user is unable to capture a dump using the
file I gave her that would force wpa_supplicant to dump with the error. There
are three different calls to the function tha
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #67 from Cy Schubert ---
wpa_driver_bsd_scan() calls set80211param() to set IEEE80211_IOC_ROAMING to
IEEE80211_ROAMING_MANUAL immediately after setting mediaopt to STA. This is
unconditional and if it fails it will issue a messa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #68 from Cy Schubert ---
The ioctl() error is likely due to bsd_del_key().
Can you please add -dd to wpa_supplicant_flags= in rc.conf. Then grep
wpa_supplicant /var/log/messages.
--
You are receiving this mail because:
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #69 from Jaskie ---
Created attachment 234669
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234669&action=edit
dtrace output
--
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 #70 from Jaskie ---
(In reply to Jaskie from comment #69)
I am using the wpa Cy Schubert prvided in this test. wpa_supplicant_flags="-dd"
was added to rc.conf.
# service netif start
Created wlan(4) interfaces: wlan0.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #71 from Cy Schubert ---
#1. I still don't understand why your system will not produce a core dump on
abort():
- what does sysctl kern.coredump say?
- what is ullimit -c?
- what is df -h /?
#2. Add priority=100, or give it a h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #72 from Jaskie ---
(In reply to Cy Schubert from comment #71)
sysctl kern.coredump reports 1
ulimit -c reports unlimited
df -h / shows there is 200G+ free space
priority=100 was added to WHU-STU block
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #73 from Cy Schubert ---
And...
--
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 #74 from Jaskie ---
Created attachment 234682
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234682&action=edit
dtrace out2
--
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 #75 from Jaskie ---
(In reply to Cy Schubert from comment #73)
Not much difference I noticed:
# service netif start
Starting wpa_supplicant.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #76 from Cy Schubert ---
DTrace output doesn't help anymore because DTrace won't dereference a pointer
to void *.
--
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 #77 from Jaskie ---
(In reply to Cy Schubert from comment #76)
But I didn't get any coredump files
# sysctl kern.corefile
kern.corefile: /var/coredumps/%U/%N.core
# sysctl kern.coredump
kern.coredump: 1
However, /var/coredump
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #78 from Bjoern A. Zeeb ---
(In reply to Jaskie from comment #77)
Try changing:
kern.corefile: /var/coredumps/%U/%N.core
to
sysctl kern.corefile="/var/coredumps/%U-%N.core"
to avoid problems with another subdir maybe?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #79 from Cy Schubert ---
ls -lh /var/coredumps, please.
--
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 #80 from Cy Schubert ---
(In reply to Bjoern A. Zeeb from comment #78)
My point exactly. /var/coredumps/0 probably does not exist and the kernel will
not create the directory. It will simply bail. I think she's trying to
duplic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #81 from Jaskie ---
Created attachment 234695
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234695&action=edit
coredump from wpa_supplicant
--
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 #82 from Jaskie ---
(In reply to Bjoern A. Zeeb from comment #78)
yes yes yes exactly. I changed this and get the coredump file. I've uploaded it
in attachment. Thanks! hope this helps.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264675
Bug ID: 264675
Summary: Wirless
Product: Base System
Version: 13.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264675
Kubilay Kocak changed:
What|Removed |Added
Severity|Affects Many People |Affects Only Me
Summary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #83 from Cy Schubert ---
This could be a timing issue. Can you please add the following to rc.conf,
synchronous_dhclient="YES"
--
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 #84 from Jaskie ---
(In reply to Cy Schubert from comment #83)
I added synchronous_dhclient="YES" to /etc/rc/conf, copied wpa_supplicant v2.10
in place, network was not working. dt_out2.txt.xz is uploaded as attachment.
# serv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #85 from Jaskie ---
Created attachment 234745
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234745&action=edit
dtrace from wpa v2.10
dtrace from wpa v2.10
synchronous_dhclient="YES"
wpa_supplicant_flags="-dd"
--
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #86 from Cy Schubert ---
We don't need anymore dtrace listings.
I assume it also worked with wpa_supplicant 2.10 on 13.1.
--
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
Cy Schubert changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #88 from Adrian Chadd ---
wait a sec, before you close it, was the actual crash in wpa_supplicant
resolved?
--
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 #89 from Cy Schubert ---
Apparently so.
--
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
Cy Schubert changed:
What|Removed |Added
Status|Closed |Open
Resolution|FIXED
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #91 from Jaskie ---
(In reply to Cy Schubert from comment #90)
No, it was NOT WORKING. I would've mentioned if it was fixed after adding
synchronous_dhclient="YES".
The only thing changed as I noticed was that now wlan0 claimed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #92 from Cy Schubert ---
After it fails, please run,
# killall dhclient
# dhclient wlan0
Also, does your rc.conf contain, ifconfig_wlan0="WPA DHCP" ?
--
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 #93 from Jaskie ---
(In reply to Cy Schubert from comment #92)
Yes, I have the line in /etc/rc.conf:
# grep wlan0 /etc/rc.conf
wlans_ath0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
#ifconfig_wlan0="WPA DHCP"
I tried both SYNCDHCP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #94 from Cy Schubert ---
What other entries are in your wpa_supplicant.conf?
Appears it's associated with authmode OPEN privacy OFF under wpa_supplicant 2.9
while authmode WPA privacy MIXED deftxkey UNDEF under wpa_supplicant 2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #95 from Jaskie ---
(In reply to Cy Schubert from comment #94)
I posted the content of /etc/wpa_supplicant.conf earlier and didn't made much
change since that:
network={
ssid="WHU-WLAN"
key_mgmt=NONE
}
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #96 from Adrian Chadd ---
hm, if this affects multiple people, should we consider rolling back wpa_s
until we can figure out what's up?
--
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 #97 from Cy Schubert ---
(In reply to Adrian Chadd from comment #96)
I'm preparing a wpa_supplicant29 port.
Reverting would cause too much churn. Though I may consider reverting only 12
and 13. Reverting would also remove supp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #98 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=7150a0c9b1014e445a8266c9080d0bf4738dcc9c
commit 7150a0c9b1014e445a8266c9080d0bf4738dcc9c
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #99 from rkober...@gmail.com ---
Once again, while the title refers to the AR9285, I am seeing the same symptoms
on my AX200. Unfortunately, since it seems to only affect connection to OPEN
access points, I only see this on the i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #100 from Adrian Chadd ---
when you're down there, can you do an "ifconfig -v wlan0 list scan", or
"ifconfig wlan0 -v list scan" (I forget which), and "ifconfig -v wlan0" to get
a full dump of the scan data and the NIC state? Th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #101 from Cy Schubert ---
Using my iwn(4) connected to one of my networks (now open) and reconfigured my
laptop to remove wlan0 from lagg0:
wlan0: flags=8843 metric 0 mtu 1500
ether xx:xx:xx:xx:xx:xx
inet6 fe80:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #102 from Cy Schubert ---
I've been able to reproduce this problem with rtwn(4).
My iwn(4) works with open networks.
My ath(4) fails to scan anything, even in single user, suggesting that either
the NIC no longer works or ther
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 #103 from rkober...@gmail.com ---
(In reply to Cy Schubert from comment #102)
Just to confirm, my urtwn fob also fails in the same manner with 13.1 and
worked fine with 13.0. I'll have my urtwn with me when I do testing, almost
c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #104 from Cy Schubert ---
Created attachment 234801
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234801&action=edit
Revert driver_bsd.c from wpa 2.10 back to 2.9
Can you try this patch?
To apply,
cd /usr/src
git
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #105 from Cy Schubert ---
Created attachment 234807
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234807&action=edit
A better patch
This patch will bring us closer.
This resolves connecting to an open unprotected 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
Cy Schubert changed:
What|Removed |Added
Summary|WiFi stops working after|wpa_supplicant fails to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #106 from Jaskie ---
(In reply to Cy Schubert from comment #105)
OK. I applied this patch (A better patch), compiled & installed wpa and tested.
WiFi still not working.
# ifconfig -v wlan0 list scan |grep WHU-STU
WHU-STU
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #107 from Jaskie ---
Created attachment 234808
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234808&action=edit
wpa out
Output from /usr/sbin/wpa_supplicant -dd -i wlan0 -c /etc/wpa_supplicant.conf
-D bsd
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #108 from Cy Schubert ---
Can you apply the latest patch first, then run the scan again. That patch was
in the FreeBSD copy of 2.9 but not in 2.10.
To make it easier to capture the output, run this:
/usr/sbin/wpa_supplicant -d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #110 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=05a849eec9d949b3de32e464570cefbabcd64702
commit 05a849eec9d949b3de32e464570cefbabcd64702
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #109 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3b2956781048f300c081952150d515573a274620
commit 3b2956781048f300c081952150d515573a274620
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #111 from commit-h...@freebsd.org ---
A commit in branch 2022Q2 references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=52efc7630680ad1445bf062b25d1f868e26e4d0d
commit 52efc7630680ad1445bf062b25d1f868e26e4d0d
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #112 from commit-h...@freebsd.org ---
A commit in branch 2022Q2 references this bug:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=c82d2efea691ec4d8eac6a875eb0fe182106bf99
commit c82d2efea691ec4d8eac6a875eb0fe182106bf99
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #113 from Jaskie ---
(In reply to Cy Schubert from comment #108)
(In reply to Cy Schubert from comment #108)
Sorry I don't really understand what you mean by "apply the latest patch
first". So I did the following test:
1. Dow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #114 from Jaskie ---
Created attachment 234816
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234816&action=edit
wpa out p1
--
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 #115 from rkober...@gmail.com ---
(In reply to Cy Schubert from comment #105)
I'm about to rebuild with the latest wps_supplicant. Just to clarify, does this
refer to connecting to an AP supporting 11n or the supplicant attemptin
301 - 400 of 2545 matches
Mail list logo
