2008-09-29 09:56:48

by Jiri Slaby

[permalink] [raw]
Subject: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

Hi,

I've found out, that NL80211_CMD_GET_WIPHY reply doesn't fit into a message
socket buffer now. Used driver is ath5k.

There is also a bug in hostapd which waits for ACK forever when this error occur
in i802_get_hw_feature_data(). This code should be preceded by the test which is
after it IMO (not sure if result.error case too):
if (!finished)
err = nl_wait_for_ack(drv->nl_handle);


Here is the kernel debug output:

Legend:
E|band
F|channels count
Fc|channel|consumed msg room|msg size

nl80211_send_wiphy: E 0
nl80211_send_wiphy: F 26
nl80211_send_wiphy: Fc 0 92 3648
nl80211_send_wiphy: Fc 1 112 3648
nl80211_send_wiphy: Fc 2 132 3648
nl80211_send_wiphy: Fc 3 152 3648
nl80211_send_wiphy: Fc 4 172 3648
nl80211_send_wiphy: Fc 5 192 3648
nl80211_send_wiphy: Fc 6 212 3648
nl80211_send_wiphy: Fc 7 232 3648
nl80211_send_wiphy: Fc 8 252 3648
nl80211_send_wiphy: Fc 9 272 3648
nl80211_send_wiphy: Fc 10 292 3648
nl80211_send_wiphy: Fc 11 312 3648
nl80211_send_wiphy: Fc 12 328 3648
nl80211_send_wiphy: Fc 13 344 3648
nl80211_send_wiphy: Fc 14 360 3648
nl80211_send_wiphy: Fc 15 376 3648
nl80211_send_wiphy: Fc 16 392 3648
nl80211_send_wiphy: Fc 17 408 3648
nl80211_send_wiphy: Fc 18 424 3648
nl80211_send_wiphy: Fc 19 440 3648
nl80211_send_wiphy: Fc 20 456 3648
nl80211_send_wiphy: Fc 21 472 3648
nl80211_send_wiphy: Fc 22 488 3648
nl80211_send_wiphy: Fc 23 504 3648
nl80211_send_wiphy: Fc 24 520 3648
nl80211_send_wiphy: Fc 25 536 3648
nl80211_send_wiphy: E 1
nl80211_send_wiphy: F 194
nl80211_send_wiphy: Fc 0 720 3648
nl80211_send_wiphy: Fc 1 736 3648
nl80211_send_wiphy: Fc 2 752 3648
nl80211_send_wiphy: Fc 3 768 3648
nl80211_send_wiphy: Fc 4 784 3648
nl80211_send_wiphy: Fc 5 800 3648
nl80211_send_wiphy: Fc 6 816 3648
nl80211_send_wiphy: Fc 7 832 3648
nl80211_send_wiphy: Fc 8 848 3648
nl80211_send_wiphy: Fc 9 864 3648
nl80211_send_wiphy: Fc 10 880 3648
nl80211_send_wiphy: Fc 11 896 3648
nl80211_send_wiphy: Fc 12 912 3648
nl80211_send_wiphy: Fc 13 928 3648
nl80211_send_wiphy: Fc 14 944 3648
nl80211_send_wiphy: Fc 15 960 3648
nl80211_send_wiphy: Fc 16 976 3648
nl80211_send_wiphy: Fc 17 992 3648
nl80211_send_wiphy: Fc 18 1008 3648
nl80211_send_wiphy: Fc 19 1024 3648
nl80211_send_wiphy: Fc 20 1040 3648
nl80211_send_wiphy: Fc 21 1056 3648
nl80211_send_wiphy: Fc 22 1072 3648
nl80211_send_wiphy: Fc 23 1088 3648
nl80211_send_wiphy: Fc 24 1104 3648
nl80211_send_wiphy: Fc 25 1120 3648
nl80211_send_wiphy: Fc 26 1136 3648
nl80211_send_wiphy: Fc 27 1152 3648
nl80211_send_wiphy: Fc 28 1168 3648
nl80211_send_wiphy: Fc 29 1184 3648
nl80211_send_wiphy: Fc 30 1200 3648
nl80211_send_wiphy: Fc 31 1216 3648
nl80211_send_wiphy: Fc 32 1232 3648
nl80211_send_wiphy: Fc 33 1248 3648
nl80211_send_wiphy: Fc 34 1264 3648
nl80211_send_wiphy: Fc 35 1280 3648
nl80211_send_wiphy: Fc 36 1296 3648
nl80211_send_wiphy: Fc 37 1312 3648
nl80211_send_wiphy: Fc 38 1328 3648
nl80211_send_wiphy: Fc 39 1344 3648
nl80211_send_wiphy: Fc 40 1360 3648
nl80211_send_wiphy: Fc 41 1376 3648
nl80211_send_wiphy: Fc 42 1392 3648
nl80211_send_wiphy: Fc 43 1408 3648
nl80211_send_wiphy: Fc 44 1424 3648
nl80211_send_wiphy: Fc 45 1440 3648
nl80211_send_wiphy: Fc 46 1456 3648
nl80211_send_wiphy: Fc 47 1472 3648
nl80211_send_wiphy: Fc 48 1488 3648
nl80211_send_wiphy: Fc 49 1504 3648
nl80211_send_wiphy: Fc 50 1520 3648
nl80211_send_wiphy: Fc 51 1536 3648
nl80211_send_wiphy: Fc 52 1552 3648
nl80211_send_wiphy: Fc 53 1568 3648
nl80211_send_wiphy: Fc 54 1584 3648
nl80211_send_wiphy: Fc 55 1600 3648
nl80211_send_wiphy: Fc 56 1616 3648
nl80211_send_wiphy: Fc 57 1632 3648
nl80211_send_wiphy: Fc 58 1648 3648
nl80211_send_wiphy: Fc 59 1664 3648
nl80211_send_wiphy: Fc 60 1680 3648
nl80211_send_wiphy: Fc 61 1696 3648
nl80211_send_wiphy: Fc 62 1712 3648
nl80211_send_wiphy: Fc 63 1728 3648
nl80211_send_wiphy: Fc 64 1744 3648
nl80211_send_wiphy: Fc 65 1760 3648
nl80211_send_wiphy: Fc 66 1776 3648
nl80211_send_wiphy: Fc 67 1792 3648
nl80211_send_wiphy: Fc 68 1808 3648
nl80211_send_wiphy: Fc 69 1824 3648
nl80211_send_wiphy: Fc 70 1840 3648
nl80211_send_wiphy: Fc 71 1856 3648
nl80211_send_wiphy: Fc 72 1872 3648
nl80211_send_wiphy: Fc 73 1888 3648
nl80211_send_wiphy: Fc 74 1904 3648
nl80211_send_wiphy: Fc 75 1920 3648
nl80211_send_wiphy: Fc 76 1936 3648
nl80211_send_wiphy: Fc 77 1952 3648
nl80211_send_wiphy: Fc 78 1968 3648
nl80211_send_wiphy: Fc 79 1984 3648
nl80211_send_wiphy: Fc 80 2000 3648
nl80211_send_wiphy: Fc 81 2016 3648
nl80211_send_wiphy: Fc 82 2032 3648
nl80211_send_wiphy: Fc 83 2048 3648
nl80211_send_wiphy: Fc 84 2064 3648
nl80211_send_wiphy: Fc 85 2080 3648
nl80211_send_wiphy: Fc 86 2096 3648
nl80211_send_wiphy: Fc 87 2112 3648
nl80211_send_wiphy: Fc 88 2128 3648
nl80211_send_wiphy: Fc 89 2144 3648
nl80211_send_wiphy: Fc 90 2160 3648
nl80211_send_wiphy: Fc 91 2176 3648
nl80211_send_wiphy: Fc 92 2192 3648
nl80211_send_wiphy: Fc 93 2208 3648
nl80211_send_wiphy: Fc 94 2224 3648
nl80211_send_wiphy: Fc 95 2240 3648
nl80211_send_wiphy: Fc 96 2256 3648
nl80211_send_wiphy: Fc 97 2272 3648
nl80211_send_wiphy: Fc 98 2288 3648
nl80211_send_wiphy: Fc 99 2304 3648
nl80211_send_wiphy: Fc 100 2320 3648
nl80211_send_wiphy: Fc 101 2336 3648
nl80211_send_wiphy: Fc 102 2352 3648
nl80211_send_wiphy: Fc 103 2368 3648
nl80211_send_wiphy: Fc 104 2384 3648
nl80211_send_wiphy: Fc 105 2400 3648
nl80211_send_wiphy: Fc 106 2416 3648
nl80211_send_wiphy: Fc 107 2432 3648
nl80211_send_wiphy: Fc 108 2448 3648
nl80211_send_wiphy: Fc 109 2464 3648
nl80211_send_wiphy: Fc 110 2480 3648
nl80211_send_wiphy: Fc 111 2496 3648
nl80211_send_wiphy: Fc 112 2512 3648
nl80211_send_wiphy: Fc 113 2528 3648
nl80211_send_wiphy: Fc 114 2544 3648
nl80211_send_wiphy: Fc 115 2560 3648
nl80211_send_wiphy: Fc 116 2576 3648
nl80211_send_wiphy: Fc 117 2592 3648
nl80211_send_wiphy: Fc 118 2608 3648
nl80211_send_wiphy: Fc 119 2624 3648
nl80211_send_wiphy: Fc 120 2640 3648
nl80211_send_wiphy: Fc 121 2656 3648
nl80211_send_wiphy: Fc 122 2672 3648
nl80211_send_wiphy: Fc 123 2688 3648
nl80211_send_wiphy: Fc 124 2704 3648
nl80211_send_wiphy: Fc 125 2720 3648
nl80211_send_wiphy: Fc 126 2736 3648
nl80211_send_wiphy: Fc 127 2752 3648
nl80211_send_wiphy: Fc 128 2768 3648
nl80211_send_wiphy: Fc 129 2784 3648
nl80211_send_wiphy: Fc 130 2800 3648
nl80211_send_wiphy: Fc 131 2816 3648
nl80211_send_wiphy: Fc 132 2832 3648
nl80211_send_wiphy: Fc 133 2848 3648
nl80211_send_wiphy: Fc 134 2864 3648
nl80211_send_wiphy: Fc 135 2880 3648
nl80211_send_wiphy: Fc 136 2896 3648
nl80211_send_wiphy: Fc 137 2912 3648
nl80211_send_wiphy: Fc 138 2928 3648
nl80211_send_wiphy: Fc 139 2944 3648
nl80211_send_wiphy: Fc 140 2960 3648
nl80211_send_wiphy: Fc 141 2976 3648
nl80211_send_wiphy: Fc 142 2992 3648
nl80211_send_wiphy: Fc 143 3008 3648
nl80211_send_wiphy: Fc 144 3024 3648
nl80211_send_wiphy: Fc 145 3040 3648
nl80211_send_wiphy: Fc 146 3056 3648
nl80211_send_wiphy: Fc 147 3072 3648
nl80211_send_wiphy: Fc 148 3088 3648
nl80211_send_wiphy: Fc 149 3104 3648
nl80211_send_wiphy: Fc 150 3120 3648
nl80211_send_wiphy: Fc 151 3136 3648
nl80211_send_wiphy: Fc 152 3152 3648
nl80211_send_wiphy: Fc 153 3168 3648
nl80211_send_wiphy: Fc 154 3184 3648
nl80211_send_wiphy: Fc 155 3200 3648
nl80211_send_wiphy: Fc 156 3216 3648
nl80211_send_wiphy: Fc 157 3232 3648
nl80211_send_wiphy: Fc 158 3248 3648
nl80211_send_wiphy: Fc 159 3264 3648
nl80211_send_wiphy: Fc 160 3280 3648
nl80211_send_wiphy: Fc 161 3296 3648
nl80211_send_wiphy: Fc 162 3312 3648
nl80211_send_wiphy: Fc 163 3328 3648
nl80211_send_wiphy: Fc 164 3344 3648
nl80211_send_wiphy: Fc 165 3360 3648
nl80211_send_wiphy: Fc 166 3376 3648
nl80211_send_wiphy: Fc 167 3392 3648
nl80211_send_wiphy: Fc 168 3408 3648
nl80211_send_wiphy: Fc 169 3424 3648
nl80211_send_wiphy: Fc 170 3440 3648
nl80211_send_wiphy: Fc 171 3456 3648
nl80211_send_wiphy: Fc 172 3472 3648
nl80211_send_wiphy: Fc 173 3488 3648
nl80211_send_wiphy: Fc 174 3504 3648
nl80211_send_wiphy: Fc 175 3520 3648
nl80211_send_wiphy: Fc 176 3536 3648
nl80211_send_wiphy: Fc 177 3552 3648
nl80211_send_wiphy: Fc 178 3568 3648
nl80211_send_wiphy: Fc 179 3584 3648
nl80211_send_wiphy: Fc 180 3600 3648
nl80211_send_wiphy: Fc 181 3616 3648
nl80211_send_wiphy: Fc 182 3632 3648
nl80211_send_wiphy: Fc 183 3648 3648



