Are LAN0 and LAN1 bridged in hardware?

[deleted]

@barryf – Thank you for explaining this; I’m starting to get an idea on how it works.
I might still need to dig deeper into the details, but it’s certainly a good starting point. 🙂
(I just got a notification from GlobalScale that my two boards have been shipped from th US; FedEx estimates them to arrive next week).

[boozel]

Hi

Has anyone found a way to re-configure the Topaz switch to un-bridge LAN0 and LAN1?

[doron]

Has anyone found a way to re-configure the Topaz switch to un-bridge LAN0 and LAN1?

LAN0 and LAN1 are bridged only upon power on (or hard reset) of the board. When you load your OS they become separate interfaces having separate broadcast domains. A soft reboot does not return them to a bridged state. A hard reset (reset button) or a power cycle, does (until the OS loads).

So in the period between a board reset and full OS load, the interfaces are bridged. If the OS fails to boot for some reason, they will remain bridged.

It appears as if undoing this short-term bridging would require (a) the latest u-boot code, compiled and flashed into the unit, and (b) a Device Tree Blob (dtb) file which marks the interfaces as “disabled”, in a new bitmap mask field. This would ensure that from power on or reset until the OS completes the boot, the interfaces will remain disabled. I have not done that (yet), mainly out of concern of bricking the board 🙂

Hope this helps.

[doron]

Specifically when you run:

Marvell>> setenv image_name boot/Image
Marvell>> setenv fdt_name boot/armada-3720-community.dtb

I am running off a microSD card.

I believe these apply to the OS load stage. The open question is how to affect u-boot’s view of the world, in terms of eth ports (keeping them disabled). I would guess this would have to do with the actual u-boot image (perhaps a dtb which is linked into the u-boot image?).

[deleted]

I have not done that (yet), mainly out of concern of bricking the board

This is actually for anyone who’s afraid of bricking the board.
Fortunately, the EspressoBIN isn’t as fragile as many TV-boxes are.
(I bricked a CS912 and I ended up having to flash it each time I wanted to use it, as it forgot the operating system).

First of all: The EspressoBIN’s can be set to boot by Nor (SPI-flash) as default.
This is what’s been chosen from the factory (the 3 jumpers near the reset button).
In case you want to change that, you have several other options, one includes booting from SATA.
The SATA boot will be what I’ll be using for my boards (when I get a 2.5″ SATA drive).
That means the CPU will not attempt to load uboot from the SPI-flash, thus even if the SPI flash is filled with zeroes, ones or random data, it won’t affect SATA boot.

There is a tutorial for setting up EspressoBIN to boot from SATA for those who want this behaviour instead.

The other boot options are not described directly on the Web-site, but on the last page of the EspressoBIN Quick Start Guide PDF from GlobalScale (note: downloading this file might require several attempts).
Possible settings:
Serial Nor Flash: J10=on, J3=off, J11=off
eMMC: J10=off, J3=on, J11=off
eMMC Alternate: J10=on, J3=on, J11=off
SATA: J10=off, J3=off, J11=on
Serial NAND: J10=on, J3=off, J11=on
Boot via UART: J10=off, J3=on, J11=on
(“on” = short the two pins closest to the reset button, “off” = short the center pin and the pin farthest away from the reset button).

In addition to this, we’re very fortunate that GlobalScale picked a SO8 package for the SPI flash (U10).
If you have a decent soldering iron and everything else fails, you should be able to unsolder the SPI flash and replace it by one you’ve programmed by using an external programmer.
(Note: You might not even have to do this, as I’m pretty sure you could supply voltage to the GND/VCC pins of the SPI flash, then use something simple as a Cortex-M chip to flash-program it without desolering it, but make sure you do not give the SPI-flash a higher voltage than the board does; personally, I’d prefer unsoldering the IC, then programming it and soldering it back in or replacing it by a programmed IC of the same type).

BTW: I received my two boards today. 🙂

