* bridge not getting ip since 3.11.5 and 3.4.66 @ 2013-11-11 10:29 Mark Trompell 2013-11-11 11:07 ` Veaceslav Falico 0 siblings, 1 reply; 9+ messages in thread From: Mark Trompell @ 2013-11-11 10:29 UTC (permalink / raw) To: linux-kernel my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, What information would be helpful and required to find out what's going wrong. Greetings Mark ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-11 10:29 bridge not getting ip since 3.11.5 and 3.4.66 Mark Trompell @ 2013-11-11 11:07 ` Veaceslav Falico 2013-11-11 12:52 ` Mark Trompell 0 siblings, 1 reply; 9+ messages in thread From: Veaceslav Falico @ 2013-11-11 11:07 UTC (permalink / raw) To: Mark Trompell; +Cc: Linux-Kernel, netdev On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: > my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, > What information would be helpful and required to find out what's going wrong. CC netdev First thing would be to provide the network scheme. Do you use vlans? Which network cards/drivers are you using? Do you use some kind of virtualization? Is bonding involved? > > Greetings > Mark > -- > 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/ -- Best regards, Veaceslav Falico ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-11 11:07 ` Veaceslav Falico @ 2013-11-11 12:52 ` Mark Trompell 2013-11-12 10:57 ` Mark Trompell 0 siblings, 1 reply; 9+ messages in thread From: Mark Trompell @ 2013-11-11 12:52 UTC (permalink / raw) To: Veaceslav Falico; +Cc: Linux-Kernel, netdev On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: > On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >> What information would be helpful and required to find out what's going wrong. > > CC netdev > > First thing would be to provide the network scheme. Do you use vlans? > Which network > cards/drivers are you using? Do you use some kind of virtualization? > Is bonding involved? > Actually this is my desktop machine using kvm for a virtual machine that uses eth0 which is connected to the bridge which is used as interface for the host. $ ip addr 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast master br0 qlen 1000 ... 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue ... Anything else? Greetings Mark ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-11 12:52 ` Mark Trompell @ 2013-11-12 10:57 ` Mark Trompell 2013-11-26 13:27 ` Mark Trompell 0 siblings, 1 reply; 9+ messages in thread From: Mark Trompell @ 2013-11-12 10:57 UTC (permalink / raw) To: Veaceslav Falico; +Cc: Linux-Kernel, netdev On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: > On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>> What information would be helpful and required to find out what's going wrong. >> >> CC netdev >> >> First thing would be to provide the network scheme. Do you use vlans? >> Which network >> cards/drivers are you using? Do you use some kind of virtualization? >> Is bonding involved? >> > Actually this is my desktop machine using kvm for a virtual machine > that uses eth0 which is connected to the bridge > which is used as interface for the host. > > $ ip addr > 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast > master br0 qlen 1000 > ... > 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > ... > > Anything else? Okay more about my hardware and configuration: from lspci: 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04) /etc/sysconfig/network-scripts/ifcfg-br0 DEVICE=br0 ONBOOT=yes MACADDR=00:19:99:ac:b3:24 TYPE=Bridge BOOTPROTO=dhcp STP=on NM_CONTROLLED=no DELAY=0 /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:19:99:cd:a5:e6 #BOOTPROTO=dhcp ONBOOT=yes BRIDGE=br0 TYPE=Ethernet NM_CONTROLLED=no > Greetings > Mark ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-12 10:57 ` Mark Trompell @ 2013-11-26 13:27 ` Mark Trompell 0 siblings, 0 replies; 9+ messages in thread From: Mark Trompell @ 2013-11-26 13:27 UTC (permalink / raw) To: Veaceslav Falico; +Cc: Linux-Kernel, netdev, herbert Answering my own mail again and even top posting, sorry, but makes more sense to me in that case). I reverted bridge related patches from 3.11.5 and it boils down to commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Thu Sep 12 17:12:05 2013 +1000 bridge: Clamp forward_delay when enabling STP [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] At some point limits were added to forward_delay. However, the limits are only enforced when STP is enabled. This created a scenario where you could have a value outside the allowed range while STP is disabled, which then stuck around even after STP is enabled. This patch fixes this by clamping the value when we enable STP. I had to move the locking around a bit to ensure that there is no window where someone could insert a value outside the range while we're in the middle of enabling STP. Causing the issue for me. Reverting that patch and br0 comes up again and gets an ip. On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote: > On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: >> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>>> What information would be helpful and required to find out what's going wrong. >>> >>> CC netdev >>> >>> First thing would be to provide the network scheme. Do you use vlans? >>> Which network >>> cards/drivers are you using? Do you use some kind of virtualization? >>> Is bonding involved? >>> >> Actually this is my desktop machine using kvm for a virtual machine >> that uses eth0 which is connected to the bridge >> which is used as interface for the host. >> >> $ ip addr >> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast >> master br0 qlen 1000 >> ... >> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >> ... >> >> Anything else? > > Okay more about my hardware and configuration: > from lspci: > 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network > Connection (rev 04) > > /etc/sysconfig/network-scripts/ifcfg-br0 > DEVICE=br0 > ONBOOT=yes > MACADDR=00:19:99:ac:b3:24 > TYPE=Bridge > BOOTPROTO=dhcp > STP=on > NM_CONTROLLED=no > DELAY=0 > > /etc/sysconfig/network-scripts/ifcfg-eth0 > DEVICE=eth0 > HWADDR=00:19:99:cd:a5:e6 > #BOOTPROTO=dhcp > ONBOOT=yes > BRIDGE=br0 > TYPE=Ethernet > NM_CONTROLLED=no > > >> Greetings >> Mark -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 @ 2013-11-26 13:27 ` Mark Trompell 0 siblings, 0 replies; 9+ messages in thread From: Mark Trompell @ 2013-11-26 13:27 UTC (permalink / raw) To: Veaceslav Falico; +Cc: Linux-Kernel, netdev, herbert Answering my own mail again and even top posting, sorry, but makes more sense to me in that case). I reverted bridge related patches from 3.11.5 and it boils down to commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Thu Sep 12 17:12:05 2013 +1000 bridge: Clamp forward_delay when enabling STP [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] At some point limits were added to forward_delay. However, the limits are only enforced when STP is enabled. This created a scenario where you could have a value outside the allowed range while STP is disabled, which then stuck around even after STP is enabled. This patch fixes this by clamping the value when we enable STP. I had to move the locking around a bit to ensure that there is no window where someone could insert a value outside the range while we're in the middle of enabling STP. Causing the issue for me. Reverting that patch and br0 comes up again and gets an ip. On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote: > On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: >> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>>> What information would be helpful and required to find out what's going wrong. >>> >>> CC netdev >>> >>> First thing would be to provide the network scheme. Do you use vlans? >>> Which network >>> cards/drivers are you using? Do you use some kind of virtualization? >>> Is bonding involved? >>> >> Actually this is my desktop machine using kvm for a virtual machine >> that uses eth0 which is connected to the bridge >> which is used as interface for the host. >> >> $ ip addr >> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast >> master br0 qlen 1000 >> ... >> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >> ... >> >> Anything else? > > Okay more about my hardware and configuration: > from lspci: > 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network > Connection (rev 04) > > /etc/sysconfig/network-scripts/ifcfg-br0 > DEVICE=br0 > ONBOOT=yes > MACADDR=00:19:99:ac:b3:24 > TYPE=Bridge > BOOTPROTO=dhcp > STP=on > NM_CONTROLLED=no > DELAY=0 > > /etc/sysconfig/network-scripts/ifcfg-eth0 > DEVICE=eth0 > HWADDR=00:19:99:cd:a5:e6 > #BOOTPROTO=dhcp > ONBOOT=yes > BRIDGE=br0 > TYPE=Ethernet > NM_CONTROLLED=no > > >> Greetings >> Mark -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-26 13:27 ` Mark Trompell @ 2013-11-26 15:25 ` Vlad Yasevich -1 siblings, 0 replies; 9+ messages in thread From: Vlad Yasevich @ 2013-11-26 15:25 UTC (permalink / raw) To: Mark Trompell, Veaceslav Falico; +Cc: Linux-Kernel, netdev, herbert On 11/26/2013 08:27 AM, Mark Trompell wrote: > Answering my own mail again and even top posting, sorry, but makes > more sense to me in that case). > I reverted bridge related patches from 3.11.5 and it boils down to > commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32 > Author: Herbert Xu <herbert@gondor.apana.org.au> > Date: Thu Sep 12 17:12:05 2013 +1000 > > bridge: Clamp forward_delay when enabling STP > > [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] > > At some point limits were added to forward_delay. However, the > limits are only enforced when STP is enabled. This created a > scenario where you could have a value outside the allowed range > while STP is disabled, which then stuck around even after STP > is enabled. > > This patch fixes this by clamping the value when we enable STP. > > I had to move the locking around a bit to ensure that there is > no window where someone could insert a value outside the range > while we're in the middle of enabling STP. > > Causing the issue for me. Reverting that patch and br0 comes up again > and gets an ip. yes, that patch introduced a bug where we always used the max_forward delay value. you have 2 options: 1) disable STP. Since you are just running VMs and you have a single physical connection on the bridge, you can safely disable STP since your system is a leaf node. 2) Get the latest stable kernel. The bug has been fixed there. -vlad > > On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote: >> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: >>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>>>> What information would be helpful and required to find out what's going wrong. >>>> >>>> CC netdev >>>> >>>> First thing would be to provide the network scheme. Do you use vlans? >>>> Which network >>>> cards/drivers are you using? Do you use some kind of virtualization? >>>> Is bonding involved? >>>> >>> Actually this is my desktop machine using kvm for a virtual machine >>> that uses eth0 which is connected to the bridge >>> which is used as interface for the host. >>> >>> $ ip addr >>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast >>> master br0 qlen 1000 >>> ... >>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >>> ... >>> >>> Anything else? >> >> Okay more about my hardware and configuration: >> from lspci: >> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network >> Connection (rev 04) >> >> /etc/sysconfig/network-scripts/ifcfg-br0 >> DEVICE=br0 >> ONBOOT=yes >> MACADDR=00:19:99:ac:b3:24 >> TYPE=Bridge >> BOOTPROTO=dhcp >> STP=on >> NM_CONTROLLED=no >> DELAY=0 >> >> /etc/sysconfig/network-scripts/ifcfg-eth0 >> DEVICE=eth0 >> HWADDR=00:19:99:cd:a5:e6 >> #BOOTPROTO=dhcp >> ONBOOT=yes >> BRIDGE=br0 >> TYPE=Ethernet >> NM_CONTROLLED=no >> >> >>> Greetings >>> Mark > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 @ 2013-11-26 15:25 ` Vlad Yasevich 0 siblings, 0 replies; 9+ messages in thread From: Vlad Yasevich @ 2013-11-26 15:25 UTC (permalink / raw) To: Mark Trompell, Veaceslav Falico; +Cc: Linux-Kernel, netdev, herbert On 11/26/2013 08:27 AM, Mark Trompell wrote: > Answering my own mail again and even top posting, sorry, but makes > more sense to me in that case). > I reverted bridge related patches from 3.11.5 and it boils down to > commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32 > Author: Herbert Xu <herbert@gondor.apana.org.au> > Date: Thu Sep 12 17:12:05 2013 +1000 > > bridge: Clamp forward_delay when enabling STP > > [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] > > At some point limits were added to forward_delay. However, the > limits are only enforced when STP is enabled. This created a > scenario where you could have a value outside the allowed range > while STP is disabled, which then stuck around even after STP > is enabled. > > This patch fixes this by clamping the value when we enable STP. > > I had to move the locking around a bit to ensure that there is > no window where someone could insert a value outside the range > while we're in the middle of enabling STP. > > Causing the issue for me. Reverting that patch and br0 comes up again > and gets an ip. yes, that patch introduced a bug where we always used the max_forward delay value. you have 2 options: 1) disable STP. Since you are just running VMs and you have a single physical connection on the bridge, you can safely disable STP since your system is a leaf node. 2) Get the latest stable kernel. The bug has been fixed there. -vlad > > On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote: >> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: >>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>>>> What information would be helpful and required to find out what's going wrong. >>>> >>>> CC netdev >>>> >>>> First thing would be to provide the network scheme. Do you use vlans? >>>> Which network >>>> cards/drivers are you using? Do you use some kind of virtualization? >>>> Is bonding involved? >>>> >>> Actually this is my desktop machine using kvm for a virtual machine >>> that uses eth0 which is connected to the bridge >>> which is used as interface for the host. >>> >>> $ ip addr >>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast >>> master br0 qlen 1000 >>> ... >>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >>> ... >>> >>> Anything else? >> >> Okay more about my hardware and configuration: >> from lspci: >> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network >> Connection (rev 04) >> >> /etc/sysconfig/network-scripts/ifcfg-br0 >> DEVICE=br0 >> ONBOOT=yes >> MACADDR=00:19:99:ac:b3:24 >> TYPE=Bridge >> BOOTPROTO=dhcp >> STP=on >> NM_CONTROLLED=no >> DELAY=0 >> >> /etc/sysconfig/network-scripts/ifcfg-eth0 >> DEVICE=eth0 >> HWADDR=00:19:99:cd:a5:e6 >> #BOOTPROTO=dhcp >> ONBOOT=yes >> BRIDGE=br0 >> TYPE=Ethernet >> NM_CONTROLLED=no >> >> >>> Greetings >>> Mark > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bridge not getting ip since 3.11.5 and 3.4.66 2013-11-26 15:25 ` Vlad Yasevich (?) @ 2013-11-27 6:46 ` Mark Trompell -1 siblings, 0 replies; 9+ messages in thread From: Mark Trompell @ 2013-11-27 6:46 UTC (permalink / raw) To: Vlad Yasevich; +Cc: Veaceslav Falico, Linux-Kernel, netdev, herbert On Tue, Nov 26, 2013 at 4:25 PM, Vlad Yasevich <vyasevich@gmail.com> wrote: > On 11/26/2013 08:27 AM, Mark Trompell wrote: >> Answering my own mail again and even top posting, sorry, but makes >> more sense to me in that case). >> I reverted bridge related patches from 3.11.5 and it boils down to >> commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32 >> Author: Herbert Xu <herbert@gondor.apana.org.au> >> Date: Thu Sep 12 17:12:05 2013 +1000 >> >> bridge: Clamp forward_delay when enabling STP >> >> [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ] >> >> At some point limits were added to forward_delay. However, the >> limits are only enforced when STP is enabled. This created a >> scenario where you could have a value outside the allowed range >> while STP is disabled, which then stuck around even after STP >> is enabled. >> >> This patch fixes this by clamping the value when we enable STP. >> >> I had to move the locking around a bit to ensure that there is >> no window where someone could insert a value outside the range >> while we're in the middle of enabling STP. >> >> Causing the issue for me. Reverting that patch and br0 comes up again >> and gets an ip. > > yes, that patch introduced a bug where we always used the > max_forward delay value. > > you have 2 options: > 1) disable STP. Since you are just running VMs and you have a single > physical connection on the bridge, you can safely disable STP since > your system is a leaf node. disabling stp indeed helps here, but ... > 2) Get the latest stable kernel. The bug has been fixed there. 3.12.1 still doesn't work with stp enabled. I guess you're talking about 4b6c7879d84ad06a2ac5b964808ed599187a188d bridge: Correctly clamp MAX forward_delay when enabling STP which should fix that? > -vlad Mark >> >> On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote: >>>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote: >>>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote: >>>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66, >>>>>> What information would be helpful and required to find out what's going wrong. >>>>> >>>>> CC netdev >>>>> >>>>> First thing would be to provide the network scheme. Do you use vlans? >>>>> Which network >>>>> cards/drivers are you using? Do you use some kind of virtualization? >>>>> Is bonding involved? >>>>> >>>> Actually this is my desktop machine using kvm for a virtual machine >>>> that uses eth0 which is connected to the bridge >>>> which is used as interface for the host. >>>> >>>> $ ip addr >>>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast >>>> master br0 qlen 1000 >>>> ... >>>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >>>> ... >>>> >>>> Anything else? >>> >>> Okay more about my hardware and configuration: >>> from lspci: >>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network >>> Connection (rev 04) >>> >>> /etc/sysconfig/network-scripts/ifcfg-br0 >>> DEVICE=br0 >>> ONBOOT=yes >>> MACADDR=00:19:99:ac:b3:24 >>> TYPE=Bridge >>> BOOTPROTO=dhcp >>> STP=on >>> NM_CONTROLLED=no >>> DELAY=0 >>> >>> /etc/sysconfig/network-scripts/ifcfg-eth0 >>> DEVICE=eth0 >>> HWADDR=00:19:99:cd:a5:e6 >>> #BOOTPROTO=dhcp >>> ONBOOT=yes >>> BRIDGE=br0 >>> TYPE=Ethernet >>> NM_CONTROLLED=no >>> >>> >>>> Greetings >>>> Mark >> >> >> > -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-11-27 6:47 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-11 10:29 bridge not getting ip since 3.11.5 and 3.4.66 Mark Trompell 2013-11-11 11:07 ` Veaceslav Falico 2013-11-11 12:52 ` Mark Trompell 2013-11-12 10:57 ` Mark Trompell 2013-11-26 13:27 ` Mark Trompell 2013-11-26 13:27 ` Mark Trompell 2013-11-26 15:25 ` Vlad Yasevich 2013-11-26 15:25 ` Vlad Yasevich 2013-11-27 6:46 ` Mark Trompell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.