[GIT]: Networking

[GIT]: Networking

[David Miller]

1) Build fix of 8390 layer from Alan Cox.

2) IGB driver bug fixes from Alexander Duyck:
      a) Incorrect VLAN register programming
      b) Fix RX hang condition by forcing all queues to interrupt every 2 secs
      c) ethtool -d accidently masks off interrupts, whoops...
      d) Fix setting of number of TX queues when in MSI-X only mode
      e) Remove 82576 quad adapter PCI IDs, these don't work properly yet

3) Add new device ID for MCS7830 USB adapter, from Arnd Bergmann

4) In forcedeth driver, make the checksum feature setting match what the
   hardware can actually do, from Ayaz Abdulla.

5) ibm_newemac calls dev_mc_add() before the device is even registered,
   fix from Benjamin Herrenschmidt.

6) Two atmel wireless driver fixes from Dan Williams:
   a) Try open system authentication when shared key fails.
   b) Return correct error code on request_firmware() failure

7) Two HSO driver fixes from Denis Joseph Barrow
   a) dev_kfree_skb() called twice on same packet during resume
   b) Icon-322 entry in hsi_ids[] table was incorrect

8) Eugene Teo noticed some bogus capability checks in SBNI wan
   driver, it was doing direct checks of current->euid :-)

9) rfkill_claim_show() was missing a line break in output,
   from Felipe Balbi.

10) r8169 DMA mapping leak fix from Francois Romieu, size argument
    to pci_unmap_single() was incorrect.

11) qeth driver should use -EOPNOTSUPP instead of -ENOTSUPP, from
    Ursula Braun.  Also, qeth forgets to post unicast address list
    to the hardware in some circumstances, from Frank Blaschka.

12) fs_enet_rx_napi() crash fix in fs_enet driver from Heiko Schocher.

13) Hugh Dickins fixed a brown paper bag issue in the recent ipv4
    sysctl bits from Al Viro.

14) Missing braces in atl1e driver, fix from Ilpo Jarvinen.

15) MAC80211 layer fix from Jan-Espen Pettersen so that we do not
    emit empty extended rates IE frames.

16) Four packet scheduler layer locking fixes from Jarek Poplawski:
    a) dev_graft_qdisc() locks the wrong qdisc
    b) Same problem in sch_tree_lock()
    c) Some dev_queue->qdisc assignments were missing rcu_assign_pointer()
    d) Wrong qdisc root passed to gen_replace_estimator(), thus wrong
       qdisc being locked by that code.

17) atl1 is showing problems now that TSO was enabled by default, turn
    it back off by default until we know what the problem is, from
    Jay Cliburn.

18) Fix smc91x null pointer deref in resource removal, from Jeff Garzik.

19) e100 uses plain readX() on iomap memory, from Jiri Slaby

20) Two ath5k bug fixes from Jiri Slaby:
    a) Beacon set and config can race with beacon sendng
    b) bintval needs to be setup earlier to be accurate

21) Lower verbosity of IBSS merge messages, they sometimes happen
    a lot, from John Linville.

22) Two mac80211 bug fixes from Jouni Malinen:
    a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
       IWEVASSOCREQIE has
    b) Fix debugfs entry corruption due to entries being left
       behind accidently with references to freed memory

23) __mesh_table_free() called with wrong table pointer when
    mesh_table_grow() fails, from Julia Lawall.

24) S390 LCS driver forgets to check CPA state in interrupt handler,
    resulting in incorrect behavior when recovery is driven after cable
    reconnect, fix from Klaus-D. Wacker.

25) mv643xx_eth fixes from Lennert Buytenhek:
    a) Interrupt handler needs to ACK RX irq before processing the ring
       to avoid a race that can get packets wedged and never processed.
    b) accidental double add_timer() in receive OOM handling
    c) Need to use IRQ safe locks in mv643xx_eth_poll or else we deadlock
    d) fix NULL pointer deref in rxq_process()
    e) chip has 8 byte multiple size restriction for buffers on receive,
       but this isn't being enforced everywhere it needs to be

26) Memory leak fix in claw_probe() from Martin Schwidefsky.

