Hi,
I'm a masters student of Automation and Systems Engineering at
Federal University of Santa Catarina in Brazil. I'd like to know if it
is possible to modify the implementation of iwlwifi because I need to
decrease the time of association between the client and the AP. I'd
like to implement something in the same way like I read in an article,
project QuickWifi. Its basic idea is that a client doesn't wait each
response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
an end-to-end connection is available.
I need this to my work, it will be used for the communication
between a moving vehicle and a fixed point on the street.
Thank you.
Best regards,
-
Cassiano Valle Tartari
Computer Engineer
Tel: +55.48.84474818
Email: [email protected]
Site: http://www.cassianotartari.eng.br
Thanks for the quick reply,
Could you give me something to start? I saw a lot of files in
"compat-wireless-2010-10-20/drivers/net/wireless/iwlwifi" is it ?
-
Cassiano Valle Tartari
Computer Engineer
Tel: +55.48.84474818
Email: [email protected]
Site: http://www.cassianotartari.eng.br
On Thu, Oct 21, 2010 at 2:58 PM, Guy, Wey-Yi <[email protected]> wrote:
>
> Hi Cassiano,
>
> On Thu, 2010-10-21 at 09:17 -0700, Cassiano Tartari, Eng. wrote:
> > Hi,
> >
> > ? I'm a masters student of Automation and Systems Engineering at
> > Federal University of Santa Catarina in Brazil. I'd like to know if it
> > is possible to modify the implementation of iwlwifi because I need to
> > decrease the time of association between the client and the AP. I'd
> > like to implement something in the same way like I read in an article,
> > project QuickWifi. Its basic idea is that a client doesn't wait each
> > response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
> > DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
> > an end-to-end connection is available.
> >
> > ? ? I need this to my work, it will be used for the communication
> > between a moving vehicle and a fixed point on the street.
> >
>
> It is an open source project, so please feel free to make the
> modifications; but please do follow the upstream process and submit the
> patch to either "[email protected]" mailing list or
> "[email protected]" mailing list for review
>
> Thanks
> Wey
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
On Mon, Oct 25, 2010 at 2:27 PM, Blaise Gassend <[email protected]> wrote:
> On Mon, Oct 25, 2010 at 1:39 AM, Johannes Berg
> <[email protected]> wrote:
>> On Thu, 2010-10-21 at 14:17 -0200, Cassiano Tartari, Eng. wrote:
>>> Its basic idea is that a client doesn't wait each
>>> response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
>>> DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
>>> an end-to-end connection is available.
>>
>> I'd just like to point out that for various reasons (that I invite you
>> to research for yourself) there's no way this can work in encrypted
>> networks, or against compliant/certified access points.
In my work, I could use a open network.
How can I know if a AP is "compliant/certified" ? I'm such a newbie.
I read in the manual of the AP: The DWL-2100AP is also interoperable
with other 802.11g and 802.11b
standards-compliant devices.
>
> I had a look at the paper, and the original poster seems to have
> exaggerated the paper's claims. They do indeed do the authentication
> and association request before getting responses. For everything else,
> they wait to get the response for the previous stage. The main
> difference is that they greatly reduce the timeouts before retrying at
> each stage. The paper is also limited to non-encrypted networks.
My objetive in my current job is just that, reduce the time of authentication.
Someone has a better idea or solution to reduce the association time?
I need to use DHCP and could be a open network.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
> How can I know if a AP is "compliant/certified" ? I'm such a newbie.
I suspect that most of them are. If they have a WiFi logo on the box
they should be:
http://www.wi-fiplanet.com/tutorials/article.php/2203361/Wi-Fi-Interoperability-Compliance-Steps.htm
>> I had a look at the paper, and the original poster seems to have
>> exaggerated the paper's claims. They do indeed do the authentication
>> and association request before getting responses. For everything else,
>> they wait to get the response for the previous stage. The main
>> difference is that they greatly reduce the timeouts before retrying at
>> each stage. The paper is also limited to non-encrypted networks.
>
> My objetive in my current job is just that, reduce the time of authentication.
>
> Someone has a better idea or solution to reduce the association time?
> I need to use DHCP and could be a open network.
How short does it need to be for you? In my experience sub-second is
pretty if you know the frequency, have low packet loss, and have an
aggressive DHCP client. The methods in the paper should make it work
even with higher packet loss.
On Mon, Oct 25, 2010 at 5:31 PM, Blaise Gassend <[email protected]> wrote:
>
> > How can I know if a AP is "compliant/certified" ? I'm such a newbie.
>
> I suspect that most of them are. If they have a WiFi logo on the box
> they should be:
> http://www.wi-fiplanet.com/tutorials/article.php/2203361/Wi-Fi-Interoperability-Compliance-Steps.htm
>
> >> I had a look at the paper, and the original poster seems to have
> >> exaggerated the paper's claims. They do indeed do the authentication
> >> and association request before getting responses. For everything else,
> >> they wait to get the response for the previous stage. The main
> >> difference is that they greatly reduce the timeouts before retrying at
> >> each stage. The paper is also limited to non-encrypted networks.
> >
> > My objetive in my current job is just that, reduce the time of authentication.
> >
> > Someone has a better idea or solution to reduce the association time?
> > I need to use DHCP and could be a open network.
>
> How short does it need to be for you? In my experience sub-second is
> pretty if you know the frequency, have low packet loss, and have an
> aggressive DHCP client. The methods in the paper should make it work
> even with higher packet loss.
what is a "agressive DHCP client" ? I saw in the manual, there a lot
of telnet commans for DHCP
I tryed:
sudo iwconfig wlan0 mode managed freq 2.437G rate 1M frag 256 key open
essid 'cassiano-PC_AP'
But when I try to run:
sudo dhclient wlan0
return: "No DHCPOFFERS received"
And I need to do this because my code will connect automatic. Using
the networkManager (ubuntu) the connection appears to occur fast.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
On Mon, Oct 25, 2010 at 1:39 AM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2010-10-21 at 14:17 -0200, Cassiano Tartari, Eng. wrote:
>> Its basic idea is that a client doesn't wait each
>> response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
>> DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
>> an end-to-end connection is available.
>
> I'd just like to point out that for various reasons (that I invite you
> to research for yourself) there's no way this can work in encrypted
> networks, or against compliant/certified access points.
I had a look at the paper, and the original poster seems to have
exaggerated the paper's claims. They do indeed do the authentication
and association request before getting responses. For everything else,
they wait to get the response for the previous stage. The main
difference is that they greatly reduce the timeouts before retrying at
each stage. The paper is also limited to non-encrypted networks.
Hi Cassiano,
On Thu, 2010-10-21 at 09:17 -0700, Cassiano Tartari, Eng. wrote:
> Hi,
>
> I'm a masters student of Automation and Systems Engineering at
> Federal University of Santa Catarina in Brazil. I'd like to know if it
> is possible to modify the implementation of iwlwifi because I need to
> decrease the time of association between the client and the AP. I'd
> like to implement something in the same way like I read in an article,
> project QuickWifi. Its basic idea is that a client doesn't wait each
> response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
> DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
> an end-to-end connection is available.
>
> I need this to my work, it will be used for the communication
> between a moving vehicle and a fixed point on the street.
>
It is an open source project, so please feel free to make the
modifications; but please do follow the upstream process and submit the
patch to either "[email protected]" mailing list or
"[email protected]" mailing list for review
Thanks
Wey
> what is a "agressive DHCP client" ? I saw in the manual, there a lot
> of telnet commans for DHCP
One that doesn't start by waiting a few seconds, to start with. I'm
thinking about a client that immediately tries to get a lease, and
does retries within a few hundred ms at most if it doesn't get a
response. dhclient definitely isn't an aggressive dhcp client. It
isn't supposed to be.
> I tryed:
> sudo iwconfig wlan0 mode managed freq 2.437G rate 1M frag 256 key open
> essid 'cassiano-PC_AP'
>
> But when I try to run:
> sudo dhclient wlan0
>
> return: "No DHCPOFFERS received"
>
> And I need to do this because my code will connect automatic. Using
> the networkManager (ubuntu) the connection appears to occur fast.
I can't debug your setup for you, and I suspect this list isn't the
right place to do it... Have you checked that you actually associated
to the AP? Have you tried using tcpdump to see if packets are making
it out?
Blaise
On Thu, 2010-10-21 at 14:17 -0200, Cassiano Tartari, Eng. wrote:
> Its basic idea is that a client doesn't wait each
> response to go to the next step, so just do: AUTH REQ -> ASSOC REQ ->
> DHCP DISC -> DHCP REQ -> ARP QUERY and a PING THROUGH to verify that
> an end-to-end connection is available.
I'd just like to point out that for various reasons (that I invite you
to research for yourself) there's no way this can work in encrypted
networks, or against compliant/certified access points.
johannes