2008-09-29 10:25:28

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 13:20 +0300, Jouni Malinen wrote:
> On Mon, Sep 29, 2008 at 12:01:20PM +0200, Johannes Berg wrote:
>
> > > I've found out, that NL80211_CMD_GET_WIPHY reply doesn't fit into a message
> > > socket buffer now. Used driver is ath5k.
> >
> > Ok, humm, I have no idea what to do. I guess we'll somehow have to make
> > it possible to split it up on band or channel boundaries. But since
> > those are nested it seems somewhat weird to me. Any ideas?
>
> Isn't ath5k reporting quite a large set of channels that would never
> really be used? 26 channels on 2.4 GHz and 194(huh!) on 5 GHz.. First
> workaround could be to just limit those to somewhat more common set of
> channels.

Well, this is what the hw supports I guess, most channels will actually
reported to userspace with the DISABLED flag set.

> Sure, it would be nice to be able to handle long enough replies, but in
> this particular case, I'm not sure whether the reply is that realistic.
> Split on band boundary would not be enough here since the 5 GHz band
> alone would probably have went beyond the size limit.

Heh, ok, split on channels it is then I guess. No big deal, but I don't
know how to handle that at all.

> > > There is also a bug in hostapd which waits for ACK forever when this error occur
> > > in i802_get_hw_feature_data().
> >
> > I should replace all the code there with the current code from iw, it's
> > much better and actually handles all the corner cases.
>
> I have following (completely untested) patch.. Does it look correct or
> do you have something more complete that should be used here?

