linux-kernel - Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1391811934.18534.54.camel@porter.coelho.fi>
Date:	Sat, 08 Feb 2014 00:25:34 +0200
From:	Luca Coelho <luca@...lho.fi>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Kalle Valo <kvalo@...rom.com>,
	Johannes Berg <johannes@...solutions.net>,
	Calvin Owens <jcalvinowens@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason
 codes

On Fri, 2014-02-07 at 09:46 -0600, Larry Finger wrote:
> On 02/07/2014 06:53 AM, Kalle Valo wrote:
> > Johannes Berg <johannes@...solutions.net> writes:
> >
> >> On Wed, 2014-02-05 at 19:44 -0600, Calvin Owens wrote:
> >>> Create a function to return a descriptive string for each reason code,
> >>> and print that instead of the numeric value in the kernel log. These
> >>> codes are easily found on popular search engines, but one is generally
> >>> not able to access the internet when dealing with wireless connectivity
> >>> issues.
> >>
> >> I believe both iw and wpa_supplicant already have the reason code
> >> printout, and if you're diagnosing connectivity issues then you're
> >> probably using those anyway (e.g. iw event -t), so I don't really see
> >> much point in adding this to the kernel?
> >
> > FWIW I find this useful. When I have connection problems I rarely look
> > at wpasupplicant, mostly I'm so lazy that I just check from the kernel
> > log what's happening. Just my 0.02 EUR.
> 
> I would also find it useful. I assist with wireless problems on the openSUSE 
> Forum, and there we are lucky if we get dmesg output. When we do and it contains 
> a deauthentication reason, I always need to bring up a web page to interpret the 
> output. With this change, one step could be skipped.

But is it worth putting this parsing in the *kernel*? I mean, if anyone
is interested enough in the problem, a simple google query is not that
hard, right?

If this happens to you "on-the-fly" and all you want is your connection
to work, you won't start debugging right away.  You'll (maybe) save the
kernel logs, try to reconnect and debug later, at home.

If you think you *can* fix the problem on-the-fly, but you can't google
because the connection doesn't work, you certainly have either the IEEE
802.11 specs or the kernel sources somewhere in your device. :)

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/