Sitecom WLR-8100 different versions

Installing and Using OpenWrt
1

I have two WLR-8100 v1.001 running OpenWRT 19.07.4 now for a couple of weeks. One is the router connecting to a fiber ISP. The second is an extra AP, also providing the guest access. Everything seems to be working as expected. IPv4 and IPv6 over pppoe is smooth. And stable VLAN, WLAN and Switching on both. IGMP works as expected. Have not found a glitch in the performance so far. Way (!!) more stable than Sitecom’s firmware which required a reboot at least once a week. Great to have these devices in extended service. I even returned the Fritzbox 5490 (ISP offering) in favor of the WLR-8100... The WLR-8100 connects to fiber via a simple managed media converter from FS.com.

Comments:

  1. The LAN ports in OpenWRT are numbered in reverse (compared to the casing)
  2. The leds for 5GHz and 2.4Ghz are not working properly
  3. The power LED is not flashing during boot. Failsafe is present but a bit of guessing when to press a button is required...
  4. It has sufficient power to do sqm effectively

If have not tested hardware NAT since my fiber connection is just 100Mbit.

I have also flashed OpenWRT 19.07.4 to a WLR-8100 v1.002. They (the v1.001 and v1.002) seem identical (PCB) but they are not:

Several unexpected issues with the WLAN: random disconnects, reconnects and disappearing SSID. Different chipset iteration it seems if I read the specs on the OpenWRT page. And that means different drivers and config I assume.

I flashed the V1.002 with the current SNAPSHOT release on the ath79 target for the v1.002 device and will test it again the coming weeks.

Any suggestions how I can help the v1.001 device move from ar71xx to ath79 target? And the v1.002 from snapshot to stable? I’m willing to test some scenarios.

@bobafetthotmail

2

If the issues mentioned are in ar71xx, there are low chances anyone will care about merging fixes there, as it's a dead target now. Only security patches will get to it.

I'm not following the Hardware NAT development/support but I wouldn't be surprised if it isn't working, or if it is still mutually exclusive with SQM.

Port number and LEDs are defined in per-device hardware definition files, and one of the main reasons to change from ar71xx to ath79 was to use a better type of hardware definition file, and also what Linux upstream does.
So I think that those issues should be fixed by just migrating to ath79. Just make sure you don't preserve any old configuration.

As for the device revisions, the devices seem the same, and afaik both wifi chipset revisions are supported by the same driver and firmware packages, probably the driver and firmware package in 19.07 is too old or buggy for that chipset revision.

From the commit that added support for your device(s) in ath79 target (and what I said above) https://github.com/openwrt/openwrt/commit/dfb7a4ce5d3200c5cb4b12c8a90b2fcc7d66f6bd it does not seem there is a difference between the two hardware revisions, as the guy did not make two different hardware definition files and there is a single download with no hardware revision in the name. I think you can use the same firmware for both your devices.

All devices in snapshot will go into next stable release, so it's just a matter of waiting.