I recently rewrote the handling in iw completely to make it easier to
follow, will post an equivalent patch for hostapd in a minute.

Jiri, can you tell me what happens with iw? iw phy phy0 info or
something.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 16:45:40

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 19:31 +0300, Jouni Malinen wrote:

> Well.. It reports channels like 2732 MHz or 6100 MHz and 5 GHz center
> frequencies for every possible multiple of 5 MHz. If someone is really
> using those properly, they are on a licensed band and this types of
> lists are not really needed for normal users. Whether the hardware
> really supports them or well, more exactly, whether all selected
> components can handle these frequencies and whether the radios have been
> calibrated for all of these areas is another question.

Good points. I hadn't looked at the list at all.

> > > > > There is also a bug in hostapd which waits for ACK forever when this error occur
> > > > > in i802_get_hw_feature_data().
>
> For some reason, I do not seem to be able to reproduce this. Both iw and
> hostapd were able to fetch the data using the current wireless-testing
> tree..

Probably depends on something about alignment or whatever, not sure. Or
you have different hardware and the driver reports different things for
different hw? Anyway, it shouldn't wait forever, and my patch fixes
that.

> > I recently rewrote the handling in iw completely to make it easier to
> > follow, will post an equivalent patch for hostapd in a minute.
>
> Anyway, cleanup for nl send/recv processing is certainly welcome. I've
> never fully understood the steps that are used there and what to do if
> anything went wrong..

