1. 24 2月, 2006 5 次提交
    • H
      [IPSEC]: Use TOS when doing tunnel lookups · 4da3089f
      Herbert Xu 提交于
      We should use the TOS because it's one of the routing keys.  It also
      means that we update the correct routing cache entry when PMTU occurs.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4da3089f
    • J
      [NET] ethernet: Fix first packet goes out with MAC 00:00:00:00:00:00 · f8d0e3f1
      Jamal Hadi Salim 提交于
      When you turn off ARP on a netdevice then the first packet always goes
      out with a dstMAC of all zeroes. This is because the first packet is
      used to resolve ARP entries. Even though the ARP entry may be resolved
      (I tried by setting a static ARP entry for a host i was pinging from),
      it gets overwritten by virtue of having the netdevice disabling ARP.
      
      Subsequent packets go out fine with correct dstMAC address (which may
      be why people have ignored reporting this issue).
      
      To cut the story short: 
      
      the culprit code is in net/ethernet/eth.c::eth_header()
      
      ----
              /*
               *      Anyway, the loopback-device should never use this
      function...
               */
      
              if (dev->flags & (IFF_LOOPBACK|IFF_NOARP))
              {
                      memset(eth->h_dest, 0, dev->addr_len);
                      return ETH_HLEN;
              }
      
      	if(daddr)
              {
                      memcpy(eth->h_dest,daddr,dev->addr_len);
                      return ETH_HLEN;
              }
      
      ----
      
      Note how the h_dest is being reset when device has IFF_NOARP.
      
      As a note:
      All devices including loopback pass a daddr. loopback in fact passes
      a 0 all the time ;-> 
      This means i can delete the check totaly or i can remove the IFF_NOARP
      
      Alexey says:
      --------------------
      I think, it was me who did this crap. It was so long ago I do not remember
      why it was made.
      
      I remember some troubles with dummy device. It tried to resolve
      addresses, apparently, without success and generated errors instead of
      blackholing. I think the problem was eventually solved at neighbour
      level.
      
      After some thinking I suspect the deletion of this chunk could change
      behaviour of some parts which do not use neighbour cache f.e. packet
      socket.
      
      I think safer approach would be to move this chunk after if (daddr).
      And the possibility to remove this completely could be analyzed later.
      --------------------
      
      Patch updated with Alexey's safer suggestions.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Acked-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8d0e3f1
    • H
      [XFRM]: Eliminate refcounting confusion by creating __xfrm_state_put(). · 21380b81
      Herbert Xu 提交于
      We often just do an atomic_dec(&x->refcnt) on an xfrm_state object
      because we know there is more than 1 reference remaining and thus
      we can elide the heavier xfrm_state_put() call.
      
      Do this behind an inline function called __xfrm_state_put() so that is
      more obvious and also to allow us to more cleanly add refcount
      debugging later.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21380b81
    • S
      [IPV4]: Fix garbage collection of multipath route entries · 85259878
      Suresh Bhogavilli 提交于
      When garbage collecting route cache entries of multipath routes
      in rt_garbage_collect(), entries were deleted from the hash bucket
      'i' while holding a spin lock on bucket 'k' resulting in a system
      hang.  Delete entries, if any, from bucket 'k' instead.
      Signed-off-by: NSuresh Bhogavilli <sbhogavilli@verisign.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85259878
    • P
      [NETFILTER]: Fix bridge netfilter related in xfrm_lookup · 42cf93cd
      Patrick McHardy 提交于
      The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL
      to purely bridged packets. When these packets are SNATed and a policy
      lookup is done, xfrm_lookup crashes because it tries to dereference
      dst->ops.
      
      Change xfrm_lookup not to dereference dst->ops before checking for the
      DST_NOXFRM flag and set this flag in the fake dst_entry.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42cf93cd
  2. 23 2月, 2006 18 次提交
  3. 22 2月, 2006 17 次提交