service netif restart [iface] runs a wpa_supplicant twice

2013-10-23 Thread clutton
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:

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-01 Thread clutton
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

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-01 Thread clutton
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.

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-01 Thread clutton
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

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-01 Thread clutton
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

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-02 Thread clutton
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

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-11-07 Thread clutton
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

Re: service netif restart [iface] runs a wpa_supplicant twice

2013-12-07 Thread clutton
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...

pcap_inject() ruins my handmade packets

2014-10-23 Thread clutton
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

Re: pcap_inject() ruins my handmade packets

2014-10-23 Thread clutton
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

Re: pcap_inject() ruins my handmade packets

2014-10-25 Thread clutton
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

Re: Atheros 5418, client drops connection after some time with N

2017-02-07 Thread clutton
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

Atheros 5418, client drops connection after some time with N

2017-02-04 Thread clutton
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

Re: Atheros 5418, client drops connection after some time with N

2017-02-04 Thread clutton
> > > > -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 sh

Re: Atheros 5418, client drops connection after some time with N

2017-02-04 Thread clutton
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

2017-02-04 Thread clutton
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

2017-02-04 Thread clutton
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

Re: Atheros 5418, client drops connection after some time with N

2017-02-04 Thread clutton
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