I see you applied that, it should be ported to the wpa_supplicant driver
too, I think.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 12:05:53

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 14:01 +0200, Jiri Slaby wrote:

> Anyway it is wrong. NLMSG_GOODSIZE * x for x > 1 doesn't give skb aligned to a
> page boundary. bufsize should start with PAGE_SIZE or 8192 and be multiplied
> then and the parameter used for nlmsg_new SKB_WITH_OVERHEAD(bufsize).

Hm ok.

> But it's ugly as hell, I agree -- and quite a temporary solution until somebody
> decides to add channels, another channel info or whatever.

I'd much prefer just splitting it up over multiple messages, shouldn't
be too hard but will possibly require changes in the userspace parsers.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 11:38:41

by Jiri Slaby

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On 09/29/2008 12:25 PM, Johannes Berg wrote:
> Jiri, can you tell me what happens with iw? iw phy phy0 info or
> something.

[iw from v0.9.5-1-ged69ad9]
# ./iw phy phy0 info
command failed: No buffer space available (-105)

as expected :). It depends only on how nl80211_send_wiphy() is written (the msg
doesn't fit into NLMSG_GOODSIZE).

2008-09-29 11:56:08

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 13:52 +0200, Jiri Slaby wrote:

> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -246,16 +246,26 @@ static int nl80211_get_wiphy(struct sk_buff *skb, struct
> genl_info *info)
> {
> struct sk_buff *msg;
> struct cfg80211_registered_device *dev;
> + size_t bufsize = NLMSG_GOODSIZE;
> + unsigned int tries = 0;
> + int ret;
>
> dev = cfg80211_get_dev_from_info(info);
> if (IS_ERR(dev))
> return PTR_ERR(dev);
>
> - msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
> +retry:
> + msg = nlmsg_new(bufsize, GFP_KERNEL);
> if (!msg)
> goto out_err;
>
> - if (nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev) < 0)
> + ret = nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev);
> + if (ret == -EMSGSIZE && ++tries < 2) {
> + bufsize *= 2;
> + nlmsg_free(msg);
> + goto retry;
> + }
> + if (ret < 0)
> goto out_free;
>
> cfg80211_put_dev(dev);
>

