ip routing

From: Rainer Hochreiter (rainer_at_hochreiter.at)
Date: 11/30/03

  • Next message: Mr. Mailing List: "usb keyboard bug remains in test 11"
    To: linux-kernel@vger.kernel.org
    Date:	30 Nov 2003 09:24:01 +0100
    
    

    hi list!

    i have a problem with ip routing!

    first of all my configuration:

    Tux1 .... embedded linux (kernel-2.4.10) running busybox-0.60.3
              and 2 lan interfaces in different networks
              default gateway 10.1.0.254 via eth0
    R1, R2 .. router (linux for testing)
    Tux2 .... linux with network different to Tux1/eth0/eth1

         eth0=10.1.0.1/16 +-----+ eth1=10.2.0.1/16
                       .--|Tux1 |--.
                       | +-----+ |
    eth1=10.1.0.254/16 | | eth1=10.2.0.254/16
                    +-----+ +-----+
       ip_forward=1 | R1 | | R2 | ip_forward=1
                    +-----+ +-----+
    eth0=10.3.1.254/16 | | eth0=10.3.2.254/16
                       | |
                       '-----+-----'
                             | eth0=10.3.0.1/16
                          +-----+
                          |Tux2 |
                          +-----+

    i want to achieve, that each packet received on Tux1/eth1 will also be
    replied via this interface. this isn't the case now, because the
    received packets came from a different network and therefore the replies
    are sent back via Tux1/eth0 using the default route.

    but the replies have to be sent even when the connection between
    Tux1/et0 and R1 is not available. a possible solution is, setting a
    network route for network Tux2/eth0 via Tux1/eth1, but in my special
    case, i do not know from which network i'll receive the packets!

    and here i reached the point where my knowledge ends;-(

    i tried to solve this problem in my application running on Tux1, using
    the following code:

    s = socket();
    bind(s, "10.2.0.1"); // bind to Tux1/eth1
    listen(s);
    s2 = accept(s);
    int yes=1;
    setsockopt(s2, SOL_SOCKET, SO_DONTROUTE, &yes, sizeof(yes));

    ...but setting SO_DONTROUTE on socket s2 doesn't have the effect, that
    the reply packets are always sent back via Tux1/eth1!
    is it possible at all to guarantee this in any case? because this means
    bypassing the routing stuff!

    any hints welcome!

    greetings,
    rainer

    PLEASE personally CC any answers and comment to my question - thnx!

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Mr. Mailing List: "usb keyboard bug remains in test 11"

    Relevant Pages

    • Re: Ethernet issue: works one way but not another
      ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
      (freebsd-questions)
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
      (Incidents)
    • Re: IDSIPS that can handle one Gig
      ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
      (Focus-IDS)
    • Re: iptables and dhcp
      ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
      (comp.os.linux.networking)
    • Re: Update: UDP 770 Potential Worm
      ... > were no packets indicating some form of replication. ... > my capture was limited due to the switched ... to see if the problem occurs on the test network, ... The proxy had already been isolated from the ...
      (Incidents)