<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.drivers.hostap">
    <title>gmane.linux.drivers.hostap</title>
    <link>http://blog.gmane.org/gmane.linux.drivers.hostap</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28071"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28070"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28069"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28068"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28067"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28066"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28065"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28064"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28063"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28062"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28061"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28060"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28059"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28058"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28057"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28056"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28055"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28054"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28053"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.drivers.hostap/28052"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28071">
    <title>Re: [PATCH] P2P: Add IFNAME=iface command option for interfaceredirection</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28071</link>
    <description>&lt;pre&gt;
Attached. However, commands are case-sensitive. We can probably force
argv[1] to be
upper case to make things easier.


I am sorry, it somehow reminds me days when ctrl_conn and mon_conn were
actually same socket. I don't know why I thought about it.

_______________________________________________
HostAP mailing list
HostAP&amp;lt; at &amp;gt;lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
&lt;/pre&gt;</description>
    <dc:creator>Dmitry Shmidt</dc:creator>
    <dc:date>2013-05-21T23:41:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28070">
    <title>Re: [PATCH 03/20] driver: nl80211: hold wdev identification forP2P device</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28070</link>
    <description>&lt;pre&gt;
Good point. Although obviously for the P2P device interface we would 
only put the wdev_id as it does not have a valid ifindex.

Gr. AvS
&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-21T19:29:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28069">
    <title>Re: [PATCH] P2P: Add IFNAME=iface command option for interfaceredirection</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28069</link>
    <description>&lt;pre&gt;
Sure, go ahead.


On wpa_supplicant side, yes, it is the same socket. On the client side,
it is not the same local end (e.g., see what wpa_ctrl_open() binds the
socket to).


I don't see any issues with this.


Why? Each connection to the global interface is uniquely identified by
the server,client side ends of the connection. Having one of those
(server) fixed does not make this any less unique pair. This is the
design that has been used with the per-interface control interfaces for
close to ten years now.. ;-) (Including what wifi.c does on Android
today.)

&lt;/pre&gt;</description>
    <dc:creator>Jouni Malinen</dc:creator>
    <dc:date>2013-05-21T19:22:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28068">
    <title>Re: [PATCH] P2P: Add IFNAME=iface command option for interfaceredirection</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28068</link>
    <description>&lt;pre&gt;
You are right, raw command is working. I am going to prepare wpa_cli patch, if
you don't mind.


It is possible that I am confused with control and monitor socket mix,
but it looks like in case of global we are using "same" socket. It will
be different socket descriptor, but it is literally connected to the same file.
wpa_ctrl_open() will connect control and monitor socket to same "named"
socket/file.
I see it is working, but isn't it a chance that we can mess control and event
messages?
Is there easy way to use different name sockets for global interface for
control and monitor?

&lt;/pre&gt;</description>
    <dc:creator>Dmitry Shmidt</dc:creator>
    <dc:date>2013-05-21T18:48:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28067">
    <title>RE: [PATCH 03/20] driver: nl80211: hold wdev identification for P2Pdevice</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28067</link>
    <description>&lt;pre&gt;


I think that older kernel versions will ignore the WDEV attribute so that should not be an issue. Anyway, I'm also ok with the current approach :) thanks.

&lt;/pre&gt;</description>
    <dc:creator>Peer, Ilan</dc:creator>
    <dc:date>2013-05-21T18:21:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28066">
    <title>Re: [PATCH 00/20] wpa_s: p2p: support nl80211 P2P_DEVICE interface</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28066</link>
    <description>&lt;pre&gt;
Trying to get an idea of the hwsim issues. I think I got the test 
environment pretty much set up, but I do get this:

Command '['../../wlantest/wlantest_cli', 'get_tdls_counter', 
'setup_conf_ok', '....] returned non-zero exit status 255
FAIL test_autogo_tdls
 

passed 1 test case(s) 

failed tests: ['test_autogo', 'test_autogo_tdls']

Is there a compilation flag missing in wlantest_cli?

Regards,
Arend
&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-21T14:16:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28065">
    <title>Re: [PATCH 00/20] wpa_s: p2p: support nl80211 P2P_DEVICE interface</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28065</link>
    <description>&lt;pre&gt;
I did not see device discovery working. hwsim0 shows Probe Request
frames, but there was no reporting if Probe Request frames to
wpa_supplicant and as such, no responses to these.


I'd assume I had that in my tests. I was using a wireless-testing.git
snapshot. Anyway, whether I had that there or not does not matter since
there is obviously at least one snapshot of the kernel where this breaks
P2P completely at least for hwsim tests. I cannot apply such changes
into hostap.git without protection that avoids regressions with any past
kernel snapshot in the default configuration. It would be unfortunate if
we have managed to push kernel changes in to claim support for this
without it actually working. That would mean that there may be need for
manual configuration to enable this in wpa_supplicant and/or a new
capability bit in the kernel once things start working.


Hmm.. I don't think this would explain the issues I saw.