Works for me. Not the greatest way to do this I guess, but hey, it
works.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 10:45:28

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 12:35 +0200, Johannes Berg wrote:
> On Mon, 2008-09-29 at 12:25 +0200, Johannes Berg wrote:
>
> > I recently rewrote the handling in iw completely to make it easier to
> > follow, will post an equivalent patch for hostapd in a minute.
>
> How does this look?
>
> http://johannes.sipsolutions.net/patches/hostap/all/2008-09-29-10%3a34/002-nl80211-resync.patch
>
> Haven't tested it yet though.

Couldn't possibly work, better version here:

http://johannes.sipsolutions.net/patches/hostap/all/2008-09-29-10%3a44/002-nl80211-resync.patch

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 10:01:24

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

Hi Jiri,

> I've found out, that NL80211_CMD_GET_WIPHY reply doesn't fit into a message
> socket buffer now. Used driver is ath5k.

Ok, humm, I have no idea what to do. I guess we'll somehow have to make
it possible to split it up on band or channel boundaries. But since
those are nested it seems somewhat weird to me. Any ideas?

> There is also a bug in hostapd which waits for ACK forever when this error occur
> in i802_get_hw_feature_data().

I should replace all the code there with the current code from iw, it's
much better and actually handles all the corner cases.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 12:01:13

by Jiri Slaby

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On 09/29/2008 01:55 PM, Johannes Berg wrote:
> On Mon, 2008-09-29 at 13:52 +0200, Jiri Slaby wrote:
>
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -246,16 +246,26 @@ static int nl80211_get_wiphy(struct sk_buff *skb, struct
>> genl_info *info)
>> {
>> struct sk_buff *msg;
>> struct cfg80211_registered_device *dev;
>> + size_t bufsize = NLMSG_GOODSIZE;
>> + unsigned int tries = 0;
>> + int ret;
>>
>> dev = cfg80211_get_dev_from_info(info);
>> if (IS_ERR(dev))
>> return PTR_ERR(dev);
>>
>> - msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>> +retry:
>> + msg = nlmsg_new(bufsize, GFP_KERNEL);
>> if (!msg)
>> goto out_err;
>>
>> - if (nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev) < 0)
>> + ret = nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev);
>> + if (ret == -EMSGSIZE && ++tries < 2) {
>> + bufsize *= 2;
>> + nlmsg_free(msg);
>> + goto retry;
>> + }
>> + if (ret < 0)
>> goto out_free;
>>
>> cfg80211_put_dev(dev);
>>
>
> Works for me. Not the greatest way to do this I guess, but hey, it
> works.

Anyway it is wrong. NLMSG_GOODSIZE * x for x > 1 doesn't give skb aligned to a
page boundary. bufsize should start with PAGE_SIZE or 8192 and be multiplied
then and the parameter used for nlmsg_new SKB_WITH_OVERHEAD(bufsize).

But it's ugly as hell, I agree -- and quite a temporary solution until somebody
decides to add channels, another channel info or whatever.

