1. 03 11月, 2016 2 次提交
    • S
      firewire: net: fix fragmented datagram_size off-by-one · e9300a4b
      Stefan Richter 提交于
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
      
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
      
          ether1394_tx() /* transmit */
              ether1394_encapsulate_prep()
                  hdr->ff.dg_size = dg_size - 1;
      
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
              else
                  dg_size = hdr->sf.dg_size + 1;
      
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      
      So let's fix firewire-net's datagram_size accessors.
      
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e9300a4b
    • S
      firewire: net: guard against rx buffer overflows · 667121ac
      Stefan Richter 提交于
      The IP-over-1394 driver firewire-net lacked input validation when
      handling incoming fragmented datagrams.  A maliciously formed fragment
      with a respectively large datagram_offset would cause a memcpy past the
      datagram buffer.
      
      So, drop any packets carrying a fragment with offset + length larger
      than datagram_size.
      
      In addition, ensure that
        - GASP header, unfragmented encapsulation header, or fragment
          encapsulation header actually exists before we access it,
        - the encapsulated datagram or fragment is of nonzero size.
      Reported-by: NEyal Itkin <eyal.itkin@gmail.com>
      Reviewed-by: NEyal Itkin <eyal.itkin@gmail.com>
      Fixes: CVE 2016-8633
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      667121ac
  2. 05 5月, 2016 1 次提交
  3. 03 3月, 2015 1 次提交
  4. 16 7月, 2014 1 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen 提交于
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
  5. 12 5月, 2014 1 次提交
  6. 28 2月, 2014 1 次提交
  7. 10 6月, 2013 1 次提交
    • S
      firewire: introduce fw_driver.probe and .remove methods · 94a87157
      Stefan Richter 提交于
      FireWire upper layer drivers are converted from generic
          struct driver.probe() and .remove()
      to bus-specific
          struct fw_driver.probe() and .remove().
      
      The new .probe() adds a const struct ieee1394_device_id *id argument,
      indicating the entry in the driver's device identifiers table which
      matched the fw_unit to be probed.  This new argument is used by the
      snd-firewire-speakers driver to look up device-specific parameters and
      methods.  There is at least one other FireWire audio driver currently in
      development in which this will be useful too.
      
      The new .remove() drops the unused error return code.
      
      Although all in-tree drivers are being converted to the new methods,
      support for the old methods is left in place in this commit.  This
      allows public developer trees to merge this commit and then move to the
      new fw_driver methods.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Acked-by: Clemens Ladisch <clemens@ladisch.de> (for sound/firewire/)
      Cc: Peter Hurley <peter@hurleysoftware.com> (for drivers/staging/fwserial/)
      94a87157
  8. 29 4月, 2013 1 次提交
  9. 28 3月, 2013 1 次提交
    • S
      net: add ETH_P_802_3_MIN · e5c5d22e
      Simon Horman 提交于
      Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
      an 802.3 frame. Frames with a lower value in the ethernet type field
      are Ethernet II.
      
      Also update all the users of this value that David Miller and
      I could find to use the new constant.
      
      Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
      should be >= not >.
      
      As suggested by Jesse Gross.
      
      Compile tested only.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Bart De Schuymer <bart.de.schuymer@pandora.be>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netfilter-devel@vger.kernel.org
      Cc: bridge@lists.linux-foundation.org
      Cc: linux-wireless@vger.kernel.org
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: linux-media@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: dev@openvswitch.org
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5c5d22e
  10. 27 3月, 2013 6 次提交
    • Y
    • Y
      firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection. · 6752c8db
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Inspection of upper layer protocol is considered harmful, especially
      if it is about ARP or other stateful upper layer protocol; driver
      cannot (and should not) have full state of them.
      
      IPv4 over Firewire module used to inspect ARP (both in sending path
      and in receiving path), and record peer's GUID, max packet size, max
      speed and fifo address.  This patch removes such inspection by extending
      our "hardware address" definition to include other information as well:
      max packet size, max speed and fifo.  By doing this, The neighbour
      module in networking subsystem can cache them.
      
      Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
            information will not be used in the driver when sending.
      
      When a packet is being sent, the IP layer fills our pseudo header with
      the extended "hardware address", including GUID and fifo.  The driver
      can look-up node-id (the real but rather volatile low-level address)
      by GUID, and then the module can send the packet to the wire using
      parameters provided in the extendedn hardware address.
      
      This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
      over IEEE1394 (RFC3146) share same "hardware address" format
      in their address resolution protocols.
      
      Here, extended "hardware address" is defined as follows:
      
      union fwnet_hwaddr {
      	u8 u[16];
      	struct {
      		__be64 uniq_id;		/* EUI-64			*/
      		u8 max_rec;		/* max packet size		*/
      		u8 sspd;		/* max speed			*/
      		__be16 fifo_hi;		/* hi 16bits of FIFO addr	*/
      		__be32 fifo_lo;		/* lo 32bits of FIFO addr	*/
      	} __packed uc;
      };
      
      Note that Hardware address is declared as union, so that we can map full
      IP address into this, when implementing MCAP (Multicast Cannel Allocation
      Protocol) for IPv6, but IP and ARP subsystem do not need to know this
      format in detail.
      
      One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
      is that 1394 ARP Request/Reply do not contain the target hardware address
      field (aka ar$tha).  This difference is handled in the ARP subsystem.
      
      CC: Stephan Gatzka <stephan.gatzka@gmail.com>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6752c8db
    • Y
      firewire net: Ignore spd and max_payload advertised by ARP. · 61a7839a
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Stefan Richter <stefanr@s5r6.in-berlin.de> says:
      | As far as I can tell, it would be best to ignore max_rec and sspd from ARP
      | and NDP but keep using the respective information from firewire-core
      | instead (handed over by fwnet_probe()).
      |
      | Why?  As I noted earlier, RFC 2734:1999 and RFC 3146:2001 were apparently
      | written with a too simplistic notion of IEEE 1394 bus topology, resulting
      | in max_rec and sspd in ARP-1394 and NDP-1394 to be useless, IMO.
      |
      | Consider a bus like this:
      |
      |     A ---- B ==== C
      |
      | A, B, C are all IP-over-1394 capable nodes.  ---- is an S400 cable hop,
      | and ==== is an S800 cable hop.
      |
      | In case of unicasts or multicasts in which node A is involved as
      | transmitter or receiver, as well as in case of broadcasts, the speeds
      | S100, S200, S400 work and speed S400 is optimal.
      |
      | In case of anything else, IOW in case of unicasts or multicasts in which
      | only nodes B and C are involved, the speeds S100, S200, S400, S800 work
      | and speed S800 is optimal.
      |
      | Clearly, node A should indicate sspd = S400 in its ARP or NDP packets.
      | But which sspd should nodes B and C set there?  Maybe they set S400, which
      | would work but would waste half of the available bandwidth in the second
      | case.  Or maybe they set S800, which is OK in the second case but would
      | prohibit any communication with node A if blindly taken for correct.
      |
      | On the other hand, firewire-core *always* gives us the correct and optimum
      | peer-to-peer speed and asynchronous packet payload, no matter how simple
      | or complex the bus topology is and no matter in which temporal order nodes
      | join the bus and are discovered.
      
      CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61a7839a
    • Y
      firewire net: Allocate address handler before registering net_device. · 382c4b40
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Allocate FIFO address before registering net_device.
      This is preparation to change the pseudo hardware address format
      for firewire devices to include the offset of the FIFO for receipt
      of unicast datagrams, instead of mangling ARP/NDP messages in the
      driver layer.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      382c4b40
    • Y
      firewire net: Send L2 multicast via GASP. · 021b97e4
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Send L2 multicast packet via GASP (Global asynchronous stream packet) by
      seeing the multicast bit in the L2 hardware address, not by seeing upper-
      layer protocol address.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      021b97e4
    • Y
  11. 13 3月, 2013 11 次提交
  12. 21 1月, 2013 2 次提交
  13. 03 12月, 2012 2 次提交
  14. 23 2月, 2012 2 次提交
    • S
      firewire: net: use dev_printk API · 8408dc1c
      Stefan Richter 提交于
      Change the log line prefix from "firewire_net: " to "net firewire0: "
      etc. for the case that several RFC 2734 interfaces are being used in the
      same machine.
      
      Note, the netdev_printk API is not very useful to firewire-net.
      netdev_notice(net, "abc\n") would result in irritating messages like
      "firewire_ohci 0000:0a:00.0: firewire0: abc".  Nor would a dev_printk on
      the fw_unit.device to which firewire-net is being bound be useful,
      because there are generally multiple ones of those per interface (from
      all RFC 2734 peers on the bus, the local node being only one of them).
      
      In the initialization message of each interface, log the PCI device
      name of the card which is parent of the netdevice instead of the GUID
      of the peer which was semi-randomly used to establish the netdevice.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      8408dc1c
    • S
      firewire: net: identify to driver core as "firewire_net", not "net" · 59759ff6
      Stefan Richter 提交于
      On second thought, there is little reason to have driver name differ
      from module name.  Therefore, change
          /sys/bus/firewire/drivers/net
          /sys/bus/firewire/devices/fw0.0/driver -> [...]/net
          /sys/module/firewire_net/drivers/firewire:net
      to
          /sys/bus/firewire/drivers/firewire_net
          /sys/bus/firewire/devices/fw0.0/driver -> [...]/firewire_net
          /sys/module/firewire_net/drivers/firewire:firewire_net
      It is redundant but consistent with firewire-sbp2's recently changed
      driver name.
      
      I don't see this anywhere used, so it should not matter either way.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      59759ff6
  15. 09 10月, 2011 2 次提交
    • S
      firewire: net: Use posted writes · a74477db
      Stephan Gatzka 提交于
      Change memory region to ohci "middle address space". This effectively
      reduces the number of packets by 50%.
      
      [Stefan R.:]  This eliminates 1394 ack packets and improved throughput
      by a few percent in some tests with an S400a connection with and without
      gap count optimization.  Since firewire-net taxes the AR-req DMA unit of
      a FireWire controller much more than firewire-sbp2 (which uses the
      middle address space with PCI posted writes too), this commit also
      changes a related error printk into a ratelimited one as a precaution.
      
      Side note:  The IPv4-over-1394 drivers of Mac OS X 10.4, Windows XP SP3,
      and the Thesycon 1394 bus driver for Windows all use the middle address
      space too.
      Signed-off-by: NStephan Gatzka <stephan@gatzka.org>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      a74477db
    • S
      firewire: use clamp and min3 macros · 4ec4a67a
      Stefan Richter 提交于
      Use kernel.h's convenience macros.  Also omit a printk that should never
      happen and won't matter much if it ever happened.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      4ec4a67a
  16. 13 7月, 2011 1 次提交
  17. 02 6月, 2011 1 次提交
  18. 11 5月, 2011 1 次提交
    • C
      firewire: optimize iso queueing by setting wake only after the last packet · 13882a82
      Clemens Ladisch 提交于
      When queueing iso packets, the run time is dominated by the two
      MMIO accesses that set the DMA context's wake bit.  Because most
      drivers submit packets in batches, we can save much time by
      removing all but the last wakeup.
      
      The internal kernel API is changed to require a call to
      fw_iso_context_queue_flush() after a batch of queued packets.
      The user space API does not change, so one call to
      FW_CDEV_IOC_QUEUE_ISO must specify multiple packets to take
      advantage of this optimization.
      
      In my measurements, this patch reduces the time needed to queue
      fifty skip packets from userspace to one sixth on a 2.5 GHz CPU,
      or to one third at 800 MHz.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      13882a82
  19. 31 3月, 2011 1 次提交
  20. 21 1月, 2011 1 次提交