Modify

Opened 3 years ago

Last modified 3 years ago

#18433 new defect

cannot run OpenWrt on new rb951g batch

Reported by: iainf Owned by: developers
Priority: normal Milestone:
Component: packages Version: Trunk
Keywords: Cc:

Description

The new batch has MAC address prefix change to 4C:5E:0C:*:*:*

Using the usual DHCP boot over ethernet method, I can see the initrd kernel being transferred. However it cannot be pinged or telnet. I monitor the traffic and noticed it would reply occasionally to arp, say every 1 in 5 arp requests it would respond to.

So its definitely running but something is broken, I had a simliar issue years ago on different board and I remember it being the switch which I believe is AR8327. Maybe they've upgrade the switch.

Attachments (0)

Change History (13)

comment:1 Changed 3 years ago by iainf

Ok, I got some information MikroTik, hopefully this can help:

Yes, to support newer RouterOS kernel, RouterBOOT has been slightly changed. To support this new RouterBOOT, you have to modify your software slightly, you have to put an offset so that RouterBOOT finds the kernel in the place it is looking in.

We do not officially support any other OS on our products, therefore we don't
have specific instructions for this procedure.

Such changes don't come often, this is the first time. If you see that the board
comes with newer RouterBOOT, check compatibility with your OS just in case.

Before you ask, downgrade of RouterBOOT will not help.

comment:2 Changed 3 years ago by anonymous

I have two Mikrotik with same problems, but downgrade Routerboot not solve this problem. Boards not respond to ping.

comment:3 Changed 3 years ago by dhutchison@…

I am also experiencing issues with this batch of boards. I have been able to get into the device over serial. If I do:

swconfig dev switch0 set reset
swconfig dev switch0 set enable_vlan 1
swconfig dev switch0 vlan 10 set ports '0t 1 2 3 4 5'
swconfig dev switch0 set apply

Then I can plug something into port 1 and another into port 2 and the hardware switch works. However, If I put an interface on eth0 ( The interface OpenWRT brings up as the switch )... I cannot ping / telnet into it. It's like the traffic from the board, cannot get out.

I can post a dmesg if needed, however it looks like the switch chip is initializing OK.

comment:4 follow-up: Changed 3 years ago by dhutchison@…

Looks like when I run the latest trunk, the RB951G just constantly reboots as soon as the switch is initialized.

I tried taking out patches manually and I can get the hardware to act as a switch at r 39076 of ar8216.c

As soon as I added the cleanup patch, it began rebooting.
When I stripped the patches for cleanup, Disable EEE, and Tagged/Untagged... I could get the hardware to run as just a switch..

I ended up checking out the latest trunk for more testing, with the latest it simply reboots as soon as it attempts to initialize the switch.

comment:5 in reply to: ↑ 4 Changed 3 years ago by dhutchison@…

Replying to dhutchison@…:

Looks like when I run the latest trunk, the RB951G just constantly reboots as soon as the switch is initialized.

I tried taking out patches manually and I can get the hardware to act as a switch at r 39076 of ar8216.c

As soon as I added the cleanup patch, it began rebooting.
When I stripped the patches for cleanup, Disable EEE, and Tagged/Untagged... I could get the hardware to run as just a switch..

I ended up checking out the latest trunk for more testing, with the latest it simply reboots as soon as it attempts to initialize the switch.

My mistake here, the latest trunk ar8216.c boots up just fine. I screwed up when manually applying patches.

I'm on the latest trunk once again, however cannot route out via the eth0 interface ipv4. I don't see any arp replies as well.

comment:6 Changed 3 years ago by anonymous

Can you check with final version of Barier breaker?

comment:7 Changed 3 years ago by mspix

it's the same with final version.
I can see the DHCP requests from WAN, but possibly the answers do not reach the router.
ARP sometimes answers on LAN, but ICMP is _very_ rarely (one answer on 1500 requests).

$ ping -s 1 192.168.1.1
...
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
9 bytes from 192.168.1.1: icmp_seq=1558 ttl=64
^C
--- 192.168.1.1 ping statistics ---
2742 packets transmitted, 1 packets received, 100.0% packet loss
00:55:15.119085 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:16.135398 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:17.143056 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:18.145082 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:19.146084 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:20.147082 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:21.148117 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
00:55:21.148262 ARP, Reply 192.168.1.1 is-at 4c:5e:0c:xx:xx:xx, length 46
00:55:21.148287 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 28, length 9
00:55:22.155352 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 29, length 9
00:55:23.172130 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 30, length 9
00:55:24.173077 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 31, length 9
00:55:25.195395 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 32, length 9
00:55:26.196466 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 33, length 9

...

01:20:59.160084 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1557, length 9
01:21:00.172006 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1558, length 9
01:21:00.172271 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 24589, seq 1558, length 9
01:21:01.173011 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1559, length 9
01:21:02.173994 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1560, length 9
01:21:03.185948 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1561, length 9
01:21:04.203625 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1562, length 9
01:21:05.181456 ARP, Request who-has 192.168.1.11 tell 192.168.1.1, length 46
01:21:05.181480 ARP, Reply 192.168.1.11 is-at f4:xx:xx:xx:xx:xx, length 28
01:21:05.205292 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1563, length 9
01:21:06.181479 ARP, Request who-has 192.168.1.11 tell 192.168.1.1, length 46
01:21:06.181504 ARP, Reply 192.168.1.11 is-at f4:xx:xx:xx:xx:xx, length 28
01:21:06.206312 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1564, length 9
01:21:07.181518 ARP, Request who-has 192.168.1.11 tell 192.168.1.1, length 46
01:21:07.181541 ARP, Reply 192.168.1.11 is-at f4:xx:xx:xx:xx:xx, length 28
01:21:07.211953 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1565, length 9
01:21:08.212279 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1566, length 9
01:21:09.213329 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 24589, seq 1567, length 9

comment:8 Changed 3 years ago by mspix

The problem was tracked down - https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029829.html
It's working for me now by patching mach-rb95x.c

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.479 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.291 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.252 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.233 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.180 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.237 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.254 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.248 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.249 ms
^C
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.180/0.268/0.479/0.075 ms

comment:9 Changed 3 years ago by anonymus

Hi,

What change did you do in mach-rb95x.c?

comment:10 Changed 3 years ago by anonymus

What change did you do in mach-rb95x.c?

comment:12 Changed 3 years ago by anonymous

Thanks!

comment:13 Changed 3 years ago by anonymous

Please commit that proposed patch in current trunk, and someone with older model test this patch for regression. Without it 4C:5E:0C:xx:xx:xx models don't work.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.