On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > > On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote: > > The firmware/boot loader transition to a full fledged OS with a switch > > is a tricky one to answer though, and there are no perfect answers > > AFAICT. If your SW is totally hosed, you might want the switch to > > forward traffic between all LAN ports (excluding WAN, otherwise you > > expose your home devices to the outside world, whoops). > > > > If your SW is fully operational, then the questions are: > > > > - do you want a DSA like behavior in your boot loader, in that all ports > > are separated but fully usable or do you want a dumb switch model where > > any port can forward to the CPU/management port, without any tags or > > anything (unmanaged mode) > > > > - what happens during bootloader to OS handover, should the switch be > > held in reset so as to avoid any possible indirect DMA into main memory > > as much as power saving? Should nothing happen and let the OS wipe out > > clean the setting left by the boot loader? > > > > All of these are in the realm of policy and trade offs as far as > > initializing/disruption goes, so there are no hard and fast answers. > > For a switch, there are four stages, not two: > > 1. The out-of-reset state, which from what I've seen seems to be to > behave like a dumb switch. > > 2. The boot loader state, which is generally the same as the > out-of-reset state. > > 3. The OS-booting state, which for a DSA switch in Linux isolates each > port from each other. > > 4. The OS-booted state, which depends on the system configuration. > > If you are setting up a switch in a STP environment, you _have_ to be > aware of all of those states, and plan your network accordingly. > While it's possible to argue that the boot loader should isolate the > ports, it may be that the system gets hosed to the point that the boot > loader is unable to run - then you have a switch operating in a STP > environment acting as a dumb switch. > > The same actually goes for many switches - consider your typical DSL > router integrated with a four port switch. By default, that switch > forwards traffic between each port. If you've setup the ports to be > isolated, each time the router is rebooted (e.g., due to a > configuration change) it will forward traffic between all ports until > the routers OS has finished booting and applied the switch > configuration. > > What I'm basically saying is that if you're going to the point of > using such hardware in a STP environment, you _must_ pay attention > to the behaviour of the hardware through all phases of its operation > and consider the consequences should it fail in any of those phases. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up
Hi Russell, The dumb switch was just an example. The absolute same thing (unwanted PHY connection) applies to regular NICs. I am not aware of any setting that makes the MAC ignore frames as long as they observe the appropriate MII spec. And the hardware will go on to process those frames, potentially calling into the operating system and making it susceptible to denial of service. That is unless you set up your buffer rings/queues/whatever in the ndo_open/ndo_close callbacks. The point is that having a way to make a link dead/have it dead by default is the easiest way to prevent a lot of problems. Call that policy, whatever, but I think at the very least the Linux kernel should have a way to operate in this mode (if not even be the default one, unless the user knows better). Regards, -Vladimir
