OpenWrt 18.06 malformed ip packets at bridged interface


#1

Hello,

I’ve installed OpenWrt18.06 on SD-Card ad described here: BananaPI BPI-R2 Openwrt18.06 Demo Image and Source Code Release 2019-03-06

The image is starting, connecting to wan is working, services seem also to be started.

Only the communication over the bridged interfaces is not working, and generating malformed IP packets.

If you ping the BPI-R2, ARP is working fine, but in the response data are missing 6 Bytes of data

root@OpenWrt:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ec23:c4ff:fe84:6d07/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether aa:c0:1e:0b:21:49 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a8c0:1eff:fe0b:2149/64 scope link 
       valid_lft forever preferred_lft forever
4: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether aa:c0:1e:0b:21:49 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.121/24 brd 192.168.0.255 scope global wan
       valid_lft forever preferred_lft forever
    inet6 fe80::a8c0:1eff:fe0b:2149/64 scope link 
       valid_lft forever preferred_lft forever
5: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ee:23:c4:84:6d:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd3b:a012:24ec::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ec23:c4ff:fe84:6d07/64 scope link 
       valid_lft forever preferred_lft forever`

.

root@OpenWrt:/# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.ee23c4846d07       no              lan0
                                                        lan1
                                                        lan2
                                                        lan3

ping.pcap (1.6 KB) http.pcap (5.6 KB)


(Frank W.) #2

Can you look in builddir (dts/dtsi) if rgmii-mode for gmac0 and 1 is same? If not change both to trgmii and compile again…i think this patch is missing


BananaPI BPI-R2 Openwrt18.06 Demo Image and Source Code Release 2019-03-06
Banana Pi BPI-R2 new image : Official OpenWRT 18.06.0
#3

Thank you frank-w, now the communication is working on the second interface too.

This time I build the Image myself like described in the post mentioned in my first post. The settings described in the patch have been already in the dts file supplied by Jackzeng.

But I have no idea why the supplied SD-Card image is not working.


(Frank W.) #4

I do not see this patch in official repo…second gmac comes by patch

Where do you see that both gmacs are set to same value?

btw. you can go through sysfs and show the values set in dts

cat /sys/firmware/devicetree/base/ethernet@1b100000/mac@0/phy-mode
cat /sys/firmware/devicetree/base/ethernet@1b100000/mac@1/phy-mode

#5

Yes, thats why i have used the dts files from BananaPI BPI-R2 Openwrt18.06 Demo Image and Source Code Release 2019-03-06

Here both types are set to trgmii:

root@OpenWrt:~# cat /sys/firmware/devicetree/base/ethernet@1b100000/mac@0/phy-mode
trgmii
root@OpenWrt:~# cat /sys/firmware/devicetree/base/ethernet@1b100000/mac@1/phy-mode
trgmii

Here are all commands how i have build the image:

sudo apt install build-essential libncurses5-dev python unzip git  
git clone https://github.com/BPI-SINOVOIP/openwrt.git
cd openwrt
git checkout -b openwrt-18.06 remotes/origin/openwrt-18.06

./scripts/feeds update -a
./scripts/feeds install -a

make menuconfig
    Target System (MediaTek Ralink ARM)                                                                                                               
    Subtarget (MT7623)                                                                                                                       
    Target Profile (MTK7623n BananaPi R2) 

make
cp ~/Downloads/mt7623.dtsi build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/linux-4.14.105/arch/arm/boot/
cp ~/Downloads/mt7623n-bananapi-bpi-r2.dts build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/linux-4.14.105/arch/arm/boot/
make
sudo bpi-copy build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/mtk-bpi-r2-SD.img /dev/sdb

(Frank W.) #6

ok, thank you…i missed these file from thread there…i have only searched on github…as far as i know this is only a workaround, because second gmac does not support trgmii-mode, but if both gmacs set to different value the packets get damaged

currently i’m testing some phylink-patches on r2 and we stumpled over this again