Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We want to create bridge (mybridge) on our board over eth0 and eth1 interface. The board runs Linux 2.6.34.9.

Following are the commands:

brctl addbr mybridge
ifconfig eth1 0.0.0.0
ifconfig eth0 0.0.0.0
brctl addif mybridge eth1
brctl addif mybridge eth0
ifconfig mybridge up

PC-----ETH1-----mybridge-------ETH0

When we ping the board from a PC, we are able to receive packet on eth1 (eth1 rx counter increasing), but they are not getting transferred to mybridge, since the rx counter on mybridge is not increasing. After little search on net we found that mybridge is up but not going to RUNNING mode. Unless it goes to RUNNING mode, the bridge will not work.

Can anyone please let us why mybridge is not entering RUNNING state?

/ # ifconfig
eth0      Link encap:Ethernet  HWaddr BC:9A:78:56:34:12  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  HWaddr 00:E0:0C:BC:E0:00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:101 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7200 (7.0 KiB)  TX bytes:126 (126.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

mybridge  Link encap:Ethernet  HWaddr 00:E0:0C:BC:E0:00  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Any sort of input will be of great help.

share|improve this question
    
How exactly are you "pinging". You don't have an IP address. Your bridge is just a bridge. You don't have an IP interface on it, so nothing is meant to receive packets there. You're just switching/bridging accross eth0 and eth1. –  Stephane Chazelas Sep 15 '12 at 16:51
    
No IPs anywhere? What are trying to accomplish with that bridge? –  Nils Sep 15 '12 at 22:02
add comment

2 Answers

You cannot ping the board, because the board does not have an IP address. It is not clear exactly what you are doing here.

Packets are not going through the bridge on the board because there is nothing hanging off eth0 of the board. If you plug a device into eth0 and ping that, you should see the packets go through the bridge.

There may be two reasons why the packet counter of eth0 is not increasing:

1) The bridge operates somewhat like a switch, in that it keeps track of the MAC addresses of the devices behind each port of the bridge. If you run the command brctl showmacs mybridge, you can see the MAC addresses of the devices the bridge has seen and which port they are behind.

If you plug a device into eth0 and try and ping it, the pinging host will first broadcast an ARP request to discover the MAC address of the host with the IP address to ping. When that host response to the ARP request, the bridge will see that the host with that MAC address is behind eth0 of the bridge. However, I would expect to see the ARP broadcasts be counted against the interface, so while you'd have a low packet/byte count on eth0, it should be non-zero.

2) There is nothing plugged into eth0, hence it has no carrier. There is no point sending packets on an interface that is unplugged. You can see this with the 'ip link' command (the ip command deprecates the ifconfig command - you can see the interface counters with ip -s link). You will see NO-CARRIER against eth0.

share|improve this answer
    
Hi first of all thanks for reply.. –  sumit Sep 17 '12 at 11:01
    
We assigned the IP to bridge but still same result.We carried same test on PC (running ubuntu),by bridging wireless port and Lan port by using following commands sudo ifconfig eth0 0.0.0.0 sudo ifconfig wlan0 0.0.0.0 sudo brctl addbr mybridge sudo brctl addif mybridge eth0 sudo brctl addif mybridge wlan0 sudo ifconfig mybridge 192.168.1.45 netmask 255.255.255.0 sudo ifconfig mybridge up Here we are able to ping to bridge from another system over wireless. And also mybridge show RUNNING UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 –  sumit Sep 17 '12 at 11:03
    
we would like add further that kernel running on PC ---- 3.0.0-24-generic kernel running on Board ---- 2.6.39.4 Can there be any kernel issue like we need to add any patch to 2.6.39.4 Any sort of input will be of great help, Thanks in advance Thanks & Regards Sumit –  sumit Sep 17 '12 at 11:12
    
You did not say "wireless" in your question. That is very important. Bridging wireless is tricky and often not possible, without some hardware-specific configuration or code. To bridge to wireless, you need to use the 4-address format instead of the regular 3-address format. I have not done wifi bridging for a number of years, so I do not know what the current state is. –  camh Sep 18 '12 at 10:22
add comment

I had the same issue but I solved it by specifying HDADDR parameter in each eth config . so you need to find out the interface mac address by using ifconfig -a command and after that edit each interface config file in /etc/sysconfig/network-scripts/ifcfg-ethX and specify the exact mac address for each interface card. this is also advised by redhat to specify interface HDADDR when you have more that one physical interface card .

" HWADDR=MAC-address where MAC-address is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive must be used in machines containing more than one NIC to ensure that the interfaces are assigned the correct device names regardless of the configured load order for each NIC's module. This directive should not be used in conjunction with MACADDR.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-interfaces.html "

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.