[barryf]

Interesting stuff @pacman

Now, if I could only get the ability to wireshark the traffic over the LAN0 and LAN1 interfaces – or ANY interface – this would be a useful board for me.

[deleted]

Now, if I could only get the ability to wireshark the traffic over the LAN0 and LAN1 interfaces – or ANY interface.

Does this include other kinds of interfaces such as USB?
-If so, then I’m pretty sure that any linux-box can do packet-sniffing on USB.
But as I’m no expert on Ethernet or TCP/IP, I’ll leave the question about the LAN interfaces to those who can give an answer that’d make sense. 😉
I do think that it’d be possible to insert the EspressoBIN between two devices and monitor the network traffic, though, but I don’t know whether that’s a “Linux question” or an “EspressoBIN question” or both.

[barryf]

Yes, it works with normal ports -USB or otherwise. However the Espressobin seems to operate all three ports in switch mode and I have not been able to see traffic passing between any of the ports – only traffic I can see is what is destined for the single port I am sniffing.

This board is interesting to me because of its price and built-in NICs, but only if I can mirror/sniff the packets crossing the LANX ports.

[doron]

@barryf,

Now, if I could only get the ability to wireshark the traffic over the LAN0 and LAN1 interfaces – or ANY interface – this would be a useful board for me.

You sure can – I do tcpdump off of lan1 / lan0 on this board all the time. You can create pcaps to your heart’s content.

[barryf]

@doron

I mean wireshark the traffic flowing FROM LAN0 to LAN1 not the individual ports.

I want to put this device in-line like:

               w'shark
                  ^
DEVICE ---- LAN0 --- LAN1 ---- ROUTER

[doron]

@barryf,

I mean wireshark the traffic flowing FROM LAN0 to LAN1 not the individual ports.

Yes, understood. Please check my previous message here.

Once an OS is loaded, lan0 and lan1 are not bridged any more. Traffic flowing from one to the other would be traffic that has gone through the OS network stack. Typically it would be routed (in which case you need the devices on the LAN segments to be cognizant of your presence, addr/gw/mask and all). It sounds like you are looking for an “insertion” type of functionality. In that case you will need to explicitly perform bridging between lan0 and lan1 in the OS (a kernel with CONFIG_BRIDGE, and brctl). Then, those packets (frames, to be precise) will flow through your s/w bridge and you will be able to sniff them (you will also need to add NF BRIDGE support into your kernel).

If you don’t do all that, there is no bridging.

Either way, I believe you can sniff whatever flows between lan0 and lan1.

[barryf]

Thanks @doron

I do have a sw bridge br0 set up with lan0 & lan1 as members, and have compiled my kernel with all network/bridge related stuff enabled. Still don’t see anything. The bridging works because I have a voip phone connected through it and it works fine – I just can’t see the packets.

I’ll try a new kernel compile

[doron]

@barryf

So I have just tried what I said above (new kernel, brctl etc.).
brctl builds the bridge fine and lan0+lan1 become bridged (again). Someone on lan1 is seeing someone else on lan0, at layer 2.
However contrary to what I said above, I haven’t yet been able to get tcpdump to show unicast frames flowing between lan0 and lan1.

Either tcpdump is reading at the wrong level in the stack, or something “interesting” is going on. Such as the “bridge” kernel module activating the hardware bridge. I’m leaning towards the 1st but will have to continue tinkering with it later.

[barryf]

@doron

So I’m not going crazy :-/

It’s like the Topaz chip will only operate the ports in “switch” mode and somehow over-rides the sw bridging’s usual operation. Just guessing here.

[deleted]

I’ll try a new kernel compile

You might want to give Armbian a try; I do not know yet how different it will be on the EspressoBIN, but my experience with the Armbian builds have been very good for other boards so far.
I’m looking forward to trying Armbian myself (perhaps it’ll be easier for me to get a static IP address then).

[Author]

Posts