Regarding TUN and TAP devices: it is not enough to make the check above.
The reason is that there may be cases when we create a TUN device and (by error)
call it tap10; or create a TAP device and name it tun10. So, how can I know if it is a tun device or a tap device, since both of course will have "tun_flags" entries?
The answer is to run ethtool -i ...
I don't think there's an easy way to distinguish them. Poking around in /sys/class/net I found the following distinctions:
Physical devices have a /sys/class/net/eth0/device symlink
Bridges have a /sys/class/net/br0/bridge directory
TUN and TAP devices have a /sys/class/net/tap0/tun_flags file
Bridges and loopback interfaces have 00:00:00:00:00:00 in /sys/...
A bridge does not need an IP address to function. Without one it will just perform layer 2 switching, spanning tree protocol and filtering (if configured).
An IP address is required if you want your bridge to take part in layer 3 routing of IP packets.
As an example you can setup a bridge without an IP address in Debian/Ubuntu using the following in /etc/...
Because a bridge is an ethernet device it needs a MAC address. A linux bridge can originate things like spanning-tree protocol frames, and traffic like that needs an origin MAC address.
A bridge does not require an ip address. There are many situations in which you won't have one. However, in many cases you may have one, such as:
When the bridge is ...
To clarify this for future.
ifup and ifdown are commands from some flavours of linux. And are used to control network settings set in /etc/network/interfaces for debian based systems and /etc/sysconfig/network-scripts/ifcg* on Redhat based systems (I cannot comment on others).
Creating and removing interfaces manually is done by using ifconfig (or ip ...
It's not just you.
See here: http://www.dd-wrt.com/wiki/index.php/Wireless_Bridge#Limitations
Basically, the spec for WiFi says that any wireless adapter can only have one MAC address, which makes bridging WiFi an impracticality.
There are several bugs in several forms describing slightly different symptoms filed against VirtualBox (735, 2975, 5503, etc.) ...
The NIC represents the uplink cable. A cable is layer 1, not layer 3.
Now the Bridge works as the device that is being addressed for network traffic (incoming) on the server - either on layer 2 (Ethernet/MAC) and/or layer 3 (IP).
So the device that responds to ARP-requests is the bridge - which is good, since it needs to distribute the traffic to the other ...
You can use the more-or-less undocumented -d option to ip(8), which tells you the type of certain devices including tun, tap & veth:
$ ip -d a
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 52:54:00:c8:12:ec brd ff:ff:ff:ff:ff:ff promiscuity 0
...note tun ...
The comment from Stéphane Chazelas provides the hint to the answer.
According to Bridge-nf Frequently Asked Questions bridge-nf enables iptables, ip6tables or arptables to see bridged traffic.
As of kernel version 2.6.1, there are five sysctl entries for bridge-nf behavioral control:
bridge-nf-call-arptables - pass bridged ARP traffic to arptables' ...
Yes, you can do this, and it's not even that hard. I have a laptop with a wireless card, and an ethernet port. I plugged a RapberryPi running Arch Linux into it, via a "crossover" ethernet cable. That's one special thing you might need - not all ethernet cards can do a machine-to-machine direct connection.
The other tricky part is IP addressing. It's best ...
For future readers, I wrote this email to some colleagues of mine who are working with me on configuring LXC and figuring out the bridging.
Well, I spent most of the day today fussing with networking in LXC, and now things are a lot clearer, so I thought I’d pass on what I learned.
First is a couple of definitions so we know what we’re looking at (I didn’...
I suspect your problem is more because whatever sends the UDP packets is not adding a newline character the commands (as in they should send "play\n" and not just "play").
In any case, if you want a new TCP connection to be created for each of the UDP packets, you should use udp-recvfrom instead of udp-listen in socat:
socat -u udp-recvfrom:3333,fork tcp:...
Here's the output from one of my bridging Linux machines:
With brctl showstp, you can print the list of interfaces and their spanning-tree parameters involved with the bridging. There, in parenthesis, you'll find the interface index of the constituent interfaces - that's what is referenced in brctl showmacs.
# brctl show
bridge name bridge id ...
For configuring a bridge from ethernet to wifi, it is as simple as doing in your /etc/network/interfaces:
iface eth0 inet manual
iface wlan0 inet manual
iface br0 inet static
bridge_ports eth0 wlan0
Replace the IP address with ...
A bridge is a network aggregation device, similar in practice to a switch. The bridges implemented in the Linux kernel follow this model. Like any bridge, they forward traffic based on destination MAC addresses, once the MAC address mapping is known. They are actually more featureful than most switches, since they also support firewalling, traffic shaping ...
You shouldn't need to set the ip_forward = 1 unless the interface is acting as a NAT for the other devices, which shouldn't be the case if you've set them up as a bridge.
Here's my KVM server setup which has a bridge device, br0, with the physical ethernet device, eth0 + all the interfaces for the KVM guests.
$ brctl show
bridge name bridge id ...
When using br0 for multicasting, it needs to have IGMP Querier enabled. When it is enabled IGMP protocol version will change from v3 into v2 and it will start issuing Membership queries and no longer drop.
From what I've googled, there seems to be no utility for enabling querier on a bridge, it must be done via /sys like this:
$ echo -n 1 > /sys/devices/...
Not a problem, it's the way most openWRT systems connect the wlan and switch ports into the same LAN. Here's an example of the config on my openWRT system which has two wifi networks, one for private use and one for guests:
# brctl show
bridge name bridge id STP enabled interfaces
br-vlan2 7fff.a0f3c15eb708 no ...
If virbr0 is a bridge, then how can it also function as a NAT?
Well, it doesn't. But the system itself has a port in the bridge, and if there's an IP address set on the bridge, then it can do routing/forwarding/NAT between the bridge and some other interface.
So, assuming you have, say eth0 as the uplink and virbr0 bridging the VMs, which show up as vmnic0 ...
Maybe you have it backwards. You don't bridge br0 onto eth0, but eth0 onto br0. And yes, you can put any number of devices on a bridge, so you can also put eth1 and eth2 onto br0, using the brctl addif br0 eth1 command. Does that answer your question?
This is as simple as it could be. You do not need any bridging.
Just MASQUERADE your local network on RPi:
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Enable forwarding of traffic:
echo 1 > /proc/sys/net/ipv4/ip_forward
RPi will not work as invisible bump-on-the-wire but will need a network setup between
it and your private router – which ...
It doesn't sound like 'bridging' is what you're looking for, it sounds like you want your Pi to act as an access point and share the internet it sees on wlan0 via a new SSID on wlan1.
See this guide for details on how to set that up: