1. 30 Apr, 2012 1 commit
  2. 15 Apr, 2012 4 commits
  3. 11 Apr, 2012 1 commit
    • Herbert Xu's avatar
      bridge: Do not send queries on multicast group leaves · 996304bb
      Herbert Xu authored
      
      
      As it stands the bridge IGMP snooping system will respond to
      group leave messages with queries for remaining membership.
      This is both unnecessary and undesirable.  First of all any
      multicast routers present should be doing this rather than us.
      What's more the queries that we send may end up upsetting other
      multicast snooping swithces in the system that are buggy.
      
      In fact, we can simply remove the code that send these queries
      because the existing membership expiry mechanism doesn't rely
      on them anyway.
      
      So this patch simply removes all code associated with group
      queries in response to group leave messages.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      996304bb
  4. 05 Mar, 2012 1 commit
  5. 11 Dec, 2011 1 commit
  6. 03 Dec, 2011 1 commit
  7. 22 Nov, 2011 1 commit
  8. 16 Nov, 2011 1 commit
  9. 13 Nov, 2011 1 commit
  10. 24 Aug, 2011 2 commits
  11. 24 Jun, 2011 1 commit
    • Herbert Xu's avatar
      bridge: Only flood unregistered groups to routers · bd4265fe
      Herbert Xu authored
      
      
      The bridge currently floods packets to groups that we have never
      seen before to all ports.  This is not required by RFC4541 and
      in fact it is not desirable in environment where traffic to
      unregistered group is always present.
      
      This patch changes the behaviour so that we only send traffic
      to unregistered groups to ports marked as routers.
      
      The user can always force flooding behaviour to any given port
      by marking it as a router.
      
      Note that this change does not apply to traffic to 224.0.0.X
      as traffic to those groups must always be flooded to all ports.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd4265fe
  12. 16 Jun, 2011 2 commits
    • Fernando Luis Vázquez Cao's avatar
      IGMP snooping: set mrouters_only flag for IPv6 traffic properly · fc2af6c7
      Fernando Luis Vázquez Cao authored
      
      
      Upon reception of a MGM report packet the kernel sets the mrouters_only flag
      in a skb that is a clone of the original skb, which means that the bridge
      loses track of MGM packets (cb buffers are tied to a specific skb and not
      shared) and it ends up forwading join requests to the bridge interface.
      
      This can cause unexpected membership timeouts and intermitent/permanent loss
      of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
      
          A snooping switch should forward IGMP Membership Reports only to
          those ports where multicast routers are attached.
          [...]
          Sending membership reports to other hosts can result, for IGMPv1
          and IGMPv2, in unintentionally preventing a host from joining a
          specific multicast group.
      
      Signed-off-by: default avatarFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@conan.davemloft.net>
      fc2af6c7
    • Fernando Luis Vázquez Cao's avatar
      IGMP snooping: set mrouters_only flag for IPv4 traffic properly · 62b2bcb4
      Fernando Luis Vázquez Cao authored
      
      
      Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
      mrouters_only flag in a skb that may be a clone of the original skb, which
      means that sometimes the bridge loses track of membership report packets (cb
      buffers are tied to a specific skb and not shared) and it ends up forwading
      join requests to the bridge interface.
      
      This can cause unexpected membership timeouts and intermitent/permanent loss
      of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
      
          A snooping switch should forward IGMP Membership Reports only to
          those ports where multicast routers are attached.
          [...]
          Sending membership reports to other hosts can result, for IGMPv1
          and IGMPv2, in unintentionally preventing a host from joining a
          specific multicast group.
      
      Signed-off-by: default avatarFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Tested-by: default avatarHayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@conan.davemloft.net>
      62b2bcb4
  13. 22 Apr, 2011 1 commit
  14. 30 Mar, 2011 1 commit
    • Linus Lüssing's avatar
      bridge: mcast snooping, fix length check of snooped MLDv1/2 · ff9a57a6
      Linus Lüssing authored
      
      
      "len = ntohs(ip6h->payload_len)" does not include the length of the ipv6
      header itself, which the rest of this function assumes, though.
      
      This leads to a length check less restrictive as it should be in the
      following line for one thing. For another, it very likely leads to an
      integer underrun when substracting the offset and therefore to a very
      high new value of 'len' due to its unsignedness. This will ultimately
      lead to the pskb_trim_rcsum() practically never being called, even in
      the cases where it should.
      
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff9a57a6
  15. 22 Mar, 2011 1 commit
  16. 22 Feb, 2011 6 commits
  17. 12 Feb, 2011 1 commit
    • Herbert Xu's avatar
      bridge: Replace mp->mglist hlist with a bool · 8a870178
      Herbert Xu authored
      
      
      As it turns out we never need to walk through the list of multicast
      groups subscribed by the bridge interface itself (the only time we'd
      want to do that is when we shut down the bridge, in which case we
      simply walk through all multicast groups), we don't really need to
      keep an hlist for mp->mglist.
      
      This means that we can replace it with just a single bit to indicate
      whether the bridge interface is subscribed to a group.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a870178
  18. 11 Feb, 2011 2 commits
    • Herbert Xu's avatar
      bridge: Fix timer typo that may render snooping less effective · 24f9cdcb
      Herbert Xu authored
      
      
      In a couple of spots where we are supposed to modify the port
      group timer (p->timer) we instead modify the bridge interface
      group timer (mp->timer).
      
      The effect of this is mostly harmless.  However, it can cause
      port subscriptions to be longer than they should be, thus making
      snooping less effective.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24f9cdcb
    • Herbert Xu's avatar
      bridge: Fix mglist corruption that leads to memory corruption · 6b0d6a9b
      Herbert Xu authored
      
      
      The list mp->mglist is used to indicate whether a multicast group
      is active on the bridge interface itself as opposed to one of the
      constituent interfaces in the bridge.
      
      Unfortunately the operation that adds the mp->mglist node to the
      list neglected to check whether it has already been added.  This
      leads to list corruption in the form of nodes pointing to itself.
      
      Normally this would be quite obvious as it would cause an infinite
      loop when walking the list.  However, as this list is never actually
      walked (which means that we don't really need it, I'll get rid of
      it in a subsequent patch), this instead is hidden until we perform
      a delete operation on the affected nodes.
      
      As the same node may now be pointed to by more than one node, the
      delete operations can then cause modification of freed memory.
      
      This was observed in practice to cause corruption in 512-byte slabs,
      most commonly leading to crashes in jbd2.
      
      Thanks to Josef Bacik for pointing me in the right direction.
      
      Reported-by: default avatarIan Page Hands <ihands@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b0d6a9b
  19. 03 Jan, 2011 1 commit
    • Tomas Winkler's avatar
      bridge: fix br_multicast_ipv6_rcv for paged skbs · 9d89081d
      Tomas Winkler authored
      use pskb_may_pull to access ipv6 header correctly for paged skbs
      It was omitted in the bridge code leading to crash in blind
      __skb_pull
      
      since the skb is cloned undonditionally we also simplify the
      the exit path
      
      this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
      
      
      
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
      Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
      Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
      Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
      Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
      Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: approvals binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
      Dec 15 14:36:41 User-PC kernel: [175576.122712]
      Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G        W   2.6.37-rc5-wl+ #3 1015PE/1016P
      Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
      Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
      Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
      Dec 15 14:36:41 User-PC kernel: [175576.123737]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
      Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
      Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01087d8>] ? sched_clock+0x8/0x10
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0138264>] ? enqueue_entity+0x174/0x440
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e451>] ? sched_clock_cpu+0x131/0x190
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0524fc1>] ? nf_iterate+0x71/0x90
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04f7a30>] ? skb_copy_bits+0x110/0x210
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e242>] ? sched_clock_local+0xb2/0x190
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c012b688>] ? default_spin_lock_flags+0x8/0x10
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150d05>] ? tasklet_action+0xc5/0x100
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150a07>] ? __do_softirq+0x97/0x1d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150970>] ? __do_softirq+0x0/0x1d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  <IRQ>
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01508f5>] ? irq_exit+0x65/0x70
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05df062>] ? do_IRQ+0x52/0xc0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01036b0>] ? common_interrupt+0x30/0x38
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c03a1fc2>] ? intel_idle+0xc2/0x160
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0101dea>] ? cpu_idle+0x8a/0xf0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d2702>] ? start_secondary+0x1e8/0x1ee
      
      Cc: David Miller <davem@davemloft.net>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d89081d
  20. 16 Dec, 2010 1 commit
  21. 10 Dec, 2010 1 commit
  22. 15 Nov, 2010 1 commit
  23. 31 Jul, 2010 1 commit
  24. 15 Jul, 2010 1 commit
  25. 05 Jul, 2010 1 commit
  26. 16 May, 2010 1 commit
  27. 27 Apr, 2010 3 commits