How i Prevent myself from getting Deauth Frames/Packets...???

[FurqanHanif]

is their any program which rejects Deauth Packets or Frames so my Network ain't disconnect if someone send me Deauth Packets>..  :'(  ???

[weVeg]

I don't know if you/we can prevent that! As I know, it's not possible! Only make a strong password!
I hope that someone can disappoint me!!

[ostendali]

you can't prevent deauth attack, becaue it is a legitimate tcp request. it is about the management frames in the 802.11 specification. So technically speaking, it is not possible but assuming that you can tell to your router to not deauth the client, in this case you will never be able to disconnect or connect at all to your device.

i hope that clarified the issue enough.

as far as I know, unless you don't invent a new protocol, it is not possible to prevent.

Instead, if you are annoyed from these attacks, you can hide your bissd and use the stronger auth algorithm. Also configure your client (yur computer) to not authenticate in auto once deauthenticated and leave to the user to decide to do that manually.

cya

[b4d_bl0ck]

True all what has been said since now... basically you can hardly mitigate it.

Anyways:

you can't prevent deauth attack, becaue it is a legitimate tcp request.

They are not TCP requests. These messages are 802.11 management frames and are exchanged at a deeper level, i guess Data Link (MAC) layer. ;)

All that happens because these management frames in 802.11 are not authenticated/encrypted, so everyone can spoof them.
In this way the target MAC address can be specified as the source of the Deauth request, and the AP will happyly deauth that station without any check.

HERE you can read some nice explanations. You can jump to Deauth sections to understand this particular issue.
And scrolling a bit down to Practical Attacks and Defenses, in the deauth section, they propose a mitigation system for this attack, consisting in monitoring the network, buffering the deauth requests in a queue for a given timeout (so not deauthenticating the station as soon as it arrives) and then wait for a timeout. If data frames arrive after the deauth request, the AP discards the deauth request, because this is an inconsisten behaviour, since a station would never send a deauth request and after that continue to send/receive data.
Really interesting...

Enjoy!  ;)

[ostendali]

True all what has been said since now... basically you can hardly mitigate it.

Anyways:

you can't prevent deauth attack, becaue it is a legitimate tcp request.

They are not TCP requests. These messages are 802.11 management frames and are exchanged at a deeper level, i guess Data Link (MAC) layer. ;)

All that happens because these management frames in 802.11 are not authenticated/encrypted, so everyone can spoof them.
In this way the target MAC address can be specified as the source of the Deauth request, and the AP will happyly deauth that station without any check.

HERE you can read some nice explanations. You can jump to Deauth sections to understand this particular issue.
And scrolling a bit down to Practical Attacks and Defenses, in the deauth section, they propose a mitigation system for this attack, consisting in monitoring the network, buffering the deauth requests in a queue for a given timeout (so not deauthenticating the station as soon as it arrives) and then wait for a timeout. If data frames arrive after the deauth request, the AP discards the deauth request, because this is an inconsisten behaviour, since a station would never send a deauth request and after that continue to send/receive data.
Really interesting...

Enjoy!  ;)

Maybe I misexplained myself, I meant to say that once the dauth happens succesfully the request to reconnect to the router is a legitimate tcp request.
you can understand this also from the next sentence about what I said "it is about the management frames in the 802.11 specification".
I always use to be lazy in explaining well things,,,
However, now it more clear I hope.