Re: Atheros 5418, client drops connection after some time with N
On Sat, 2017-02-04 at 11:12 -0800, Adrian Chadd wrote: > thanks! please do update and let me know. Solved. Updating both endpoints to the latest CURRENT helped. Thank you sir! signature.asc Description: This is a digitally signed message part
Re: Atheros 5418, client drops connection after some time with N
On Sat, 2017-02-04 at 10:57 -0800, Adrian Chadd wrote: > ok, so far it indeed looks like a block-ack window issue. Which is > weird, because i thought I had fixed all the transmit block-ack > window > stuff a looong time ago :( > > Oh, can you please update to the very latest -HEAD? I only recently > just fixed some multicast / queue handling issues which may fix your > issues. It needs to be done on both the STA and AP side. HOST: #0 8c2c935f91a(master)-dirty: Sun Jan 29 17:19:08 EET 2017 AP : #0 82a993254a9(master): Mon Jan 23 11:46:09 EET 2017 I'll update anyway and give feedback. signature.asc Description: This is a digitally signed message part
Re: Atheros 5418, client drops connection after some time with N
On Sat, 2017-02-04 at 09:48 -0800, Adrian Chadd wrote: > ugh, uhm, redo this on the client and AP side, and include "wlandebug > +crypto +11n" too. > > thx, Just with +crypto+11n or with input+scan+assoc+elemid+node+output+inact+roam+rate++crypto+11n I'm doing with second now it's still working for now. signature.asc Description: This is a digitally signed message part
Re: Atheros 5418, client drops connection after some time with N
AP: http://pasted.co/89e8eb3b The fall happened around this time: Sat 4 Feb 2017 19:32:04 EET signature.asc Description: This is a digitally signed message part
Re: Atheros 5418, client drops connection after some time with N
On Sat, 2017-02-04 at 09:17 -0800, Adrian Chadd wrote: > hi, > > can you do the AP side at the same time please? > > > -a Sure, give me 10 minutes. signature.asc Description: This is a digitally signed message part
Re: Atheros 5418, client drops connection after some time with N
http://pasted.co/3664ad20 There it is. Nope, it's the log from the client which fails. On Sat, 2017-02-04 at 08:54 -0800, Adrian Chadd wrote: > hiya, > > hm! attachments are stripped. can you please put it up somewhere for > download? > > Is that log from the AP side? > > > > -adrian > > > On 4 February 2017 at 06:34, clutton <clut...@zoho.com> wrote: > > > > Hi list. > > > > The hosts are CURRENT both AP and client, after some time of usage > > client (my laptop) becomes deaf. > > tcpdump from AP shows that packets are received and transmitted > > back, > > but on client tcpdump doesn't show receiving. arping doesn't work > > too. > > ifconfig shows "status: associated" anyway. > > > > I don't have any wifi encryption, I use OPEN with IPSEC, but > > without > > IPSEC the situation is the same. > > > > What else, ifconfig down/up solves the issue, and with ifconfig -ht > > everything works well. Need more info - ask. > > > > The log attached is produced with: > > _ wlandebug input+scan+assoc+elemid+node+output+inact+roam+rate > > > > client's dmesg: > > ath0: mem 0xdf3f-0xdf3f irq 17 at device 0.0 > > on > > pci2 > > ath0: [HT] enabling HT modes > > ath0: [HT] RTS aggregates limited to 8 KiB > > ath0: [HT] 2 RX streams; 2 TX streams > > ath0: AR5418 mac 12.10 RF5133 phy 8.1 > > ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 > > > > P.S. I must be cursed, since I send few emails with debug > > attachment > > and none of them passed to list. signature.asc Description: This is a digitally signed message part
Atheros 5418, client drops connection after some time with N
Hi list. The hosts are CURRENT both AP and client, after some time of usage client (my laptop) becomes deaf. tcpdump from AP shows that packets are received and transmitted back, but on client tcpdump doesn't show receiving. arping doesn't work too. ifconfig shows "status: associated" anyway. I don't have any wifi encryption, I use OPEN with IPSEC, but without IPSEC the situation is the same. What else, ifconfig down/up solves the issue, and with ifconfig -ht everything works well. Need more info - ask. The log attached is produced with: _ wlandebug input+scan+assoc+elemid+node+output+inact+roam+rate client's dmesg: ath0: mem 0xdf3f-0xdf3f irq 17 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] RTS aggregates limited to 8 KiB ath0: [HT] 2 RX streams; 2 TX streams ath0: AR5418 mac 12.10 RF5133 phy 8.1 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 P.S. I must be cursed, since I send few emails with debug attachment and none of them passed to list. signature.asc Description: This is a digitally signed message part
Re: pcap_inject() ruins my handmade packets
On Thu, 2014-10-23 at 17:32 -0700, Adrian Chadd wrote: Which version of FreeBSD are you using? I only recently fixed raw frame injection in monitor mode in FreeBSD-11. How are you trying to do raw frame injection? -adrian Any ideas? Why this doesn't work for me using pcap and works using sockets? https://www.kernel.org/doc/Documentation/networking/mac80211-injection.txt As I understand monitor mode can be used for injections now, is it right? As I remember some discussion here (a long time ago) said that the monitor mode is for monitoring :) and people should use other modes for injections. But since new pcap API was introduced, we can see that the monitor mode is not only for monitoring. On 23 October 2014 17:21, clutton clut...@zoho.com wrote: Hi list. I'm porting a Linux application [reaver], and have a tough time figuring out what is wrong. The way how Linux users use it doesn't work I mean building packet like radiotap_header+frame+payload and use pcap_inject() for injections. Nevertheless, using the same packets with sockets work like a charm. Since I didn't find any working example with packet injections conjugates with pcap_inject for FreeBSD, I starting think it doesn't work on FreeBSD platform. Right now, I started using LD_PRELOAD with my own version of libpcap, because after end of day it uses write(), but why it is ruins my packets is not obvious for me yet. May be somebody could explain me? May be it's well known not fixable bug, and I'm just wasting my time. I really want to do this using libpcap! Using sockets is quicker approach for me, but you know, fixing libpcap will bring a lot of others apps to FreeBSD realm. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
pcap_inject() ruins my handmade packets
Hi list. I'm porting a Linux application [reaver], and have a tough time figuring out what is wrong. The way how Linux users use it doesn't work I mean building packet like radiotap_header+frame+payload and use pcap_inject() for injections. Nevertheless, using the same packets with sockets work like a charm. Since I didn't find any working example with packet injections conjugates with pcap_inject for FreeBSD, I starting think it doesn't work on FreeBSD platform. Right now, I started using LD_PRELOAD with my own version of libpcap, because after end of day it uses write(), but why it is ruins my packets is not obvious for me yet. May be somebody could explain me? May be it's well known not fixable bug, and I'm just wasting my time. I really want to do this using libpcap! Using sockets is quicker approach for me, but you know, fixing libpcap will bring a lot of others apps to FreeBSD realm. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: pcap_inject() ruins my handmade packets
On Thu, 2014-10-23 at 17:32 -0700, Adrian Chadd wrote: Which version of FreeBSD are you using? I only recently fixed raw frame injection in monitor mode in FreeBSD-11. How are you trying to do raw frame injection? -adrian HEAD, but I didn't update it more then month. I'm not using monitor mode, just ordinary one when I'm connected to AP, and ahdemo. Seems raw write works with both types well, and pcap_inject() doesn't. The scenario is that: handle = pcap_open_live(dev, BUFSIZ, 1, 0, errbuf); // tried without promisk, didn't help pcap_set_datalink(handle, DLT_IEEE802_11_RADIO); // I've tried others datalinks, and also skipping setting this like Linux users do, changing datalink here changes the way how packet is corrupted BUILD_PACKET_STEP() pcap_inject(handle, packet, packet_len); ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: service netif restart [iface] runs a wpa_supplicant twice
On Tue, 2013-11-12 at 13:54 -0500, John Baldwin wrote: Guys, it still doesn't work. Two days ago, when I changed my AP setup, in rc.conf and then run «sudo service netif restart» I'd observed two copies of the wpa_supplicant. System is CURRENT b9061d4, I can't see the pgrep patch on it... ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: service netif restart [iface] runs a wpa_supplicant twice
On Wed, 2013-11-06 at 11:59 -0500, John Baldwin wrote:
On Tuesday, November 05, 2013 5:17:30 pm John Baldwin wrote:
On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote:
On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin j...@freebsd.org wrote:
On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote:
On 2 November 2013 12:13, clutton clut...@zoho.com wrote:
[snip]
What was happened? netif tries to setup wlan0 (clone, wpa, dhcp,
etc),
when wlan0 interface occurs, devd runs another copy of netif.
Well, it sounds like we need to pick an architecture _and_ fix the
behaviour here.
Which is:
* I think wpa-supplicant should always run if it's required in
/etc/rc.conf;
* netif should check if devd is configured and if so, just leave the
configuration up to devd
* if it isn't running, then devd should be responsible for
dhclient/add-to-wpa-config
What we first have to establish is whether add_interface and
remove_interface (or whatever they're called) are correctly working,
for ethernet and wifi driver types. Then, we need to ensure they can
coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers
loaded and active on their relevant interfaces.) _then_ we can break
out the stuff devd does out of netif and have _either_ netif (x)or
devd call this new script to setup/teardown the interface runtime
state.
How's that sound?
Note that devd just runs netif (via /etc/pccard_ether), so it's already
just one script, and having netif bail if devd is running would make
netif not do anything in the common case.
What normally happens during boot is that '/etc/rc.d/netif start'
creates
wlan0 and runs wpa_supplicant via 'childif_create' making a nested call
to
ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif
explicitly after it creates the device. Probably that is what should be
removed. That would let devd always start wpa_supplicant via
/etc/pccard_ether. I've just tested this by doing a stop/start on iwn0
(parent of wlan0, so wlan0 gets destroyed and re-created) and it started
wpa_supplicant correctly.
Index: head/etc/network.subr
===
--- network.subr(revision 257705)
+++ network.subr(working copy)
@@ -1429,9 +1429,6 @@ childif_create()
fi
${IFCONFIG_CMD} $i name $child cfg=0
fi
- if autoif $child; then
- ifn_start $child
- fi
done
# Create vlan interfaces
I also tested vlans created via vlans_if and they should use the same
fix as
well. Note that this model is more consistent with how
cloned_interfaces
works where ifn_start is not explicitly run when each interface is
created.
Instead, we rely on devd kicking off pccard_ether for those as well.
That looks sane too me.
Just one question, I remember that devd is disabled during boot and
activated later through a sysctl (to ignore events entirely), is this
the case before or after netif is running? I guess it is activated
after netif, otherwise we would have seen this issue on booting and
not just during netif restart.
Hmm, devd starts after netif, but it just worked fine for me when I booted
up.
I also misspoke about cloned_interfaces. We manually add the
cloned_interface
list to the list of interfaces /etc/rc.d/netif iterates over. What I am
puzzled by is that this just worked for me during a test boot. Hmm, it
looks like
devctl is no longer disabled during boot and then explicitly enabled by
devd.
devctl is now always enabled during boot, but capped at 1000 entries to
avoid
leaking memory. In fact, it looks like devd tries to recreate a few
interfaces
after netif finishes and is generally confused. I tried again with
devd_flags
set to -n to flush the initial set of events on boot. This removed the
multiple calls to netif on boot on my laptop, but somehow wpa_supplicant is
still being started by devd (and I'm not sure how now).
I've hacked devd some more and can now see what is going on. -n doesn't do
what
I thought it does. It does not throw away pending events on startup, it just
makes devd not fork until it has walked the initial set of events. The kernel
changed (a while ago) to queue the first 1000 events until devd starts up.
This
means that in practice devd gets arrival events for all devices in the system
as
soon as it starts up and triggers duplicate invocations of netif after netif
finishes. However, /etc/pccard_ether ignores attempts to start a device that
is already up, so this should be a no-op on bootup (if my change
Re: service netif restart [iface] runs a wpa_supplicant twice
On Fri, 2013-11-01 at 23:50 -0700, Adrian Chadd wrote:
OK, so where's the other path for invoking wpa_supplicant?
-a
On 1 November 2013 13:35, clutton clut...@zoho.com wrote:
On Fri, 2013-11-01 at 13:02 -0700, Adrian Chadd wrote:
What's running the other copy?
Adrian
On Nov 1, 2013 4:00 PM, clutton clut...@zoho.com wrote:
On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote:
On 1 November 2013 12:16, Bernhard Schmidt
bschm...@techwires.net wrote:
That actually is a design question I once wrapped my head
around
unsuccessfully. The lines above are responsible for
configuring wlan0
if it is created, eg.
ifconfig wlan0 destroy
ifconfig wlan0 create wlandev ath0
will invoke above code which will then invoke
pccard_ether. Changing
the code as you intent to will prevent this.
Someone should step up an decide what is supposed to
happen, should
wlan0 in that case be configured as stated in rc.conf, or
not?
The actual issue though, is in wpa_supplicant itself. It
has code to
prevent it being started twice, but that doesn't kick in
because the
instances are started to fast and we loose (have not yet
setup enough)
information in our net code.
Uhm, I'm confused by this. Would you mind explaining it in a
bit more detail?
-a
The devd runs a pccard_ether script when the IFNET interface
appears.
In some rare cases you can see two copies of the
wpa_sopplicant.
devd:
notify 0 {
match system IFNET;
match subsystem !usbus[0-9]+;
match typeATTACH;
action /etc/pccard_ether $subsystem start;
};
What do you mean?
signature.asc
Description: This is a digitally signed message part
Re: service netif restart [iface] runs a wpa_supplicant twice
On Wed, 2013-10-23 at 21:43 -0700, Adrian Chadd wrote:
IT's not. It's devd doing something dumb.
-a
On 23 October 2013 21:30, clutton clut...@zoho.com wrote:
Indeed.
I have looked at a sys/net80211 and at a sys/dev/ath.
But I still have no idea which one triggers rc script and how on the
earth it can be done.
On Wed, 2013-10-23 at 16:57 -0700, Adrian Chadd wrote:
. that needs to be fixed. It definitely shouldn't be started twice!
-adrian
On 23 October 2013 16:56, clutton clut...@zoho.com wrote:
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the
wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant
twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the
/etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Yes, it's not a bug, just misconfigured devd.
Here the patch:
Ξ ~ → diff -u /usr/src/etc/devd.conf /etc/devd.conf
--- /usr/src/etc/devd.conf 2013-09-29 17:24:16.759250174 +0300
+++ /etc/devd.conf 2013-11-01 10:52:02.731746832 +0200
@@ -38,7 +38,7 @@
#
notify 0 {
match system IFNET;
- match subsystem !usbus[0-9]+;
+ match subsystem !(usbus|wlan)[0-9]+;
match typeATTACH;
action /etc/pccard_ether $subsystem start;
};
zsh: exit 1 diff -u /usr/src/etc/devd.conf /etc/devd.conf
↑1 ~ →
Is it good enough? Should I make an pr?
I believe that the wlan iface may be avoided and all cases, am I wrong?
signature.asc
Description: This is a digitally signed message part
Re: service netif restart [iface] runs a wpa_supplicant twice
On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote: On 1 November 2013 12:16, Bernhard Schmidt bschm...@techwires.net wrote: That actually is a design question I once wrapped my head around unsuccessfully. The lines above are responsible for configuring wlan0 if it is created, eg. ifconfig wlan0 destroy ifconfig wlan0 create wlandev ath0 will invoke above code which will then invoke pccard_ether. Changing the code as you intent to will prevent this. Someone should step up an decide what is supposed to happen, should wlan0 in that case be configured as stated in rc.conf, or not? The actual issue though, is in wpa_supplicant itself. It has code to prevent it being started twice, but that doesn't kick in because the instances are started to fast and we loose (have not yet setup enough) information in our net code. Uhm, I'm confused by this. Would you mind explaining it in a bit more detail? -a The devd runs a pccard_ether script when the IFNET interface appears. In some rare cases you can see two copies of the wpa_sopplicant. signature.asc Description: This is a digitally signed message part
Re: service netif restart [iface] runs a wpa_supplicant twice
On Fri, 2013-11-01 at 20:16 +0100, Bernhard Schmidt wrote:
On Fri, Nov 1, 2013 at 7:40 PM, clutton clut...@zoho.com wrote:
On Wed, 2013-10-23 at 21:43 -0700, Adrian Chadd wrote:
IT's not. It's devd doing something dumb.
-a
On 23 October 2013 21:30, clutton clut...@zoho.com wrote:
Indeed.
I have looked at a sys/net80211 and at a sys/dev/ath.
But I still have no idea which one triggers rc script and how on the
earth it can be done.
On Wed, 2013-10-23 at 16:57 -0700, Adrian Chadd wrote:
. that needs to be fixed. It definitely shouldn't be started twice!
-adrian
On 23 October 2013 16:56, clutton clut...@zoho.com wrote:
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the
wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant
twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the
/etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Yes, it's not a bug, just misconfigured devd.
Here the patch:
Ξ ~ → diff -u /usr/src/etc/devd.conf /etc/devd.conf
--- /usr/src/etc/devd.conf 2013-09-29 17:24:16.759250174 +0300
+++ /etc/devd.conf 2013-11-01 10:52:02.731746832 +0200
@@ -38,7 +38,7 @@
#
notify 0 {
match system IFNET;
- match subsystem !usbus[0-9]+;
+ match subsystem !(usbus|wlan)[0-9]+;
match typeATTACH;
action /etc/pccard_ether $subsystem start;
};
zsh: exit 1 diff -u /usr/src/etc/devd.conf /etc/devd.conf
↑1 ~ →
Is it good enough? Should I make an pr?
I believe that the wlan iface may be avoided and all cases, am I wrong?
That actually is a design question I once wrapped my head around
unsuccessfully. The lines above are responsible for configuring wlan0
if it is created, eg.
ifconfig wlan0 destroy
ifconfig wlan0 create wlandev ath0
will invoke above code which will then invoke pccard_ether. Changing
the code as you intent to will prevent this.
Someone should step up an decide what is supposed to happen, should
wlan0 in that case be configured as stated in rc.conf, or not?
The actual issue though, is in wpa_supplicant itself. It has code to
prevent it being started twice, but that doesn't kick in because the
instances are started to fast and we loose (have not yet setup enough)
information in our net code.
--
Bernhard
At least it shouldn't call the pccard_ether. My wifi card is not the
pccard nor the ether card :). Here we have an old design + a new
implementation of wlan devices.
And yes, it occurs that the FreeBSD has some kind of a NetworkManager.
In my view it should be optional, because rc.d scripts is mandatory
anyway.
signature.asc
Description: This is a digitally signed message part
Re: service netif restart [iface] runs a wpa_supplicant twice
On Fri, 2013-11-01 at 13:02 -0700, Adrian Chadd wrote:
What's running the other copy?
Adrian
On Nov 1, 2013 4:00 PM, clutton clut...@zoho.com wrote:
On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote:
On 1 November 2013 12:16, Bernhard Schmidt
bschm...@techwires.net wrote:
That actually is a design question I once wrapped my head
around
unsuccessfully. The lines above are responsible for
configuring wlan0
if it is created, eg.
ifconfig wlan0 destroy
ifconfig wlan0 create wlandev ath0
will invoke above code which will then invoke
pccard_ether. Changing
the code as you intent to will prevent this.
Someone should step up an decide what is supposed to
happen, should
wlan0 in that case be configured as stated in rc.conf, or
not?
The actual issue though, is in wpa_supplicant itself. It
has code to
prevent it being started twice, but that doesn't kick in
because the
instances are started to fast and we loose (have not yet
setup enough)
information in our net code.
Uhm, I'm confused by this. Would you mind explaining it in a
bit more detail?
-a
The devd runs a pccard_ether script when the IFNET interface
appears.
In some rare cases you can see two copies of the
wpa_sopplicant.
devd:
notify 0 {
match system IFNET;
match subsystem !usbus[0-9]+;
match typeATTACH;
action /etc/pccard_ether $subsystem start;
};
signature.asc
Description: This is a digitally signed message part
service netif restart [iface] runs a wpa_supplicant twice
What is the best way to restart a wireless stack?
A command ifconfig wlan0 create wlandev ath0 starts the wpa_supplicant
by itself. It means that the netif script runs the wpa_supplicant twice,
always. Is it ok?
There is my debug during booting:
[netif.network_common()] START:
[netif.network_common()] ITERATION:
[wpa_supplicant] SUPPID=30067
[wpa_supplicant] SUPPID=30067
[netif.network_common()] STOP:
It means that during running a network_common() from the /etc/rc.d/netif
the /etc/rc.d/wpa_supplicant was called twice.
/etc/rc.conf
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_em0=DHCP
ipsec_enable=YES
/etc/wpa_supplicant.conf
network={
ssid=ssid
psk=psk
}
11.0-CURRENT
signature.asc
Description: This is a digitally signed message part