&lt;/pre&gt;</description>
    <dc:creator>Jouni Malinen</dc:creator>
    <dc:date>2013-05-21T12:02:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28064">
    <title>Re: [PATCH 00/20] wpa_s: p2p: support nl80211 P2P_DEVICE interface</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28064</link>
    <description>&lt;pre&gt;
Can you elaborate what does not work in you hwsim tests. I tested with 
your devel branch and I can connect and ping. However, I am using 
3.10-rc1 on the peer using P2P Device interface. Reason for this is that 
it needs a nl80211 patch to make P2P_FIND succeed.

   commit 97990a060e6757f48b931a3946b17c1c4362c3fb
   Author: Johannes Berg &amp;lt;johannes.berg&amp;lt; at &amp;gt;intel.com&amp;gt;
   Date:   Fri Apr 19 01:02:55 2013 +0200

       nl80211: allow using wdev identifiers to get scan results

Another thing is that for P2P Device I use the same configuration file, 
but that starts scanning on P2P Device for the networks configured in 
it. So I patched wpa_supplicant_enabled_networks() to return 0 if 
wpa_s-&amp;gt;p2p_mgmt is 1.

I do see a problem on the devel branch with deleting the group 
interface, which I do not recall seeing on my branch. I will double check.

Regards,
Arend

&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-21T11:53:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28063">
    <title>Re: [PATCH 03/20] driver: nl80211: hold wdev identification forP2P device</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28063</link>
    <description>&lt;pre&gt;
I meant to say: kernel version *without* wdev_id. Sorry for the confusion.

&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-21T10:18:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28062">
    <title>Re: WPA_supplicant trouble connecting client to AP</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28062</link>
    <description>&lt;pre&gt;2013/5/16 Dan Williams &amp;lt;dcbw&amp;lt; at &amp;gt;redhat.com&amp;gt;:

I have tried to leave out that parameter but without success, which
according to openWRT people, this value is set when the client fix the
channel to work in.

On the other hand, has wpa_supplicant a way of selecting a default
frequency in case some error occurs?? I mean, for instance if you try
to set a wrong frequency or channel, wpa can change it for a default
one like for instance the channel 34??

I tell this because, I'm experiencing a weird behaviour, my AP is on
4915MHz, as you can see below

Completing interface initialization
1315508363.989115: Mode: IEEE 802.11a  Channel: 183  Frequency: 4915 MHz
1315508363.989470: nl80211: Set freq 4915 (ht_enabled=0 sec_channel_offset=0)

However, in the client, I get a complete different frequency of the BSS

lan1: State: SCANNING -&amp;gt; AUTHENTICATING
1315509514.527299: nl80211: Authenticate (ifindex=13)
1315509514.527333:   * bssid=xx:xx:xx:xx:xx:xx
1315509514.527376:   * freq=5180
1315509514.527401:   * SSID - hexdump_ascii(len=18):

What is this due to???

Thanks in advance!
&lt;/pre&gt;</description>
    <dc:creator>Francisco Cuesta</dc:creator>
    <dc:date>2013-05-21T10:11:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28061">
    <title>Re: [PATCH] P2P: Add IFNAME=iface command option for interfaceredirection</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28061</link>
    <description>&lt;pre&gt;
wpa_supplicant does understand the command and the "status" failing is
by design since there is no way of figuring out which interface that
would apply to without the IFNAME prefix. I guess there could also be a
global STATUS command added to give systemwide (not specific to a
network interface information).

The middle one is a current limitation in wpa_cli, not in the
wpa_supplicant control interface. You can run that with "raw
IFNAME=wlan0 STATUS" from wpa_cli. I guess I should make wpa_cli
understand that IFNAME= prefix, too, so that this would not need to go
through the raw command. Anyway, this is all within wpa_cli.


That was the original design direction for the global control interface
extensions, too, and it should work fine (and does in my tests). Please
let me know if you hit any issues that are not just because of wpa_cli
limitations on this. As far as I can tell, it should now be possible to
run every operation (both commands and events) through the global
interface now.

&lt;/pre&gt;</description>
    <dc:creator>Jouni Malinen</dc:creator>
    <dc:date>2013-05-21T07:55:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28060">
    <title>Re: Hostapd and wpa_supplicant frequency range</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28060</link>
    <description>&lt;pre&gt;Good afternoon,


Thank for your answer, I was aware of that fact, indeed, iw list command
lists the frequencies which I wanted, but I have found functions in
hostapd, for instance, wpa_supplicant_conf_ap() where there're defined some
frequency ranges of operating work. I was wondering, whether there is some
more functions in which such a statements are in.

Thanks in advance,

Kind regards,

Watanabe


2013/5/20 Holger Schurig &amp;lt;holgerschurig&amp;lt; at &amp;gt;gmail.com&amp;gt;

_______________________________________________
HostAP mailing list
HostAP&amp;lt; at &amp;gt;lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
&lt;/pre&gt;</description>
    <dc:creator>Sotaro Watanabe</dc:creator>
    <dc:date>2013-05-21T07:07:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28059">
    <title>Re: [PATCH] hostapd: Remove redundant freeing of STA list entries</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28059</link>
    <description>&lt;pre&gt;
