search for: add_to_bridg

Hi, The attached patch fixes the setup of the bridge ports and the bridge itself. Changes: * move some functions to xen-network-common.sh, so both vif-bridge and network-bridge can use them. * add a new function to configure bridge ports and use it. * make sure arp requests, ipv6 autoconfiguration and ipv6 router solicitations are disabled for the bridge ports and also for the

...ate the bridge if it already exists. if ! brctl show | grep -q ${bridge} ; then brctl addbr ${bridge} brctl stp ${bridge} off brctl setfd ${bridge} 0 fi ip link set ${bridge} arp off ip link set ${bridge} multicast off ip link set ${bridge} up } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # Don't add $dev to $bridge if it's already on a bridge. if ! brctl show | grep -q ${dev} ; then brctl addif ${bridge} ${dev} fi } # adds $dev to $bridge but waits for $dev to be in running state first...

...ge bridge create_bridge () { local bridge=$1 # Don''t create the bridge if it already exists. if ! brctl show | grep -q ${bridge} ; then brctl addbr ${bridge} brctl stp ${bridge} off brctl setfd ${bridge} 0 fi ip link set ${bridge} up } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # Don''t add $dev to $bridge if it''s already on a bridge. if ! brctl show | grep -q ${dev} ; then brctl addif ${bridge} ${dev} fi } # Usage: show_status dev bridge # Print ifconfig and routes....

...d, 0% packet loss, time 1998ms # more /var/tmp/network-bridge.log ... + for i in ''`seq ${maxtries}`'' + ifconfig peth1 + grep -q RUNNING + echo -n . + sleep 1 + ''['' 10 -eq 10 '']'' + echo -n ''(link isnt in running state)'' + echo + add_to_bridge eth1 peth1 + local bridge=eth1 + local dev=peth1 + ''['' -e /sys/class/net/eth1/brif/peth1 '']'' + brctl addif eth1 peth1 + ip link set peth1 up + do_ifup eth1 + ''['' eth1 ''!='' eth1 '']'' + ifup eth1 RTNETLINK answe...

Hi, I have two systems(a laptop and a desktop) connected with an Ethernet cable. Desktop is using the Internet through the laptop wireless LAN. Both systems have Ubuntu 11.10 with XEN 4.1.2 Hypervisor. I have compiled OpenvSwitch-1.5 on both the systems as well. In Linux Bridge mode both can ping each other. Problem: LINUX bridge is used in both systems and both can access the internet but as

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is there a way to prevent hwaddr/mac address spoofing between DomU''s? So in a way ''binding'' a mac-address on boot time with a virtual interface? (with something like ebtables/arptables/etc?) Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla -

...bridge="eth${bridge#xenbr}" fi fi fi RET=0 ip link show $bridge 1>/dev/null 2>&1 || RET=1 if [ "$RET" -eq 1 ] then fatal "Could not find bridge device $bridge" fi case "$command" in online) setup_bridge_port "$vif" add_to_bridge "$bridge" "$vif" if [ ${bridge} = "eth1" ]; then do_without_error ifconfig "$vif" mtu 9000 (sleep 10; ifconfig "$vif" mtu 9000) & (sleep 30; ifconfig "$vif" mtu 9000) & (sleep 300; ifconfig "$vif" mtu 900...

...tic u32 str2ip(const char *ipaddr) +{ + unsigned int byte[4]; + + sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); + return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; +} + +/* adapted from libbridge */ +static void add_to_bridge(int fd, const char *if_name, const char *br_name) +{ + int ifidx; + struct ifreq ifr; + + if (!*br_name) + errx(1, "must specify bridge name"); + + ifidx = if_nametoindex(if_name); + if (!ifidx) + errx(1, "interface %s does not exist!", if_name); + + strncpy(ifr.ifr_name, br_...

...tic u32 str2ip(const char *ipaddr) +{ + unsigned int byte[4]; + + sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); + return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; +} + +/* adapted from libbridge */ +static void add_to_bridge(int fd, const char *if_name, const char *br_name) +{ + int ifidx; + struct ifreq ifr; + + if (!*br_name) + errx(1, "must specify bridge name"); + + ifidx = if_nametoindex(if_name); + if (!ifidx) + errx(1, "interface %s does not exist!", if_name); + + strncpy(ifr.ifr_name, br_...

...tic u32 str2ip(const char *ipaddr) +{ + unsigned int byte[4]; + + sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); + return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; +} + +/* adapted from libbridge */ +static void add_to_bridge(int fd, const char *if_name, const char *br_name) +{ + int r, ifidx; + struct ifreq ifr; + + if (!*br_name) + errx(1, "must specify bridge name"); + + ifidx = if_nametoindex(if_name); + if (!ifidx) + errx(1, "interface %s does not exist!\n", if_name); + + strncpy(ifr.ifr_name...

...tic u32 str2ip(const char *ipaddr) +{ + unsigned int byte[4]; + + sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); + return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; +} + +/* adapted from libbridge */ +static void add_to_bridge(int fd, const char *if_name, const char *br_name) +{ + int r, ifidx; + struct ifreq ifr; + + if (!*br_name) + errx(1, "must specify bridge name"); + + ifidx = if_nametoindex(if_name); + if (!ifidx) + errx(1, "interface %s does not exist!\n", if_name); + + strncpy(ifr.ifr_name...

xenconsole fix. reference of tty->count in xencons_close() is racy. It must be protected by tty_sem semaphore like con_close() in drivers/char/vt.c -- yamahata _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Pardon me for a long detailed post but this looks pretty serious. The bottom line is that, when I attempt to shut down or reboot my simple xen-2.0.7 server running FC3 with two domUs, shutting down xendomains appears to send python into an infinite loop. This may be due to a serious misconfiguration on my part but it is certainly a big problem. If we shutdown the domUs manually first, the

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c