B1300 firmware update

kyson-lok · 2019-01-08T01:56:34.318Z

Cannot handle VLAN? Could you please explain more about what’s your usage scenario?

micmon · 2019-01-08T05:48:23.049Z

There are actually at least two posts about the VLAN problem on this forum (search “b1300”). In short: I need to trunk two VLANs (100 and 110) to a single physical port and bridge the two VLAN interfaces to one WIFI ESSID each, so traffic from each ESSID goes only to the attached VLAN and leaves the device via the trunk port. I cannot use two physical ports (only one cable) but don’t need the other two physical ports.

There is a device from ASUS using the same internal switch setup which seems to have the same problem (search OpenWRT forum) as well as a two years old patch for the driver which however never made it upstream.

UPDATE: After trying again I think I managed to set up working VLANs.

User_Felix · 2019-01-26T02:38:15.105Z

Looking forward to the update too.

kyson-lok · 2019-01-28T02:57:51.630Z

@User_Felix @micmon @Ben Testing firmware for B1300 is available, you can have a try. http://download.gl-inet.com/firmware/b1300/testing/

paulham · 2019-01-28T15:21:02.151Z

The mesh button doesn’t work (no change to the mesh LED), so mesh networking doesn’t work.

kyson-lok · 2019-01-29T04:17:06.938Z

Yup, we are optimizing mesh network now. The v3.0 testing firmware doesn’t integrated into mesh network yet.

micmon · 2019-01-29T21:48:27.147Z

Works fine for me (not using Mesh stuff). I was hoping to see the base OpenWRT updated to 18.x but sadly it is still 15.x

carrionlee · 2019-01-30T00:50:45.399Z

What? The new firmware still sticks to 15.x ?

alzhao · 2019-01-30T10:09:12.277Z

If you want to use OpenWrt 1806 then you have to use open source wifi drivers. Although these open source wifi drivers works fine, the performance does not beat Qualcomm drivers.

Qualcomm driver only works on their SDK which is based on 15.x. The good news is that now the kernel is 4.4.60.

micmon · 2019-02-02T05:45:13.486Z

Well that is unfortunate but at least I can report that the test build runs stable so far and WiFi performance seems to be excellent.

flyli924 · 2019-02-03T00:55:23.193Z

congratulation finished before spring festival

ymliang · 2019-02-06T04:37:17.384Z

@alzhao I have upgraded to this testing firmware, but the DNS over TLS doesn’t work, could you confirm this ? Thx.

reflector · 2019-02-07T03:18:50.443Z

I upgraded with don’t keep settings checked, working for me.

madscientist_42 · 2019-02-24T01:00:53.865Z

As an observation, there’s more going on with that OLD version of OpenWRT than just an old kernel. There’s things like it not working with modern USB 4G and soon to be out 5G modems, because they don’t function as a classic 3G, they’re a USB CDC-ECM device, which for the source branch you’re building out of , it just simply doesn’t work (The Black micro-bricks work just fine…but they’re using the latest LEDE derived OpenWRT…),

There’s more. It’s enough to be infuriated and deeply disappointed with GL-Inet, to be honest with you. It’s something you should’ve contemplated DEEPLY before designing the device in the FIRST place.

Someone needs to resolve this situation or offer an option for a build using the same, knowing peak performance may not be obtained. What is the performance degradation between the two classes of drivers and has anyone even looked to see if it’s an “old” issue and they’ve fixed it?

glucknet · 2019-03-24T07:32:33.215Z

Your frustration should be with Qualcomm, not GL-Inet, GLinet simply take Qualcomm’s SDK and modify it with their apps/branding. The underlying core components are all provided by the QSDK, its true that its based on openwrt, but its not as simple as adding a couple of packages etc and typing make -j4.

Its qualcomm that should update their SDK to use a more recent openwrt version, in fact, they should ideally submit code directly to openwrt and not fork it… but since they rely on closed-source hardware acceleration and their code would never get accepted into linux, they fork and do major modifications then send those tarballs to customers like GL-inet. I guess a less ideal option would be qualcomm compiling their closed source Wifi drivers against current kernels so people using mainline openwrt can leverage the higher performance, but again their modifications affect many core parts of the network stack, its not like you can uninstall ath10k and install qsdk-wlan-driver and everything works, not that simple unfortunately.

I used to be frustrated too, but its not the vendors, its the chipset developer that is to blame (this is the same case with Asus, tplink…etc, they all use sdks provided by chipset makers).

Having said all of that, you can use mainline openwrt and with some tricks (irqbalance, assigning cores), you can reach pretty respectable performance numbers with the open source drivers.

unlo · 2019-03-25T18:25:50.985Z

Perhaps you could share some insight.
I have the b1300 with latest test firmware installed.
Copying known working Wireguard and OpenVPN client configs results in the same error “no internet connection” when I press connect under the selected VPN client config.

I am of course connected to the internet when i’m attempting to connect to my VPNs.

kyson-lok · 2019-03-26T03:44:07.660Z

Could you please upgrade to the latest testing firmware?

http://download.gl-inet.com/firmware/b1300/snapshots/

madscientist_42 · 2019-03-27T01:12:38.244Z

I’d blame Qualcomm fully and totally, save for one thing. Why did GL-Inet get yowled at by myself? You chose that chipset KNOWING it had issues. They will continue down that path so long as you tacitly consider it acceptable by buying things under those conditions.

SDK? Meh… I make those for vendors and customers… Of this class of SOC and others in other segments. That gets more ire to be honest with you.

Better yet? Instead of just rebadging the OpenWRT based “SDK”, they could use the Yocto metadata layer FROM Qualcomm Innovation Center (CodeAurora…) which at least USED to have better support than the OpenWRT derivative “SDK”. (It should be noted that the odds are good, since I knew, at one point, the people doing those CodeAurora repos, as I worked for QuIC at one point in time.)

sfx2000 · 2019-03-28T21:19:13.347Z

glucknet:

Having said all of that, you can use mainline openwrt and with some tricks (irqbalance, assigning cores), you can reach pretty respectable performance numbers with the open source drivers.

QC-Atheros can be frustrating at times - on one hand, we have the old-school AR93XX, which is incredibly open, even to the WiFi driver, which QC-Atheros publicly supported an Open Source driver for.

Then we get the IPQ40xx/IPQ80xx - which is exactly the opposite - yes, there are community drivers in OpenWRT 18.06, but they’re no where near the capability of the closed source…

I agree - would be great if QCA contributed directly into OpenWRT, rather than fork - they don’t need to add all the “special sauce”, but getting a good ath10k Wave 2 driver would go a long way towards improving the relationship with the FOSS community.

madscientist_42 · 2019-03-29T03:13:47.820Z

Yes, it very much would.