I was wondering why PoE doesn't work. I tried original firmware AND a second Zyxel with original firmware but PoE didn't work on my Alfa routers. Hence the issue is with the routers which obviously don't support "standard" PoE (for which they are well known). Need to postpone this until I have compliant devices.
bmork, I started compiling your branch. And meanwhile I took the latest snapshot and flashed it and I was really surprised that my 1000Base-T SFP module did suddenly work! Did an upstream merge happen?
Hence I didn't tested your realtek-fixes branch image (which meanwhile was successfully built). If it makes sense for you then I can test it.
That is surprising. I could not get mine to work with at least the MODE_NA fix and the Marvell 88E1111 phy driver.
What does your log look like? Can you install ethtool and play with it? Does speed and duplex negotioation work? I am ready for more suprises
No need to test my branch, BTW. I bit the bullet and tested myself. The only thing that failed was the SX SFP. Which was a bummer for me, since that was my only link to that switch and all the connected devices....
Anyway, I went out there and reconnected the console so I can di some testing again. And used the opportunity to test hotplugging of a 1000Base-T SFP.. Which worked fine. Pretty weird. But it did eventually ring a bell: I saw this before when link state interrupts were failing. And looking at my GS108Tv3 running the same image, I see that this is now the problem again. Even after disconnecting and reconnecting a cable I have zilch here:
How does that look for you? Do you see link-state interrupts? Funny thing is that anything with a phy will still work. But the fibre SFPs fail to come up. Do you have any fibre SFP to test with as well? Would be good to have someone else verify my findings, as I tend to jump to conclusions
Yes, fibre sfps should work on master. They fail for me because I re-enabled the sfp, without noticing that the link-state irq is still broken. I thought I bugged you about that a long time ago?
Anyway, will verify my fix on the GS108Tv3 and then do another attempt on the GS1900-10HP.
Still don't understand how the copper SFPs works with current master. I thought they would need some interface setup?
Oops, I have that fixed in my development branch, I think it got accidentally broken by some work on the IRQ driver. It's not obvious when this is broken since phylink polls the MDIO bus also for link changes and triggers the necessary updates even in absence of an IRQ. But then I really rely on that IRQ to trigger printing of debug output during development I am away from my gear at the moment, next weekend I am back and will submit a patch.
BTW: I am still working on the L3 routing support, it is just that it has so many hardware tables for next hops, interfaces, source macs of interfaces, MTUs for interfaces, L2 forwarding database entries and finally routes which all need to be correctly linked to each other that it is very easy to get something wrong upon which these devices show their usual informative and graceful fail behavior: the router just does nothing. Also the kernel integration is a bit of work since one needs to send ARP requests and wait for answers to update the next-hop entries with the proper macs of e.g. a gateway IP. But that part is written and actually works, in contrast to the hardware part...
I found a lot of hits with "G" about "can PoE". But almost everything was PR stuff.
I searched for technical specs. But all I found was "PoE passive 12V".
root@OpenWrt:~# ethtool -s lan9 speed 10 duplex full
Cannot set new settings: Invalid argument
not setting speed
not setting duplex
root@OpenWrt:~# ethtool lan9
Settings for lan9:
Supported ports: [ MII ]
Supported link modes: 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
realtek-fixes branch:
I saw boot messages up to "hit enter" but no key did show any reaction, console was dead. SFP did not work, led was off.
You're probably going to hate me now, but I just fired what I have to the mailing list. These features are something I actually use, and one of the reasons I like open source is that I can stuff the things I use upstream...
And I just submitted @blogic's PoE daemon too. Can't see any valid reason for keeping it hidden like that. It can always be dropped if there ever is a replacement. For now, new users need to find the package.
@Borromini I've had the exact same experience with my D-Link DGS-1210-16 rev. G. The switch sits between my computer and my router. I can ping and ssh the switch from my computer, but not from the router. But traffic passes through.
To make it even weirder, this happens only when my router is connected to Port 1 (lan1) of the DGS-1210-16. When I plug the router into Port 2 (lan2) instead, I can immediately ping and ssh it without problems. Both ports are configured the same way. No iptables, ebtables or the like in place. I even flushed arp tables and rebooted all systems (DGS-1210-16, router, computer) without any change.
The default configuration of the switch has a management vlan with ID 100 configured for port 1 which uses DHCP to get an IP address. All other ports have VLAN ID 1, and are reachable at 192.168.1.1. These ports offer DHCP. Port 1 is so to say set up as a WAN port which cannot be reached via ssh. Have a look at /etc/config/network after installation. There was a lot of discussion about how the default configuration of the switches should look like, this was the outcome.
Many thanks for the hint, @anon13997276 . I stumbled upon that when flashing the device, but luckily I had a serial console to investigate. I then removed the WAN parts from /etc/config/network and added lan1 to LAN. That's why I wrote that lan1 and lan2 are configured identical. The packages ppp, dnsmasq, firewall, ip6tables, iptables and odhcpd-ipv6only are omitted from my build because I just want pure switching, no routing.
@ajoeiam , it depends on what you call a "non-dev level of user".
You need to open the case, connect to a (non-populated) serial header, provide the initial file on a TFTP server, boot it via the bootloader, stop the firewall (or configure VLAN100 on a second device), upload the sysupgrade file via SCP and flash it.
I'm not a dev and can handle these tasks, but other users probably won't.
@ajoeiam , it depends on what you call a "non-dev level of user".
You need to open the case, connect to a (non-populated) serial header, provide the initial file on a TFTP server, boot it via the bootloader, stop the firewall (or configure VLAN100 on a second device), upload the sysupgrade file via SCP and flash it.
I'm not a dev and can handle these tasks, but other users probably won't.
With a pic to accurately identify the first and clear (de)structions (my goofy humor intruding) on the rest I think it might be time to get a GX1900 24 to give this a whirl.
(Driving the need to experiment is trying to come up with a way of having a private network inside another network and at the same time carefully controlling outside access from even the network.
Trying to very much minimize intrusion possibilities AND information harvesting!!)
Note that a number of supported devices have populated headers. I believe all the ZyXELs have them. Some models, like the GS1900-10HP, even allow access to the header without opening the case. through a hole made for this purpose.
It is also possible to flash OpenWrt from stock web UI, at least on some models. But console is still recommended for now. The default OpenWrt network config is difficult to work with, and the uboot-envtools are not properly configured if you want to change bootpartition (e.g going back to stock). So you should be prepared to use the console, even if you test out flashing from stock.
Need to postpone this until I have compliant devices.
I am away from my gear at the moment, next weekend I am back and will submit a patch.
