service netif restart [iface] runs a wpa_supplicant twice

[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:
[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

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

[clutton]

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  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"



signature.asc
Description: This is a digitally signed message part

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

[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  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  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 "type""ATTACH";
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

[clutton]

On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote:
> On 1 November 2013 12:16, Bernhard Schmidt  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

[clutton]

On Fri, 2013-11-01 at 20:16 +0100, Bernhard Schmidt wrote:
> On Fri, Nov 1, 2013 at 7:40 PM, clutton  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  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  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 "type""ATTACH";
> > 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

[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"  wrote:
> On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote:
> > On 1 November 2013 12:16, Bernhard Schmidt
>  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 "type""ATTACH";
action "/etc/pccard_ether $subsystem start";
};



signature.asc
Description: This is a digitally signed message part

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

[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  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"  wrote:
> >> On Fri, 2013-11-01 at 12:33 -0700, Adrian Chadd wrote:
> >> > On 1 November 2013 12:16, Bernhard Schmidt
> >>  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 "type""ATTACH";
> > 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

[clutton]

On Sat, 2013-11-02 at 10:00 -0700, Adrian Chadd wrote:
> right, this makes it clearer.
> 
> What about:
> 
> * the wpa_supplicant rc script only starts/stops one wpa_supplicant instance
> * upon ethernet / wlan clone creation, use interface_add to add the
> interface to wpa_supplicant
> * upon ethernet / wlan clone destruction, use interface_remove
> 
> how's that sound?
> 
> 
> -adrian

Sounds nice, but firstly we need to figure out this case, and then we
can do adding/removing/whatever

Without fixing that, it would be possible to see
adding/removing/whatever twice.

How to reproduce:

1) put debug info into rc.d/wpa_supplicant, a «toto» looks very
informative!

↑1 ~ → diff -u /usr/src/etc/rc.d/wpa_supplicant /etc/rc.d/wpa_supplicant
--- /usr/src/etc/rc.d/wpa_supplicant2013-06-19 01:06:53.911196741 +0300
+++ /etc/rc.d/wpa_supplicant2013-11-02 20:42:02.556222618 +0200
@@ -34,6 +34,8 @@
driver="bsd"
 fi
 
+echo toto >> /tmp/toto
+
 load_rc_config $name
 
 command=${wpa_supplicant_program}
zsh: exit 1 diff
-u /usr/src/etc/rc.d/wpa_supplicant /etc/rc.d/wpa_supplicant
↑1 ~ → 

2) then: service netif restart
3) then: cat /tmp/toto, how many totos do you see?
4) if you are lucky like I am, you can even observe something like this:

root   15038   0.0  0.1  21596   6100  -  Ss8:42pm
0:00.16 /usr/sbin/wpa_supplicant -s -B -i wlan0
-c /etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/wlan0.pid
root   15077   0.0  0.1  21596   6112  -  Ss8:42pm
0:00.12 /usr/sbin/wpa_supplicant -s -B -i wlan0
-c /etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/wlan0.pid

What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc),
when wlan0 interface occurs, devd runs another copy of netif.


signature.asc
Description: This is a digitally signed message part

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

[clutton]

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  wrote:
> > > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote:
> > > >> On 2 November 2013 12:13, clutton  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_ 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 
> >

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

[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...


___
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

[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 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

[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 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: pcap_inject() ruins my handmade packets

[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
> 

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  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"

Re: pcap_inject() ruins my handmade packets

[clutton]

On Sat, 2014-10-25 at 19:54 -0700, Adrian Chadd wrote:
> On 25 October 2014 18:05, clutton  wrote:
> > 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.
> 
> It should be working. I haven't coded anything up recently to use
> monitor mode and inject, but I do know it now works.
> 
> 
> 
> -adrian

I finally made the «reaver» work, I even got banned by my AP. The
problem is the pcap library, not the source of the program.

Before sending any patches I think I need familiarize myself with
libpcap more. Because it's pretty scary to patch program which has
comments like this:

* Back in 2002, Donald Lee at Cray wanted a DLT_ for
* IP-over-FC:
[skip]
* 11 years later, Christian Svensson wanted to map
* various ARPHRD_ values to DLT_FC_2 and
* DLT_FC_2_WITH_FRAME_DELIMS for raw Fibre Channel
* frames:

One more question: no radiotap headers currently can be injected. Right?
The underlie levels just ignore DLT_IEEE802_11_RADIO dlt.


___
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

[clutton]

On Thu, 2014-10-30 at 09:13 -0700, Adrian Chadd wrote:
> Hah, what was your actual code that worked?
> 
> And hm, there are some things in the radiotap header that the raw
> transmit path pays attention to.
> 
> 
> 
> -adrian
> 
> 
> On 30 October 2014 09:11, clutton  wrote:
> > On Sat, 2014-10-25 at 19:54 -0700, Adrian Chadd wrote:
> >> On 25 October 2014 18:05, clutton  wrote:
> >> > 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.
> >>
> >> It should be working. I haven't coded anything up recently to use
> >> monitor mode and inject, but I do know it now works.
> >>
> >>
> >>
> >> -adrian
> >
> > I finally made the «reaver» work, I even got banned by my AP. The
> > problem is the pcap library, not the source of the program.
> >
> > Before sending any patches I think I need familiarize myself with
> > libpcap more. Because it's pretty scary to patch program which has
> > comments like this:
> >
> > * Back in 2002, Donald Lee at Cray wanted a DLT_ for
> > * IP-over-FC:
> > [skip]
> > * 11 years later, Christian Svensson wanted to map
> > * various ARPHRD_ values to DLT_FC_2 and
> > * DLT_FC_2_WITH_FRAME_DELIMS for raw Fibre Channel
> > * frames:
> >
> > One more question: no radiotap headers currently can be injected. Right?
> > The underlie levels just ignore DLT_IEEE802_11_RADIO dlt.

The program I work with is [rever] https://code.google.com/p/reaver-wps

I looked at aircrack-ng sources, and tools/net80211 and none of them
includes radiotap headers for injection, when I do I have corrupted
packets.


___
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"

Atheros 5418, client drops connection after some time with N

[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 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: Atheros 5418, client drops connection after some time with N

[clutton]

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  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

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

[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

[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

[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 for now.

signature.asc
Description: This is a digitally signed message part

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

[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 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

[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