Using bridge utils to connect two computers via Linux












5















I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:



client - server - client
|
[Internet]


So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.



Internet is on eth0, and I have one bridge set up as



bridge name     interfaces
br0 eth1, eth2


ip addr br0 and ip route show shows respectively



inet 10.0.0.1/24 brd 10.0.0.255
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1


So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.



How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?










share|improve this question





























    5















    I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:



    client - server - client
    |
    [Internet]


    So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.



    Internet is on eth0, and I have one bridge set up as



    bridge name     interfaces
    br0 eth1, eth2


    ip addr br0 and ip route show shows respectively



    inet 10.0.0.1/24 brd 10.0.0.255
    10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1


    So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.



    How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?










    share|improve this question



























      5












      5








      5


      4






      I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:



      client - server - client
      |
      [Internet]


      So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.



      Internet is on eth0, and I have one bridge set up as



      bridge name     interfaces
      br0 eth1, eth2


      ip addr br0 and ip route show shows respectively



      inet 10.0.0.1/24 brd 10.0.0.255
      10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1


      So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.



      How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?










      share|improve this question
















      I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:



      client - server - client
      |
      [Internet]


      So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.



      Internet is on eth0, and I have one bridge set up as



      bridge name     interfaces
      br0 eth1, eth2


      ip addr br0 and ip route show shows respectively



      inet 10.0.0.1/24 brd 10.0.0.255
      10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1


      So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.



      How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?







      linux networking routing bridge






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 3 hours ago









      Rui F Ribeiro

      41.5k1483140




      41.5k1483140










      asked Oct 4 '10 at 10:27









      PatrickPatrick

      14827




      14827






















          3 Answers
          3






          active

          oldest

          votes


















          5














          Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.



          iptables -L


          and



          iptables -t nat -L





          share|improve this answer
























          • I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

            – Patrick
            Oct 4 '10 at 14:35






          • 1





            "man iptables" is your friend :-)

            – Richm
            Oct 4 '10 at 14:53






          • 1





            But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

            – Richm
            Oct 4 '10 at 14:56











          • @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

            – Patrick
            Oct 4 '10 at 15:47






          • 1





            The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

            – Richm
            Oct 4 '10 at 16:52



















          3














          If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like



          $ brctl show
          bridge name bridge id STP enabled interfaces
          br0 8000.003018a46079 no eth1
          eth2


          If both interfaces are not listed there then that needs correcting.



          You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding



          Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.



          ip link set br0 up
          ip link set eth0 up
          ip link set eth1 up
          ip link set eth2 up





          share|improve this answer
























          • brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

            – Patrick
            Oct 4 '10 at 12:46





















          2














          Check if ip fowarding is enabled on the server with the command



          sysctl net.ipv4.ip_forward


          if this gives 0, do



          sysctl -w net.ipv4.ip_forward=1


          as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf






          share|improve this answer
























          • it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

            – Patrick
            Oct 4 '10 at 10:58













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f2696%2fusing-bridge-utils-to-connect-two-computers-via-linux%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          5














          Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.



          iptables -L


          and



          iptables -t nat -L





          share|improve this answer
























          • I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

            – Patrick
            Oct 4 '10 at 14:35






          • 1





            "man iptables" is your friend :-)

            – Richm
            Oct 4 '10 at 14:53






          • 1





            But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

            – Richm
            Oct 4 '10 at 14:56











          • @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

            – Patrick
            Oct 4 '10 at 15:47






          • 1





            The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

            – Richm
            Oct 4 '10 at 16:52
















          5














          Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.



          iptables -L


          and



          iptables -t nat -L





          share|improve this answer
























          • I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

            – Patrick
            Oct 4 '10 at 14:35






          • 1





            "man iptables" is your friend :-)

            – Richm
            Oct 4 '10 at 14:53






          • 1





            But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

            – Richm
            Oct 4 '10 at 14:56











          • @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

            – Patrick
            Oct 4 '10 at 15:47






          • 1





            The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

            – Richm
            Oct 4 '10 at 16:52














          5












          5








          5







          Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.



          iptables -L


          and



          iptables -t nat -L





          share|improve this answer













          Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.



          iptables -L


          and



          iptables -t nat -L






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 4 '10 at 14:13









          RichmRichm

          3,1641612




          3,1641612













          • I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

            – Patrick
            Oct 4 '10 at 14:35






          • 1





            "man iptables" is your friend :-)

            – Richm
            Oct 4 '10 at 14:53






          • 1





            But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

            – Richm
            Oct 4 '10 at 14:56











          • @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

            – Patrick
            Oct 4 '10 at 15:47






          • 1





            The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

            – Richm
            Oct 4 '10 at 16:52



















          • I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

            – Patrick
            Oct 4 '10 at 14:35






          • 1





            "man iptables" is your friend :-)

            – Richm
            Oct 4 '10 at 14:53






          • 1





            But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

            – Richm
            Oct 4 '10 at 14:56











          • @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

            – Patrick
            Oct 4 '10 at 15:47






          • 1





            The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

            – Richm
            Oct 4 '10 at 16:52

















          I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

          – Patrick
          Oct 4 '10 at 14:35





          I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?

          – Patrick
          Oct 4 '10 at 14:35




          1




          1





          "man iptables" is your friend :-)

          – Richm
          Oct 4 '10 at 14:53





          "man iptables" is your friend :-)

          – Richm
          Oct 4 '10 at 14:53




          1




          1





          But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

          – Richm
          Oct 4 '10 at 14:56





          But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.

          – Richm
          Oct 4 '10 at 14:56













          @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

          – Patrick
          Oct 4 '10 at 15:47





          @Richm: Well whaddayaknow. iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..

          – Patrick
          Oct 4 '10 at 15:47




          1




          1





          The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

          – Richm
          Oct 4 '10 at 16:52





          The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.

          – Richm
          Oct 4 '10 at 16:52













          3














          If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like



          $ brctl show
          bridge name bridge id STP enabled interfaces
          br0 8000.003018a46079 no eth1
          eth2


          If both interfaces are not listed there then that needs correcting.



          You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding



          Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.



          ip link set br0 up
          ip link set eth0 up
          ip link set eth1 up
          ip link set eth2 up





          share|improve this answer
























          • brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

            – Patrick
            Oct 4 '10 at 12:46


















          3














          If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like



          $ brctl show
          bridge name bridge id STP enabled interfaces
          br0 8000.003018a46079 no eth1
          eth2


          If both interfaces are not listed there then that needs correcting.



          You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding



          Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.



          ip link set br0 up
          ip link set eth0 up
          ip link set eth1 up
          ip link set eth2 up





          share|improve this answer
























          • brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

            – Patrick
            Oct 4 '10 at 12:46
















          3












          3








          3







          If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like



          $ brctl show
          bridge name bridge id STP enabled interfaces
          br0 8000.003018a46079 no eth1
          eth2


          If both interfaces are not listed there then that needs correcting.



          You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding



          Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.



          ip link set br0 up
          ip link set eth0 up
          ip link set eth1 up
          ip link set eth2 up





          share|improve this answer













          If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like



          $ brctl show
          bridge name bridge id STP enabled interfaces
          br0 8000.003018a46079 no eth1
          eth2


          If both interfaces are not listed there then that needs correcting.



          You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding



          Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.



          ip link set br0 up
          ip link set eth0 up
          ip link set eth1 up
          ip link set eth2 up






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 4 '10 at 11:34









          RichmRichm

          3,1641612




          3,1641612













          • brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

            – Patrick
            Oct 4 '10 at 12:46





















          • brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

            – Patrick
            Oct 4 '10 at 12:46



















          brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

          – Patrick
          Oct 4 '10 at 12:46







          brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.

          – Patrick
          Oct 4 '10 at 12:46













          2














          Check if ip fowarding is enabled on the server with the command



          sysctl net.ipv4.ip_forward


          if this gives 0, do



          sysctl -w net.ipv4.ip_forward=1


          as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf






          share|improve this answer
























          • it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

            – Patrick
            Oct 4 '10 at 10:58


















          2














          Check if ip fowarding is enabled on the server with the command



          sysctl net.ipv4.ip_forward


          if this gives 0, do



          sysctl -w net.ipv4.ip_forward=1


          as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf






          share|improve this answer
























          • it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

            – Patrick
            Oct 4 '10 at 10:58
















          2












          2








          2







          Check if ip fowarding is enabled on the server with the command



          sysctl net.ipv4.ip_forward


          if this gives 0, do



          sysctl -w net.ipv4.ip_forward=1


          as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf






          share|improve this answer













          Check if ip fowarding is enabled on the server with the command



          sysctl net.ipv4.ip_forward


          if this gives 0, do



          sysctl -w net.ipv4.ip_forward=1


          as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 4 '10 at 10:52









          fschmittfschmitt

          7,6713043




          7,6713043













          • it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

            – Patrick
            Oct 4 '10 at 10:58





















          • it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

            – Patrick
            Oct 4 '10 at 10:58



















          it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

          – Patrick
          Oct 4 '10 at 10:58







          it prints net.ipv4.ip_forward = 1, so no dice unfortunately.

          – Patrick
          Oct 4 '10 at 10:58




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f2696%2fusing-bridge-utils-to-connect-two-computers-via-linux%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          CARDNET

          Boot-repair Failure: Unable to locate package grub-common:i386

          濃尾地震