27) claw and ctcm drivers were non-functional because they were using
    netdev->priv as a mid-layer private pointer, but that doesn't work
    because netdev->priv is where the generic networking stores the
    private memory allocated at alloc_netdev() time.

    We have a netdev->ml_priv pointer that fits the need here, so we
    convert things to use that to fix this bug, from Peter Tiedemann.

28) TCP header size miscalculation when eliding window scaling, fix
    from Philip Love.

29) ibmveth transmits incorrect UDP checksums, fix from Santiago Leon.

30) gianfar grabs a mutex in softirq context, oops, fix from Sebastian Siewior.

31) Two more SCTP overflow fixes from Vlad Yasevich based upon feedback
    from Eugene Teo.  I have to ship these two off to -stable as well.

Please pull, thanks a lot!

The following changes since commit c2d42545774c4bba7232521d836d0793330e3a4e:
  Eilon Greenstein (1):
        bnx2x: Version update

are available in the git repository at:

  master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Alan Cox (1):
      [netdrvr] fix build issue: undefined reference to `NS8390p_init'

Alexander Duyck (5):
      ixgbe: fix vlan filtering
      igb: force all queues to interrupt once every 2 seconds
      igb: ethtool -d reads EICR which is incorrect as it is read on clear
      igb: fix setting the number of tx queues
      igb: remove 82576 quad adapter

Arnd Bergmann (1):
      net/usb/mcs7830: new device IDs

Ayaz Abdulla (1):
      forcedeth: fix checksum flag

Benjamin Herrenschmidt (1):
      ibm_newemac: Don't call dev_mc_add() before device is registered

Brice Goglin (1):
      myri10ge: update version string to 1.4.3-1.358

Dan Williams (2):
      atmel: return ENOENT on request_firmware failure
      atmel: try open system authentication too

David S. Miller (2):
      Merge branch 'davem-fixes' of master.kernel.org:/.../jgarzik/netdev-2.6
      Merge branch 'no-iwlwifi' of git://git.kernel.org/.../linville/wireless-2.6

Denis Joseph Barrow (2):
      [netdrvr] hso: icon 322 detection fix
      [netdrvr] hso: dev_kfree_skb crash fix

Eugene Teo (1):
      wan: Missing capability checks in sbni_ioctl()

Felipe Balbi (1):
      net: rfkill: add missing line break

Francois Romieu (1):
      r8169: balance pci_map / pci_unmap pair

Frank Blaschka (2):
      qeth: l2 write unicast list to hardware
      qeth: preallocated header account offset

Heiko Schocher (1):
      fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()

Hugh Dickins (1):
      ipv4: mode 0555 in ipv4_skeleton

Ilpo Järvinen (1):
      atl1e: multistatement if missing braces

Jan-Espen Pettersen (1):
      mac80211: don't send empty extended rates IE

Jarek Poplawski (4):
      pkt_sched: Fix dev_graft_qdisc() locking
      pkt_sched: Use rcu_assign_pointer() to change dev_queue->qdisc
      pkt_sched: Fix gen_estimator locks
      pkt_sched: Fix sch_tree_lock()

Jay Cliburn (1):
      atl1: disable TSO by default

Jeff Garzik (2):
      Merge branch 'for-2.6.27' of git://git.marvell.com/mv643xx_eth into upstream-fixes
      [netdrvr] smc91x: fix resource removal (null ptr deref)

Jiri Slaby (3):
      Ath5k: lock beacons
      Ath5k: fix bintval setup
      e100, fix iomap read

John W. Linville (1):
      mac80211: quiet chatty IBSS merge message

Jouni Malinen (2):
      mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
      mac80211: Fix debugfs file add/del for netdev

Julia Lawall (1):
      net/mac80211/mesh.c: correct the argument to __mesh_table_free

Klaus-D. Wacker (1):
      LCS recovery dumps when cable reconnect

Lennert Buytenhek (6):
      mv643xx_eth: fix NAPI 'rotting packet' issue
      mv643xx_eth: fix double add_timer() on the receive oom timer
      mv643xx_eth: fix inconsistent lock semantics
      mv643xx_eth: fix NULL pointer dereference in rxq_process()
      mv643xx_eth: enforce multiple-of-8-bytes receive buffer size restriction
      mv643xx_eth: bump version to 1.3

Martin Schwidefsky (1):
      claw: fix memory leak in claw_probe.

Mike Frysinger (1):
      Blackfin EMAC Driver: the BF526 also supports the MAC,

Oliver Martin (1):
      net/usb/mcs7830: add set_mac_address

Peter Tiedemann (2):
      claw: netdev->priv vs. netdev->ml_priv
      ctcm: netdev->priv vs. netdev->ml_priv

Philip Love (1):
      tcp: fix tcp header size miscalculation when window scale is unused

Santiago Leon (1):
      ibmveth: fix bad UDP checksums

Sebastian Siewior (1):
      net: don't grab a mutex within a timer context in gianfar

Takashi Iwai (1):
      drivers/net/skfp/ess.c: fix compile warnings

Ursula Braun (1):
      qeth: use -EOPNOTSUPP instead of -ENOTSUPP.

Vlad Yasevich (2):
      sctp: correct bounds check in sctp_setsockopt_auth_key
      sctp: fix random memory dereference with SCTP_HMAC_IDENT option.

 arch/powerpc/include/asm/cpm2.h    |    5 ++
 drivers/net/Kconfig                |    6 +-
 drivers/net/atl1e/atl1e_main.c     |    3 +-
 drivers/net/atlx/atl1.c            |    1 -
 drivers/net/e100.c                 |    4 +-
 drivers/net/forcedeth.c            |    4 +-
 drivers/net/fs_enet/fs_enet-main.c |    8 ++++
 drivers/net/fs_enet/mac-scc.c      |    8 +++-
 drivers/net/gianfar.c              |   22 ++++++++--
 drivers/net/gianfar.h              |    1 +
 drivers/net/ibm_newemac/core.c     |    6 +-
 drivers/net/ibmveth.c              |    5 +-
 drivers/net/igb/e1000_82575.c      |    1 -
 drivers/net/igb/e1000_hw.h         |    1 -
 drivers/net/igb/igb_ethtool.c      |   17 +++-----
 drivers/net/igb/igb_main.c         |   25 +++++------
 drivers/net/ixgbe/ixgbe_main.c     |    8 ++-
 drivers/net/mv643xx_eth.c          |   35 +++++++++-------
 drivers/net/myri10ge/myri10ge.c    |    2 +-
 drivers/net/r8169.c                |    2 +-
 drivers/net/skfp/ess.c             |    6 +-
 drivers/net/smc91x.c               |    2 +-
 drivers/net/usb/hso.c              |    3 +-
 drivers/net/usb/mcs7830.c          |   47 +++++++++++++++++++++-
 drivers/net/wan/sbni.c             |    8 ++--
 drivers/net/wd.c                   |    2 +-
 drivers/net/wireless/ath5k/base.c  |   23 ++++++++---
 drivers/net/wireless/ath5k/base.h  |    1 +
 drivers/net/wireless/atmel.c       |   51 ++++++++++++++---------
 drivers/s390/net/claw.c            |   79 +++++++++++++++++------------------
 drivers/s390/net/ctcm_fsms.c       |   56 +++++++++++++-------------
 drivers/s390/net/ctcm_main.c       |   24 +++++-----
 drivers/s390/net/ctcm_main.h       |    9 ++--
 drivers/s390/net/ctcm_mpc.c        |   46 ++++++++++----------
 drivers/s390/net/lcs.c             |    3 +-
 drivers/s390/net/qeth_core.h       |    1 +
 drivers/s390/net/qeth_core_main.c  |    2 +-
 drivers/s390/net/qeth_l2_main.c    |   27 ++++++++++--
 drivers/s390/net/qeth_l3_sys.c     |    2 +-
 include/net/sch_generic.h          |   12 +++++-
 net/ipv4/route.c                   |    4 +-
 net/ipv4/tcp_output.c              |    6 ++-
 net/mac80211/debugfs_netdev.c      |   24 +++++-----
 net/mac80211/ieee80211_i.h         |    6 +++
 net/mac80211/mesh.c                |    2 +-
 net/mac80211/mlme.c                |   52 +++++------------------
 net/rfkill/rfkill.c                |    2 +-
 net/sched/sch_api.c                |   18 ++++++--
 net/sched/sch_cbq.c                |    4 +-
 net/sched/sch_generic.c            |    4 +-
 net/sched/sch_hfsc.c               |    4 +-
 net/sched/sch_htb.c                |    4 +-
 net/sctp/auth.c                    |    3 +
 net/sctp/socket.c                  |    8 ++-
 54 files changed, 413 insertions(+), 296 deletions(-)

Re: [GIT]: Networking

[Alex Williamson]

On Wed, 2008-08-27 at 16:46 -0700, David Miller wrote:

> 22) Two mac80211 bug fixes from Jouni Malinen:
>     a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
>        IWEVASSOCREQIE has

This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:

mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [GIT]: Networking

[Linus Torvalds]

On Fri, 5 Sep 2008, Alex Williamson wrote:

> On Wed, 2008-08-27 at 16:46 -0700, David Miller wrote:
> 
> > 22) Two mac80211 bug fixes from Jouni Malinen:
> >     a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
> >        IWEVASSOCREQIE has
> 
> This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
> back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> 
> mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM

Grr. I'd love to say "I told you so", and write another rant about -rc 
series patches. But I'm too lazy, so people - please mentally insert my 
standard rant here.

David/Jouni - just revert it?

		Linus

Re: [GIT]: Networking

[John W. Linville]

On Fri, Sep 05, 2008 at 10:45:11AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 5 Sep 2008, Alex Williamson wrote:
> 
> > On Wed, 2008-08-27 at 16:46 -0700, David Miller wrote:
> > 
> > > 22) Two mac80211 bug fixes from Jouni Malinen:
> > >     a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
> > >        IWEVASSOCREQIE has
> > 
> > This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
> > back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> > 
> > mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
> 
> Grr. I'd love to say "I told you so", and write another rant about -rc 
> series patches. But I'm too lazy, so people - please mentally insert my 
> standard rant here.
> 
> David/Jouni - just revert it?

Yes, just revert it.

Jouni, feel free to send me a new version for 2.6.28.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [GIT]: Networking

[Jouni Malinen]

Alex Williamson wrote:
> On Wed, 2008-08-27 at 16:46 -0700, David Miller wrote:
> 
>> 22) Two mac80211 bug fixes from Jouni Malinen:
>>     a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
>>        IWEVASSOCREQIE has

By the way, that description is incorrect; the change was in the other 
direction (i.e., to use IWSSOCREQIE).

> This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
> back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> 
> mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM

Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved 
all WEXT cases. This code is (and was) using wireless_send_event() and I 
did not find clear changes to its use in Dave's patch set. Was that 
supposed to be fixed with the compat ioctl patches? I'm not very 
familiar with this area and don't have an easy way to test this now (I'm 
traveling and don't have access to a 64/32-bit setup).

As far as I can tell, the commit mentioned here is correct in itself, 
but it looks like the WEXT code would not handle something properly for 
wireless_send_event(). I'm not sure why IWEVCUSTOM would work any 
better, but well, maybe it does not have some fields that get wrong in 
64/32 case or the previous working case ended up getting the 
too-long-buffer error which prevented the message from being processed 
in userspace).

What exactly does "breaks wireless" mean here?

As far as resolving this quickly is concerned, reverting the change is 
fine; this is not a critical issue with most use cases. Anyway, this 
should really be fixed eventually, but it looks like someone would need 
to fix WEXT for wireless_send_event() first..

- Jouni

Re: [GIT]: Networking

[David Miller]

I'm so entirely tired of reading these 300+ column emails today that
I'm just flat out refusing to read this one.

People, fix your setup please!  And if you have to get your email
client to auto format your outgoing email text for you, that's fine.
Although I can't understand why folks are too lazy to type enter every
80 columns or so.

It's funny how something so fundamental that everyone could get
right 15 years ago, is now such an epidemic problem. :-/

Re: [GIT]: Networking

[Jouni Malinen]

On Mon, Sep 08, 2008 at 07:46:27PM -0700, David Miller wrote:
> I'm so entirely tired of reading these 300+ column emails today that
> I'm just flat out refusing to read this one.
> 
> People, fix your setup please!  And if you have to get your email
> client to auto format your outgoing email text for you, that's fine.
> Although I can't understand why folks are too lazy to type enter every
> 80 columns or so.

Hmm.. I was using my temporary thunderbird setup and it is configured to
wordwrap at 72 character lines.. The mail server may have done something
odd, though. The version of the message I received directly at w1.fi was
word wrapped, so I have no idea what happened here. Anyway, since the
message was discussing your patchset, here's another version from mutt
(and another mail server) and which will hopefully show up in more
reasonable format.


Alex Williamson wrote:
> On Wed, 2008-08-27 at 16:46 -0700, David Miller wrote:
> 
>> 22) Two mac80211 bug fixes from Jouni Malinen:
>>     a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
>>        IWEVASSOCREQIE has

By the way, that description is incorrect; the change was in the other 
direction (i.e., to use IWSSOCREQIE).

> This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
> back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> 
> mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM

Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved 
all WEXT cases. This code is (and was) using wireless_send_event() and I 
did not find clear changes to its use in Dave's patch set. Was that 
supposed to be fixed with the compat ioctl patches? I'm not very 
familiar with this area and don't have an easy way to test this now (I'm 
traveling and don't have access to a 64/32-bit setup).

As far as I can tell, the commit mentioned here is correct in itself, 
but it looks like the WEXT code would not handle something properly for 
wireless_send_event(). I'm not sure why IWEVCUSTOM would work any 
better, but well, maybe it does not have some fields that get wrong in 
64/32 case or the previous working case ended up getting the 
too-long-buffer error which prevented the message from being processed 
in userspace).

What exactly does "breaks wireless" mean here?

As far as resolving this quickly is concerned, reverting the change is 
fine; this is not a critical issue with most use cases. Anyway, this 
should really be fixed eventually, but it looks like someone would need 
to fix WEXT for wireless_send_event() first..

- Jouni

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [GIT]: Networking

[Jouni Malinen]

On Mon, Sep 08, 2008 at 09:08:08PM -0600, Alex Williamson wrote:
> NetworkManager can see access points, but doesn't get much further than
> that.  From an end user perspective, similar to how it behaved in
> 2.6.26, before Dave's wext compat fixes.

Are you using 802.11n? Dave's patches fixed scan result processing, but
it looks like they may not have fixed wireless_send_event() processing.
It would be interesting to see what wpa_supplicant debug log shows
here. I would assume the device was able to associate with the AP, but
something went wrong when the association information (the data that
was changed to use binary format instead of text-based custom iw event).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [GIT]: Networking

[Alex Williamson]

On Tue, 2008-09-09 at 05:44 +0300, Jouni Malinen wrote:
> 
> What exactly does "breaks wireless" mean here?

NetworkManager can see access points, but doesn't get much further than
that.  From an end user perspective, similar to how it behaved in
2.6.26, before Dave's wext compat fixes.

Alex

Re: [GIT]: Networking

[David Miller]

From: Jouni Malinen <j@w1.fi>
Date: Mon, 8 Sep 2008 19:55:25 -0700

> On Mon, Sep 08, 2008 at 07:46:27PM -0700, David Miller wrote:
> > This one breaks wireless with 32bit userspace/64bit kernel.  Bisected
> > back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> > 
> > mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
> 
> Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved 
> all WEXT cases. This code is (and was) using wireless_send_event() and I 
> did not find clear changes to its use in Dave's patch set. Was that 
> supposed to be fixed with the compat ioctl patches? I'm not very 
> familiar with this area and don't have an easy way to test this now (I'm 
> traveling and don't have access to a 64/32-bit setup).

If we're talking about the netlink emission of WEXT blobs, then such
bits cannot be fixed unfortunately, because via netlink we don't know
in the message generating context what kind of process will receive
the message.

In fact, when broadcasting a netlink message, applications of different
dispositions can want to receive the message.

So in essence netlink cases cannot be fixed for COMPAT handling,
rather, netlink protocols must be designed to be COMPAT agnostic from
the beginning, and use fixed sized types only.  WEXT was not.

Re: [GIT]: Networking

[Jouni Malinen]

On Mon, Sep 08, 2008 at 08:43:23PM -0700, David Miller wrote:

> If we're talking about the netlink emission of WEXT blobs, then such
> bits cannot be fixed unfortunately, because via netlink we don't know
> in the message generating context what kind of process will receive
> the message.

OK. Interesting point here is that the old code was using IWEVCUSTOM
which is defined as having header_type IW_HEADER_TYPE_POINT and so are
the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
max_tokens specifying different maximum length for the data. Maybe the
old code was also broken, but wpa_supplicant handled the bogus data
without causing problems (text parsing failing instead of some
parameters being set based on bogus binary data).

> In fact, when broadcasting a netlink message, applications of different
> dispositions can want to receive the message.
> 
> So in essence netlink cases cannot be fixed for COMPAT handling,
> rather, netlink protocols must be designed to be COMPAT agnostic from
> the beginning, and use fixed sized types only.  WEXT was not.

I haven't looked how IW_HEADER_TYPE_POINT headers get encoded with
wireless_send_event(), but it sounds likely something there gets
different field size. It sounds like there is not really a good
solution for this with the current iw event types and should we want to
get the original issue fixed, something new would need to be
specified.. Would people be fine with extending wireless_send_event()
with new event types that use fixed sized fields or is someone going to
be interesting in providing a better replacement for this functionality?

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [GIT]: Networking

[David Miller]

From: Jouni Malinen <j@w1.fi>
Date: Mon, 8 Sep 2008 21:05:25 -0700

> Would people be fine with extending wireless_send_event() with new
> event types that use fixed sized fields or is someone going to be
> interesting in providing a better replacement for this
> functionality?

I thought this was the idea behind nl80211?  To be a new netlink
interface for wireless, one that actually is designed correctly
from the start and thus can avoid all of these problems.

Re: [GIT]: Networking

[Jouni Malinen]

On Mon, Sep 08, 2008 at 09:15:48PM -0700, David Miller wrote:
> From: Jouni Malinen <j@w1.fi>
> > Would people be fine with extending wireless_send_event() with new
> > event types that use fixed sized fields or is someone going to be
> > interesting in providing a better replacement for this
> > functionality?

> I thought this was the idea behind nl80211?  To be a new netlink
> interface for wireless, one that actually is designed correctly
> from the start and thus can avoid all of these problems.

Well, this wireless_send_event() is the part of WEXT that no one has
worked with replacing yet as far as I'm aware.. The currently available
infrastructure in nl80211 can be relatively easily extended to handle
all other functionality, but unless I've missed something, this sending
of event messages to user space would require new type of functionality
for nl8211. In other words, sure, it can be done, but we are not there
yet.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [GIT]: Networking (WEXT events and 64/32 compat)

[Jouni Malinen]

On Mon, Sep 08, 2008 at 09:05:25PM -0700, Jouni Malinen wrote:
> OK. Interesting point here is that the old code was using IWEVCUSTOM
> which is defined as having header_type IW_HEADER_TYPE_POINT and so are
> the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
> max_tokens specifying different maximum length for the data. Maybe the
> old code was also broken, but wpa_supplicant handled the bogus data
> without causing problems (text parsing failing instead of some
> parameters being set based on bogus binary data).

I was able to test this with a 64/32-bit setup and confirmed that both
IWEVCUSTOM and the new IWEVASSOCREQIE/IWEVASSOCRESPIE are indeed failing
when using 32-bit binary in userspace (and work with 64-bit). The length
field is parsed incorrectly for all these events.

wpa_supplicant has code for rejecting IWEVCUSTOM events that have too
large a value in the length field. However, same validation is not done
for IWEVASSOCREQIE/IWEVASSOCRESPIE (i.e., wpa_supplicant relies on
kernel providing the correct value for the length field). As the end
result, the new IWEVASSOCREQIE/IWEVASSOCRESPIE events will trigger a
segmentation fault in wpa_supplicant when the buffer is being read way
beyond its end.

I'll make wpa_supplicant validate the length field for all WEXT events
to avoid the crash. This was enough to make association work with the
reverted mac80211 patch since the values from these association info
events are not critical for many use cases.

Since we cannot fix the kernel code to handle the WEXT events for all
cases (e.g., 64-bit kernel and mix of 32-bit and 64-bit userspace
apps), I could consider adding a workaround in wpa_supplicant to handle
the 64-bit data being received in 32-bit app.. However, that would not
fix problems for anyone using older versions of wpa_supplicant.

Would it be acceptable to ever enable use of IWEVASSOCREQIE /
IWEVSSOCRESPIE in kernel if the workaround were available in new
wpa_supplicant versions? Or should we try to add a new WEXT event
type that uses fixed size for the length field and then replace the old
IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
64/32-bit case (wpa_supplicant just knows how to avoid processing that
bogus event data)?

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [GIT]: Networking (WEXT events and 64/32 compat)

[David Miller]

From: Jouni Malinen <j@w1.fi>
Date: Wed, 17 Sep 2008 12:11:28 -0700

> Would it be acceptable to ever enable use of IWEVASSOCREQIE /
> IWEVSSOCRESPIE in kernel if the workaround were available in new
> wpa_supplicant versions? Or should we try to add a new WEXT event
> type that uses fixed size for the length field and then replace the old
> IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
> 64/32-bit case (wpa_supplicant just knows how to avoid processing that
> bogus event data)?

Moving to a new event with a strictly sized datastructure, instead of
one that has variable sized members like pointers and crap which are
impossible to compat layer'ify, is indeed my preference.

But in that case, we might as well make nl80211 usable instead.

We'll always have those existing wpa_supplicant binaries out there, we
can't break them.  And the size checks wpa_supplicant makes is a BOGUS
and REDICULIOUS way to get these malformed objects "supported" and
"usable".

Re: [GIT]: Networking (WEXT events and 64/32 compat)

[John W. Linville]

On Wed, Sep 17, 2008 at 01:11:33PM -0700, David Miller wrote:
> From: Jouni Malinen <j@w1.fi>
> Date: Wed, 17 Sep 2008 12:11:28 -0700
> 
> > Would it be acceptable to ever enable use of IWEVASSOCREQIE /
> > IWEVSSOCRESPIE in kernel if the workaround were available in new
> > wpa_supplicant versions? Or should we try to add a new WEXT event
> > type that uses fixed size for the length field and then replace the old
> > IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
> > 64/32-bit case (wpa_supplicant just knows how to avoid processing that
> > bogus event data)?
> 
> Moving to a new event with a strictly sized datastructure, instead of
> one that has variable sized members like pointers and crap which are
> impossible to compat layer'ify, is indeed my preference.
> 
> But in that case, we might as well make nl80211 usable instead.

This is, of course, my opinion as well.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [GIT]: Networking (WEXT events and 64/32 compat)

[Jouni Malinen]

On Wed, Sep 17, 2008 at 01:11:33PM -0700, David Miller wrote:
> Moving to a new event with a strictly sized datastructure, instead of
> one that has variable sized members like pointers and crap which are
> impossible to compat layer'ify, is indeed my preference.
> 
> But in that case, we might as well make nl80211 usable instead.

Would you be fine with continuing to use IFLA_WIRELESS for this or
should we reserve a new identifier for the nl80211 case? I'm assuming
that the base mechanism would continue to remain as a broadcast
rtnetlink message and the main difference to WEXT is in defining all
events as data with fixed size fields instead of C structures.

IFLA_WIRELESS messages start with two fixed size fields (16-bit len
and cmd) which would allow us to reserve a new cmd value for nl80211
messaages and then we could even share the helper functions in
wireless/wext.c and just replace wireless_send_event() with a new
function that generates the new event type.

As a first porting step, wireless_send_event() could be extended to send
both messages so that we do not need to modify all drivers to use the
new mechanism in the beginning (and the old WEXT events would continue
to be available for anyone who uses 32/32-bit or 64/64-bit
kernel/userspace).

As far as userspace is concerned, I would assume apps would eventually
start moving to using the new events. As an example, wpa_supplicant has
support for using either WEXT or nl80211 (though, this is still using
WEXT for places that nl80211 does not support yet) and I would likely
leave the WEXT case as-is and modify nl80211 interface to use only the
new event messages.

-- 
Jouni Malinen                                            PGP id EFC895FA