When devices connected to different LAN ports on an OpenWRT-powered WBMR-HP-G300H router can't communicate, while wireless clients can reach both, we're typically dealing with a switch configuration issue. The key observations are:

• Ping works from router to all wired clients
• Wireless clients can reach all wired devices
• Cross-port communication fails with "destination unreachable"
• All devices share the same subnet (10.0.0.0/24)

The swconfig output reveals the root cause:

Global attributes:
        enable_vlan: 0
Port 0:
        pvid: 0
Port 1:
        pvid: 0
...

Critical findings:

• VLAN functionality is disabled (enable_vlan: 0)
• All ports have PVID (Port VLAN ID) set to 0 (invalid)
• The bridge shows only wlan0 and eth0 as members

Edit /etc/config/network to implement correct VLAN tagging:

config device
        option name 'eth0'
        option type 'bridge'
        option macaddr '00:24:A5:BD:66:08'

config switch
        option name 'eth0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'eth0'
        option vlan '1'
        option ports '0 1 2 3 4 5t'
        option vid '1'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '10.0.0.1'

The essential elements in this solution:

• VLAN tagging enabled (enable_vlan '1')
• All physical ports (0-4) assigned to VLAN 1
• CPU port tagged (5t) for proper bridging
• Bridge interface uses eth0.1 instead of raw eth0

After applying changes and rebooting:

# Check VLAN assignments
swconfig dev eth0 show

# Verify bridge membership
brctl show

# Test connectivity
ping -c 3 10.0.0.2

Based on multiple troubleshooting cases:

• Never leave PVID at 0 - always assign valid VLAN IDs
• Ensure the CPU port is properly tagged (suffix 't')
• Double-check interface naming in bridge configuration
• Remember that changes require either service restart or reboot

If communication is still blocked, check firewall rules:

# Allow LAN-to-LAN traffic
uci add firewall rule
uci set firewall.@rule[-1].name='Allow-LAN-to-LAN'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

When working with OpenWRT on Buffalo WBMR-HP-G300H routers, a common network configuration issue emerges where devices connected to different LAN ports cannot communicate, despite being in the same subnet. This manifests as "destination unreachable" errors when attempting ping tests between wired clients.

The root cause typically lies in the VLAN and bridge configuration. Examining the swconfig output shows VLAN functionality is disabled (enable_vlan: 0), and all ports have pvid: 0, indicating no proper VLAN assignment:

Global attributes:
        enable_vlan: 0
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex

The current bridge configuration shows only wlan0 and eth0 are bridged, which explains why wireless clients can communicate but wired clients cannot:

bridge name     bridge id               STP enabled     interfaces
br-lan          8000.0024a5bd6608       no              wlan0
                                                        eth0

To properly configure LAN port communication, we need to modify both the switch and bridge settings. Here's the complete working configuration for /etc/config/network:

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '10.0.0.1'
        option netmask '255.255.255.0'
        option ifname 'eth0.1'

config switch
        option name 'eth0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'eth0'
        option vlan '1'
        option ports '0 1 2 3 4 5'
        option vid '1'

After applying these changes and rebooting, verify with these commands:

# Verify VLAN assignment
swconfig dev eth0 show

# Check bridge members
brctl show

# Test port-to-port connectivity
ping -c 4 10.0.0.2

If you lose access during configuration:

• Use wireless connection to revert changes
• Check system logs with logread
• Verify physical port numbering matches software configuration