2008-09-29 11:52:29

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 13:38 +0200, Jiri Slaby wrote:
> On 09/29/2008 12:25 PM, Johannes Berg wrote:
> > Jiri, can you tell me what happens with iw? iw phy phy0 info or
> > something.
>
> [iw from v0.9.5-1-ged69ad9]
> # ./iw phy phy0 info
> command failed: No buffer space available (-105)
>
> as expected :). It depends only on how nl80211_send_wiphy() is written (the msg
> doesn't fit into NLMSG_GOODSIZE).

Yes, I just wanted to confirm that the code there fails. I'm hunting a
strange bug in the hostapd code now, but other than that my patch (plus
a bunch of fixes) appears to work and reduce code size.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-29 11:52:45

by Jiri Slaby

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On 09/29/2008 12:25 PM, Johannes Berg wrote:
> Jiri, can you tell me what happens with iw? iw phy phy0 info or
> something.

Well, with this patch:
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1221d72..98fd93a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -246,16 +246,26 @@ static int nl80211_get_wiphy(struct sk_buff *skb, struct
genl_info *info)
{
struct sk_buff *msg;
struct cfg80211_registered_device *dev;
+ size_t bufsize = NLMSG_GOODSIZE;
+ unsigned int tries = 0;
+ int ret;

dev = cfg80211_get_dev_from_info(info);
if (IS_ERR(dev))
return PTR_ERR(dev);

- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+retry:
+ msg = nlmsg_new(bufsize, GFP_KERNEL);
if (!msg)
goto out_err;

- if (nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev) < 0)
+ ret = nl80211_send_wiphy(msg, info->snd_pid, info->snd_seq, 0, dev);
+ if (ret == -EMSGSIZE && ++tries < 2) {
+ bufsize *= 2;
+ nlmsg_free(msg);
+ goto retry;
+ }
+ if (ret < 0)
goto out_free;

cfg80211_put_dev(dev);

-----8<----------------8<----------------8<----------------8<-----

I get:
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz (passive scanning, no IBSS)
* 2417 MHz (passive scanning, no IBSS)
* 2422 MHz (passive scanning, no IBSS)
* 2427 MHz (passive scanning, no IBSS)
* 2432 MHz (passive scanning, no IBSS)
* 2437 MHz (passive scanning, no IBSS)
* 2442 MHz (passive scanning, no IBSS)
* 2447 MHz (passive scanning, no IBSS)
* 2452 MHz (passive scanning, no IBSS)
* 2457 MHz (passive scanning, no IBSS)
* 2462 MHz (passive scanning, no IBSS)
* 2467 MHz (disabled)
* 2472 MHz (disabled)
* 2484 MHz (disabled)
* 2512 MHz (disabled)
* 2532 MHz (disabled)
* 2552 MHz (disabled)
* 2572 MHz (disabled)
* 2592 MHz (disabled)
* 2612 MHz (disabled)
* 2632 MHz (disabled)
* 2652 MHz (disabled)
* 2672 MHz (disabled)
* 2692 MHz (disabled)
* 2712 MHz (disabled)
* 2732 MHz (disabled)
Bitrates:
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Frequencies:
* 5135 MHz (disabled)
* 5140 MHz (disabled)
* 5145 MHz (disabled)
* 5150 MHz (disabled)
* 5155 MHz (disabled)
* 5160 MHz (disabled)
* 5165 MHz (disabled)
* 5170 MHz (disabled)
* 5175 MHz (disabled)
* 5180 MHz (disabled)
* 5185 MHz (disabled)
* 5190 MHz (disabled)
* 5195 MHz (disabled)
* 5200 MHz (disabled)
* 5205 MHz (disabled)
* 5210 MHz (disabled)
* 5215 MHz (disabled)
* 5220 MHz (disabled)
* 5225 MHz (disabled)
* 5230 MHz (disabled)
* 5235 MHz (disabled)
* 5240 MHz (disabled)
* 5245 MHz (disabled)
* 5250 MHz (disabled)
* 5255 MHz (disabled)
* 5260 MHz (disabled)
* 5265 MHz (disabled)
* 5270 MHz (disabled)
* 5275 MHz (disabled)
* 5280 MHz (disabled)
* 5285 MHz (disabled)
* 5290 MHz (disabled)
* 5295 MHz (disabled)
* 5300 MHz (disabled)
* 5305 MHz (disabled)
* 5310 MHz (disabled)
* 5315 MHz (disabled)
* 5320 MHz (disabled)
* 5325 MHz (disabled)
* 5330 MHz (disabled)
* 5335 MHz (disabled)
* 5340 MHz (disabled)
* 5345 MHz (disabled)
* 5350 MHz (disabled)
* 5355 MHz (disabled)
* 5360 MHz (disabled)
* 5365 MHz (disabled)
* 5370 MHz (disabled)
* 5375 MHz (disabled)
* 5380 MHz (disabled)
* 5385 MHz (disabled)
* 5390 MHz (disabled)
* 5395 MHz (disabled)
* 5400 MHz (disabled)
* 5405 MHz (disabled)
* 5410 MHz (disabled)
* 5415 MHz (disabled)
* 5420 MHz (disabled)
* 5425 MHz (disabled)
* 5430 MHz (disabled)
* 5435 MHz (disabled)
* 5440 MHz (disabled)
* 5445 MHz (disabled)
* 5450 MHz (disabled)
* 5455 MHz (disabled)
* 5460 MHz (disabled)
* 5465 MHz (disabled)
* 5470 MHz (disabled)
* 5475 MHz (disabled)
* 5480 MHz (disabled)
* 5485 MHz (disabled)
* 5490 MHz (disabled)
* 5495 MHz (disabled)
* 5500 MHz (disabled)
* 5505 MHz (disabled)
* 5510 MHz (disabled)
* 5515 MHz (disabled)
* 5520 MHz (disabled)
* 5525 MHz (disabled)
* 5530 MHz (disabled)
* 5535 MHz (disabled)
* 5540 MHz (disabled)
* 5545 MHz (disabled)
* 5550 MHz (disabled)
* 5555 MHz (disabled)
* 5560 MHz (disabled)
* 5565 MHz (disabled)
* 5570 MHz (disabled)
* 5575 MHz (disabled)
* 5580 MHz (disabled)
* 5585 MHz (disabled)
* 5590 MHz (disabled)
* 5595 MHz (disabled)
* 5600 MHz (disabled)
* 5605 MHz (disabled)
* 5610 MHz (disabled)
* 5615 MHz (disabled)
* 5620 MHz (disabled)
* 5625 MHz (disabled)
* 5630 MHz (disabled)
* 5635 MHz (disabled)
* 5640 MHz (disabled)
* 5645 MHz (disabled)
* 5650 MHz (disabled)
* 5655 MHz (disabled)
* 5660 MHz (disabled)
* 5665 MHz (disabled)
* 5670 MHz (disabled)
* 5675 MHz (disabled)
* 5680 MHz (disabled)
* 5685 MHz (disabled)
* 5690 MHz (disabled)
* 5695 MHz (disabled)
* 5700 MHz (disabled)
* 5705 MHz (disabled)
* 5710 MHz (disabled)
* 5715 MHz (disabled)
* 5720 MHz (disabled)
* 5725 MHz (disabled)
* 5730 MHz (disabled)
* 5735 MHz (disabled)
* 5740 MHz (disabled)
* 5745 MHz (disabled)
* 5750 MHz (disabled)
* 5755 MHz (disabled)
* 5760 MHz (disabled)
* 5765 MHz (disabled)
* 5770 MHz (disabled)
* 5775 MHz (disabled)
* 5780 MHz (disabled)
* 5785 MHz (disabled)
* 5790 MHz (disabled)
* 5795 MHz (disabled)
* 5800 MHz (disabled)
* 5805 MHz (disabled)
* 5810 MHz (disabled)
* 5815 MHz (disabled)
* 5820 MHz (disabled)
* 5825 MHz (disabled)
* 5830 MHz (disabled)
* 5835 MHz (disabled)
* 5840 MHz (disabled)
* 5845 MHz (disabled)
* 5850 MHz (disabled)
* 5855 MHz (disabled)
* 5860 MHz (disabled)
* 5865 MHz (disabled)
* 5870 MHz (disabled)
* 5875 MHz (disabled)
* 5880 MHz (disabled)
* 5885 MHz (disabled)
* 5890 MHz (disabled)
* 5895 MHz (disabled)
* 5900 MHz (disabled)
* 5905 MHz (disabled)
* 5910 MHz (disabled)
* 5915 MHz (disabled)
* 5920 MHz (disabled)
* 5925 MHz (disabled)
* 5930 MHz (disabled)
* 5935 MHz (disabled)
* 5940 MHz (disabled)
* 5945 MHz (disabled)
* 5950 MHz (disabled)
* 5955 MHz (disabled)
* 5960 MHz (disabled)
* 5965 MHz (disabled)
* 5970 MHz (disabled)
* 5975 MHz (disabled)
* 5980 MHz (disabled)
* 5985 MHz (disabled)
* 5990 MHz (disabled)
* 5995 MHz (disabled)
* 6000 MHz (disabled)
* 6005 MHz (disabled)
* 6010 MHz (disabled)
* 6015 MHz (disabled)
* 6020 MHz (disabled)
* 6025 MHz (disabled)
* 6030 MHz (disabled)
* 6035 MHz (disabled)
* 6040 MHz (disabled)
* 6045 MHz (disabled)
* 6050 MHz (disabled)
* 6055 MHz (disabled)
* 6060 MHz (disabled)
* 6065 MHz (disabled)
* 6070 MHz (disabled)
* 6075 MHz (disabled)
* 6080 MHz (disabled)
* 6085 MHz (disabled)
* 6090 MHz (disabled)
* 6095 MHz (disabled)
* 6100 MHz (disabled)
Bitrates:
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Supported interface modes:
* IBSS
* Station
* AP
* AP(VLAN)
* Monitor
* mesh point


2008-09-29 16:32:44

by Jouni Malinen

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, Sep 29, 2008 at 12:25:23PM +0200, Johannes Berg wrote:

> > Isn't ath5k reporting quite a large set of channels that would never
> > really be used? 26 channels on 2.4 GHz and 194(huh!) on 5 GHz.. First
> > workaround could be to just limit those to somewhat more common set of
> > channels.
>
> Well, this is what the hw supports I guess, most channels will actually
> reported to userspace with the DISABLED flag set.

Well.. It reports channels like 2732 MHz or 6100 MHz and 5 GHz center
frequencies for every possible multiple of 5 MHz. If someone is really
using those properly, they are on a licensed band and this types of
lists are not really needed for normal users. Whether the hardware
really supports them or well, more exactly, whether all selected
components can handle these frequencies and whether the radios have been
calibrated for all of these areas is another question.

> > > > There is also a bug in hostapd which waits for ACK forever when this error occur
> > > > in i802_get_hw_feature_data().

For some reason, I do not seem to be able to reproduce this. Both iw and
hostapd were able to fetch the data using the current wireless-testing
tree..

> I recently rewrote the handling in iw completely to make it easier to
> follow, will post an equivalent patch for hostapd in a minute.

Anyway, cleanup for nl send/recv processing is certainly welcome. I've
never fully understood the steps that are used there and what to do if
anything went wrong..

--
Jouni Malinen PGP id EFC895FA

2008-09-29 10:21:23

by Jouni Malinen

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, Sep 29, 2008 at 12:01:20PM +0200, Johannes Berg wrote:

> > I've found out, that NL80211_CMD_GET_WIPHY reply doesn't fit into a message
> > socket buffer now. Used driver is ath5k.
>
> Ok, humm, I have no idea what to do. I guess we'll somehow have to make
> it possible to split it up on band or channel boundaries. But since
> those are nested it seems somewhat weird to me. Any ideas?

Isn't ath5k reporting quite a large set of channels that would never
really be used? 26 channels on 2.4 GHz and 194(huh!) on 5 GHz.. First
workaround could be to just limit those to somewhat more common set of
channels.

Sure, it would be nice to be able to handle long enough replies, but in
this particular case, I'm not sure whether the reply is that realistic.
Split on band boundary would not be enough here since the 5 GHz band
alone would probably have went beyond the size limit.

> > There is also a bug in hostapd which waits for ACK forever when this error occur
> > in i802_get_hw_feature_data().
>
> I should replace all the code there with the current code from iw, it's
> much better and actually handles all the corner cases.

I have following (completely untested) patch.. Does it look correct or
do you have something more complete that should be used here?



diff --git a/hostapd/driver_nl80211.c b/hostapd/driver_nl80211.c
index f8c83e1..9b1a0a2 100644
--- a/hostapd/driver_nl80211.c
+++ b/hostapd/driver_nl80211.c
@@ -1531,12 +1531,17 @@ static struct hostapd_hw_modes *i802_get_hw_feature_data(void *priv,
nl_cb_set(cb, NL_CB_VALID, NL_CB_CUSTOM, phy_info_handler, &result);
nl_cb_set(cb, NL_CB_ACK, NL_CB_CUSTOM, ack_wait_handler, &finished);

- err = nl_recvmsgs(drv->nl_handle, cb);
-
- if (!finished)
+ if (result.error)
+ err = -1;
+ else if (!finished)
err = nl_wait_for_ack(drv->nl_handle);
+ else
+ err = 0;
+
+ if (err >= 0)
+ err = nl_recvmsgs(drv->nl_handle, cb);

- if (err < 0 || result.error) {
+ if (err < 0) {
hostapd_free_hw_features(result.modes, *num_modes);
result.modes = NULL;
}

--
Jouni Malinen PGP id EFC895FA

2008-09-30 13:49:09

by Jouni Malinen

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, Sep 29, 2008 at 06:45:34PM +0200, Johannes Berg wrote:

> Probably depends on something about alignment or whatever, not sure. Or
> you have different hardware and the driver reports different things for
> different hw? Anyway, it shouldn't wait forever, and my patch fixes
> that.

I was unable to reproduce it and as far as I can tell, I have identical
hardware from the view point of which channels are supported. Anyway,
the cleanup/fix is reasonable regardless.

> I see you applied that, it should be ported to the wpa_supplicant driver
> too, I think.

Yes, done.

--
Jouni Malinen PGP id EFC895FA

2008-09-29 10:35:08

by Johannes Berg

[permalink] [raw]
Subject: Re: NL80211_CMD_GET_WIPHY reply doesn't fit into nl message buffer

On Mon, 2008-09-29 at 12:25 +0200, Johannes Berg wrote:

> I recently rewrote the handling in iw completely to make it easier to
> follow, will post an equivalent patch for hostapd in a minute.

How does this look?

http://johannes.sipsolutions.net/patches/hostap/all/2008-09-29-10%3a34/002-nl80211-resync.patch

Haven't tested it yet though.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part