746719ab   
   From: lacos@caesar.elte.hu   
      
   On Tue, 29 Nov 2011, adirtymindisajoyforever wrote:   
      
   > I have a solaris box with two nic cards: iprb0 and e1000g0.   
   >   
   > In the routing table the first entry is the e1000g0.   
   >   
   > On this machine I have a udp socket listening process that echoes all   
   > incoming messsages.   
   >   
   > I have another machine from which i send upd messages and receive   
   > answers on the same socket.   
   >   
   > I use as destination ip address the one associated with iprb0.   
   >   
   > Snoop tells me the incoming messages are on iprb0 and outgoing on   
   > e1000g0, i.e. the reply don not have the ip address configured for iprb0   
   > (as the messages sent), but the address configures on e1000g0.   
   >   
   > When the sending machine is a linux the messages echoed are NOT   
   > received.   
   > When the sending machine is a solaris, messages are received.   
   >   
   > Which behaviour is correct? According to me it is the linux one.   
      
   I suspect the reverse path filter. (I assume you don't call connect() in   
   the client.)   
      
   See the documentation of the 'rp_filter' sysctl:   
      
   http://lxr.linux.no/#linux+v3.1.4/Documentation/networking/ip-sysctl.txt#L845   
      
   It mentions RFC3704:   
      
   http://www.rfc-editor.org/rfc/rfc3704.txt   
      
   What would happen in your current setup, if you addressed, from the   
   client, the server's e1000g0 interface?   
      
   - If the packet could not be routed at all, then:   
      - Linux runs with rp_filter=1 or rp_filter=2, and   
      - Solaris does not validate the source   
   - If the packet could be routed, but through a different client interface   
      than it currently happens, then   
      - Linux runs with rp_filter=1, and   
      - Solaris does not validate the source, or is in loose mode.   
      
   Laszlo   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)