12 Dec, 2011

1 commit


04 Dec, 2011

1 commit

  • While parsing through IPv6 extension headers, fragment headers are
    skipped making them invisible to the caller. This reports the
    fragment offset of the last header in order to make it possible to
    determine whether the packet is fragmented and, if so whether it is
    a first or last fragment.

    Signed-off-by: Jesse Gross

    Jesse Gross
     

23 Nov, 2011

1 commit


17 Nov, 2011

1 commit

  • Bridge multicast snooping of ICMPv6 would incorrectly report a checksum problem
    when used with Ethernet devices like sky2 that use CHECKSUM_COMPLETE.
    When bytes are removed from skb, the computed checksum needs to be adjusted.

    Signed-off-by: Stephen Hemminger
    Tested-by: Martin Volf
    Signed-off-by: David S. Miller

    stephen hemminger
     

14 Nov, 2011

1 commit

  • multicast_lock is taken in softirq context, so we should use
    spin_lock_bh() in userspace.

    call-chain in softirq context:
    run_timer_softirq()
    br_multicast_query_expired()

    call-chain in userspace:
    sysfs_write_file()
    store_multicast_snooping()
    br_multicast_toggle()

    Signed-off-by: Andrew Vagin
    Signed-off-by: David S. Miller

    Andrey Vagin
     

25 Aug, 2011

2 commits


25 Jun, 2011

1 commit

  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

17 Jun, 2011

2 commits

  • 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: Fernando Luis Vazquez Cao
    Signed-off-by: David S. Miller

    Fernando Luis Vázquez Cao
     
  • 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: Fernando Luis Vazquez Cao
    Tested-by: Hayato Kakuta
    Signed-off-by: David S. Miller

    Fernando Luis Vázquez Cao
     

23 Apr, 2011

1 commit


30 Mar, 2011

1 commit

  • "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: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     

23 Mar, 2011

1 commit

  • The ipv6_dev_get_saddr() is currently called with an uninitialized
    destination address. Although in tests it usually seemed to nevertheless
    always fetch the right source address, there seems to be a possible race
    condition.

    Therefore this commit changes this, first setting the destination
    address and only after that fetching the source address.

    Reported-by: Jan Beulich
    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     

23 Feb, 2011

6 commits

  • Currently the bridge multicast snooping feature periodically issues
    IPv6 general multicast listener queries to sense the absence of a
    listener.

    For this, it uses :: as its source address - however RFC 2710 requires:
    "To be valid, the Query message MUST come from a link-local IPv6 Source
    Address". Current Linux kernel versions seem to follow this requirement
    and ignore our bogus MLD queries.

    With this commit a link local address from the bridge interface is being
    used to issue the MLD query, resulting in other Linux devices which are
    multicast listeners in the network to respond with a MLD response (which
    was not the case before).

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • Map the IPv6 header's destination multicast address to an ethernet
    source address instead of the MLD queries multicast address.

    For instance for a general MLD query (multicast address in the MLD query
    set to ::), this would wrongly be mapped to 33:33:00:00:00:00, although
    an MLD queries destination MAC should always be 33:33:00:00:00:01 which
    matches the IPv6 header's multicast destination ff02::1.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • Currently the multicast bridge snooping support is not active for
    link local multicast. I assume this has been done to leave
    important multicast data untouched, like IPv6 Neighborhood Discovery.

    In larger, bridged, local networks it could however be desirable to
    optimize for instance local multicast audio/video streaming too.

    With the transient flag in IPv6 multicast addresses we have an easy
    way to optimize such multimedia traffic without tempering with the
    high priority multicast data from well-known addresses.

    This patch alters the multicast bridge snooping for IPv6, to take
    effect for transient multicast addresses instead of non-link-local
    addresses.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • The nsrcs number is 2 Byte wide, therefore we need to call ntohs()
    before using it.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • We actually want a pointer to the grec_nsrcr and not the following
    field. Otherwise we can get very high values for *nsrcs as the first two
    bytes of the IPv6 multicast address are being used instead, leading to
    a failing pskb_may_pull() which results in MLDv2 reports not being
    parsed.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • The protocol type for IPv6 entries in the hash table for multicast
    bridge snooping is falsely set to ETH_P_IP, marking it as an IPv4
    address, instead of setting it to ETH_P_IPV6, which results in negative
    look-ups in the hash table later.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     

12 Feb, 2011

3 commits

  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • 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: Ian Page Hands
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

05 Jan, 2011

1 commit


04 Jan, 2011

1 commit

  • 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:[] 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] [] ? sched_clock+0x8/0x10
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? enqueue_entity+0x174/0x440
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? sched_clock_cpu+0x131/0x190
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? select_task_rq_fair+0x2ad/0x730
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? nf_iterate+0x71/0x90
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x184/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x0/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame+0x189/0x230 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x0/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame+0x0/0x230 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __netif_receive_skb+0x1b6/0x5b0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? skb_copy_bits+0x110/0x210
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? netif_receive_skb+0x6f/0x80
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __netif_receive_skb+0x380/0x5b0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? sched_clock_local+0xb2/0x190
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? default_spin_lock_flags+0x8/0x10
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_rx+0x2a4/0x830 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __rcu_process_callbacks+0x201/0x2d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? tasklet_action+0xc5/0x100
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __do_softirq+0x97/0x1d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? nmi_stack_correct+0x2f/0x34
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __do_softirq+0x0/0x1d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? irq_exit+0x65/0x70
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? do_IRQ+0x52/0xc0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? common_interrupt+0x30/0x38
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? intel_idle+0xc2/0x160
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? cpuidle_idle_call+0x6b/0x100
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? cpu_idle+0x8a/0xf0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? start_secondary+0x1e8/0x1ee

    Cc: David Miller
    Cc: Johannes Berg
    Cc: Stephen Hemminger
    Signed-off-by: Tomas Winkler
    Signed-off-by: David S. Miller

    Tomas Winkler
     

18 Dec, 2010

1 commit


17 Dec, 2010

1 commit


11 Dec, 2010

1 commit


16 Nov, 2010

1 commit


31 Jul, 2010

1 commit


16 Jul, 2010

1 commit

  • ipv6_skip_exthdr() can return error code that is below zero.
    'offset' is unsigned, so it makes no sense.
    ipv6_skip_exthdr() returns 'int' so we can painlessly change type of
    offset to int.

    Signed-off-by: Kulikov Vasiliy
    Acked-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Kulikov Vasiliy
     

06 Jul, 2010

1 commit

  • On Tue, Jul 06, 2010 at 08:48:35AM +0800, Herbert Xu wrote:
    >
    > bridge: Restore NULL check in br_mdb_ip_get

    Resend with proper attribution.

    bridge: Restore NULL check in br_mdb_ip_get

    Somewhere along the line the NULL check in br_mdb_ip_get went
    AWOL, causing crashes when we receive an IGMP packet with no
    multicast table allocated.

    This patch restores it and ensures all br_mdb_*_get functions
    use it.

    Reported-by: Frank Arnold
    Signed-off-by: Herbert Xu

    Thanks,
    Signed-off-by: David S. Miller

    Herbert Xu
     

16 May, 2010

1 commit


11 May, 2010

1 commit


28 Apr, 2010

6 commits


27 Apr, 2010

1 commit