If you want to test and report issues in the snapshot builds here (and possibly in the bug tracker as well https://bugs.openwrt.org/ ) or send an email to the guy that added support for your device, you can do so.

Since you mention VLANs, I think they are now handled differently in ath79 (and most other targets) as they are now using the modern DSA switch interface from upstream like all other devices in OpenWrt.
The main difference is that each port in the switch appears as its own interface, eth0 eth1 eth2 and so on, and tools like swconfig (and the Luci web interface for switches) don't work anymore.

Configuration through UCI (OpenWrt's unified text file configuration system, accessible from commandline) was added a few months ago and you can read a tiny bit about how it is supposed to work in this commit where the feature was added https://github.com/openwrt/openwrt/commit/96b87196b0788d4cdaa81a49a65d198d9f6c90d2
and the cover letter for that in the mailing list where it goes more in depth and provides some examples https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg53505.html

Since now UCI supports that, it will be added to Luci web interface in a few months, for now this is the issue ticket about that https://github.com/openwrt/luci/issues/2798

You can also search/ask in the forum about DSA switches and VLANs, but they probably won't talk about this new UCI functionality.

If you used the above info to set up successfully the VLANs in your devices with the new UCI system, please share what you did and what you wrote in your configuration, I'll integrate it in the wiki when I write the page that documents this new UCI functionality.

1 Like
3

Thank you for providing so much detailed information.

You are correct: the stable 19.07.4 firmware is in the ar71xx target. Works flawless, even with the older drivers and kernel, for the WLR-8100 v1.001 but it has unstable WLAN for the v1.002, likely due to the newer revision of the chipset.

Thank you for informing about the different switch interface in the current ath79 target. The snapshot for the WLR-8100 (v1.002) is in this target and I flashed this version.

I understand the configuration files between target ar71xxx and ath79 are incompatible. Makes sense as the switch interface is working differently, amongst others.

I started testing the snapshot on the v1.002, but realize I need to start configuring from scratch and will need to use CLI and UCI for at least the VLAN configuration to get my internet working.

First comments:

  • The failsafe period is visible now (flashing power LED)
  • The WLAN LEDS work
  • LUCI can be installed
  • PPPoE works
  • The Switch config page (in Luci) does not work (as explained by you)
  • So I cannot get my internet connection to work on VLAN6 from my ISP

I wish to learn how to configure the switch to get the VLAN6 working. However, I'm not yet comfortable with CLI, let alone UCI. And I also lack time.... But I will follow-up on the links you provided and message the guy that added support for the device.

It is tempting to wait for UCI support in a future LUCI version... :slight_smile:

Any thoughts?

4

Do you need to use VLANs to connect to your ISP? That's strange. What is the configuration on the other device where it works correctly?

Also, it seems the regulars here are not aware of the new UCI backend for VLAN configuration, which should allow to do set VLANs again without much fuss. I'll drop the news in a thread and see if someone with more time than me (and you) can learn how to use it.

5

The Luci interface for the DSA switching interface is being worked on in this ticket https://github.com/openwrt/luci/pull/4307
(see the 5th image for what it's going to look like)
so you can check when it is eventually merged

6

I converted one of my devices recently. I own the Sitecom WLR-8100 v1.001 also. But I did not convert it yet. DSA/VLAN is not that complicated (I had difficulties too :D). You just have to realize that there is no switch definition available by default anymore.

marcin1j made a good assumption how to do it in the link which @bobafetthotmail provided to you.

But I would recommend to wait and stick to stable release because it is still in flow and wireless is not handled properly by uci atm.

1 Like
7

I know more ISP's (in NL) that use different VLAN's for internet, IPTV and telephony. Easier to manage I suppose? I configured VLAN6 to have the WAN port tagged and CPU tagged, LAN ports off. VLAN1 is CPU tagged all LAN ports untagged, WAN off (19.07.4 using LUCI). Then VLAN1 and WLAN's are bridged on the LAN interface. The WAN interface connects via PPPoE with MTU of 1452 (and mss clamping enabled in the WAN firewall zone).

I'm in touch with the guy that added support. So I got the right connection now to get the devices in good working order on the ath79 target and at the same time do some testing...

8

Thanks for chiming in!

Waiting is an option for the v1.001. The v1.002 however does not work well with the stable ar71xx target 19.07.4 firmware: unstable WLAN.

I will try to get the VLAN6 connection work on the v1.002 using the snapshot and some guts and glories...

9

Mystery solved: the ath79 target for the WLR-8100, with switch chip QCA8337N, is still using the old swconfig. DSA will not be used anytime soon is expected. See this thread: Interfaces are swapped in nanostation-m from 18.x to 19.x

Thanks Davide for pointing this.

The current snapshot works sable on the WLR-8100v1.002 (as expected). VLAN6 can be selected in the LUCI switch config page. Only one issue: The LAN leds stay off when a fast ethernet device is connected. But this bug is reported and might be solved in the stable release.

Currently testing the snapshot on the WLR-8100 v1.001. Seems as stable as the v1.002. Will report back later.

1 Like
10

The WLR-8100 v1.001 is 4 days stable on the SNAPSHOT. No reboots, no issues. I would suggest both v1.001 and v1.002 run stable on the ath79 target snapshot. Just the fast ethernet LED function is not working yet.

Does the hardware offload function work for this router? And if it works, what functionality is disabled (qos, sqm, IGMP snooping etc)?

The original OEM firmware for this router was capable (calling it hardware acceleration) but it said it disabled QoS.

Would it be helpful if there is a OpenWRT hardware offloading support table where chipsets and compatibility can be looked up?

11

the feature is called "hardware flow offloading" in OpenWrt and is a checkbox in the Firewall section. It will disable SQM/QoS. It probably won't work on your device because only devices with Mediatek MT7621 chipset work, and your device has a Qualcomm chipset.
I think the supported chipsets are stated in Luci web interface.

There is another feature called "software flow offloading" that is not using the hardware accelerator and should work in all devices, it's a bit slower than using the hardware accelerator but still around twice as fast as normal. Disables SQM/QoS as well.

See this blog for an actual test done by someone else https://www.leowkahman.com/2020/02/01/speedtest-openwrt-with-flow-offloading/

1 Like