actually, that does look what did the flip on AR150 compared to ar71xx - there, WAN port is mapped to ETH0, and LAN is ETH1
On first boot, the WAN port shows as a LAN port with an address of 192.168.1.1 - which if one is doing development work, and the local LAN is also 192.168.1.0/24, this causes an ARP conflict with the gateway…
From the GW log… GW is running pfSense on the 192.168.1.0/24 segment…
Oct 18 21:30:46 kernel arp: e4:95:6e:44:f7:ac is using my IP address 192.168.1.1 on igb1!
Which causes every host on that LAN segment to get very confused about who really is 192.168.1.1
Wonder how this impacts the failsafe recovery options with the pepe2k uboot page.
don’t have time to fix it right now - very busy with day job stuff…
Log info…
[ 0.444524] libphy: Fixed MDIO Bus: probed
[ 0.808376] ag71xx 19000000.eth: Could not connect to PHY device. Deferring p
robe.
[ 1.487758] libphy: ag71xx_mdio: probed
[ 1.491098] libphy: ar8xxx-mdio: probed
[ 1.497091] switch0: Atheros AR724X/AR933X built-in rev. 2 switch registered
on mdio-bus.0
[ 1.543352] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000
, driver=Generic PHY]
[ 1.551954] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[ 1.560582] NET: Registered protocol family 10
[ 1.571933] Segment Routing with IPv6
[ 1.574311] NET: Registered protocol family 17
[ 1.578800] 8021q: 802.1Q VLAN Support v1.8
[ 1.918985] ag71xx 19000000.eth: connected to PHY at mdio-bus.0:1f:04 [uid=00
4dd041, driver=Generic PHY]
[ 1.928510] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
and a bit further down the log where br-lan sorts itself out… (for those who might not know, first boot takes a bit as we have to build the jffs2 file system, subsequent boots take much less time.)
[ 80.340793] br-lan: port 1(eth0) entered blocking state
[ 80.344568] br-lan: port 1(eth0) entered disabled state
[ 80.350400] device eth0 entered promiscuous mode
[ 80.411887] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[ 80.504625] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 81.078304] eth0: link up (1000Mbps/Full duplex)
[ 81.088168] br-lan: port 1(eth0) entered blocking state
[ 81.091953] br-lan: port 1(eth0) entered forwarding state
[ 81.137380] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 83.960736] eth1: link up (100Mbps/Full duplex)
[ 84.011938] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 95.071990] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 95.148973] br-lan: port 2(wlan0) entered blocking state
[ 95.152841] br-lan: port 2(wlan0) entered disabled state
[ 95.158764] device wlan0 entered promiscuous mode
[ 95.162956] br-lan: port 2(wlan0) entered blocking state
[ 95.168200] br-lan: port 2(wlan0) entered forwarding state
[ 95.658824] br-lan: port 2(wlan0) entered disabled state
[ 100.358656] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 100.363866] br-lan: port 2(wlan0) entered blocking state
[ 100.368960] br-lan: port 2(wlan0) entered forwarding state
some backup info, this is from the ar9331 data sheet, and if I recall, ar9531 is the same here…
One would want the GE0 mapped out to WAN, and GE1-MDIO and MAC to be mapped out to the LAN side to ensure enough bandwidth across the LAN ports