no Jouni, its a cleanup, haven't found any issue that this fixes.

&lt;/pre&gt;</description>
    <dc:creator>Mohammed Shafi Shajakhan</dc:creator>
    <dc:date>2013-05-21T05:16:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28058">
    <title>Re: [PATCH] P2P: Add IFNAME=iface command option for interfaceredirection</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28058</link>
    <description>&lt;pre&gt;
I like idea to have global interface to control everything. However,
it looks like it doesn't understand
"usual" interface commands like:

root&amp;lt; at &amp;gt;manta:/ # wpa_cli -g &amp;lt; at &amp;gt;android:wpa_wlan0
Interactive mode
UNKNOWN COMMAND
Unknown command 'IFNAME=wlan0'
OK
...

I understand that it was not your original design direction, but it
will be easier for wifi manager to
have one socket control and one socket monitor.

&lt;/pre&gt;</description>
    <dc:creator>Dmitry Shmidt</dc:creator>
    <dc:date>2013-05-21T00:59:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28057">
    <title>Re: Hostapd and wpa_supplicant frequency range</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28057</link>
    <description>&lt;pre&gt;It's the kernel driver and the optional CRDA that tell the kernel
which channels/frequency are allowed and with what parameters. Do "iw
wlan0" to see what frequencies your card (with your current driver)
supports.

2013/5/20 Sotaro Watanabe &amp;lt;sotarowatanabe&amp;lt; at &amp;gt;gmail.com&amp;gt;:
&lt;/pre&gt;</description>
    <dc:creator>Holger Schurig</dc:creator>
    <dc:date>2013-05-20T19:58:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28056">
    <title>Re: Not reassociating after a 4-way Handshake 'Retry limit 4 reached'</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28056</link>
    <description>&lt;pre&gt;Noone?


On Tue, May 14, 2013 at 2:08 PM, Douglas Diniz &amp;lt;dgdiniz&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Douglas Diniz</dc:creator>
    <dc:date>2013-05-20T14:56:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28055">
    <title>Hostapd and wpa_supplicant frequency range</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28055</link>
    <description>&lt;pre&gt;Good afternoon, I'm Watanabe,Sotaro,

Currently am I working with some experimental wifi cards, which support
6GHz bands. In that sense, I would like to know whether or not hostapd and
wpa supplicant might work in that range.

Looking into the code, I have found some files where such a frequency range
are defined, but I don't know if those files are all of the them or just a
few of a whole set, might be possible to know what are all the files which
contain the frequency working range of hostapd and wpa supplicant?

On the other hand, I would wish to know whether I might extend these ranges
will lead to a proper work of hostapd and wpa supplicant.

Thank you so much,


Watanabe.
_______________________________________________
HostAP mailing list
HostAP&amp;lt; at &amp;gt;lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
&lt;/pre&gt;</description>
    <dc:creator>Sotaro Watanabe</dc:creator>
    <dc:date>2013-05-20T14:21:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28054">
    <title>RE: [PATCH 03/20] driver: nl80211: hold wdev identification for P2Pdevice</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28054</link>
    <description>&lt;pre&gt;


I meant put both attributes :) I think that even older kernel versions can handle this.

&lt;/pre&gt;</description>
    <dc:creator>Peer, Ilan</dc:creator>
    <dc:date>2013-05-20T07:05:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28053">
    <title>Re: [PATCH 06/20] wpa_s: p2p: create P2P Device interface if supported</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28053</link>
    <description>&lt;pre&gt;
wpas_p2p_add_p2pdev_interface() does a wpa_supplicant_add_iface() with 
iface-&amp;gt;p2p_mgmt set to 1. So wpas_p2p_init() is only called for the P2P 
Device wpa_s or for the first interface specified on the command line in 
case driver does not support P2P_DEVICE.

&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-19T21:16:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28052">
    <title>Re: [PATCH 03/20] driver: nl80211: hold wdev identification forP2P device</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28052</link>
    <description>&lt;pre&gt;
That was my initial take as well, but Johannes pointed out to keep 
wpa_supplicant usable for kernel version with wdev_id.

&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-19T21:13:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.drivers.hostap/28051">
    <title>Re: [PATCH 00/20] wpa_s: p2p: support nl80211 P2P_DEVICE interface</title>
    <link>http://permalink.gmane.org/gmane.linux.drivers.hostap/28051</link>
    <description>&lt;pre&gt;
Thanks, Jouni

I will have a look at the devel branch. Will not be until tuesday though 
due to holiday. What would be needed to run your hwsim tests if I want 
to look into that.


Ok. I put p2p_mgmt flag in wpa_supplicant struct, which could be used to 
skip creating a control interface for it if it is preferred to keep the 
behaviour the same. I forgot to mention, but there may be more stuff 
that is not really needed for this type of interface (eg. eapol related 
stuff) that I left as is.

Gr. AvS
&lt;/pre&gt;</description>
    <dc:creator>Arend van Spriel</dc:creator>
    <dc:date>2013-05-19T21:09:06</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.drivers.hostap">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.drivers.hostap</link>
  </textinput>
</rdf:RDF>
