Flint 2 (GL-MT6000 ) - bug reports - collective thread

FTP is dead und pretty old.
Go SFTP instead.

There are many scressnshots and looks like you are using OpenWrt.
I’m not sure what did you try to report.
What is the problem?

hi which firmware do you recommend? I noticed a big bug on 4.5.6.
do you recommend putting 4.5.7 or going directly to 4.6.0?
Thank you

They all have bugs. So the recommendation is:

  1. Wait until a truly stable one is available
  2. Go to 4.6.0 and try to stay as up-to-date as possible.

ok I update 4.6 released yesterday.
what version of openwrt 21 or 23 is it based on??

Ftp dead? WTF.
A lot of cams, IoT uses ftp.

Just because many crap applications still use it, it’s not good tho.

FTP is unsafe and shouldn’t be considered as a standard service anymore. At least if you don’t encrypt it. But encryption will need certificate management, and then the whole thing gets more “professional” than home users would like it.

If you need FTP really bad, install it. It’s not that complicated.

But it shouldn’t be integrated by default, my 2 cents here.

Don’t worry. I’m selling my 4 gl.inet router and replacing with asus. Regards.

That option is not there, I can’t change the Country Code so the maximum TX power is 20dBm

No release notes for the 4.60 snapshot, so what is different between the 4.60 snapshot and the latest 4.5.7 beta?

I guess this is also the reason why the maximum TX power is 20dBm, LuCI doesn’t show the option for 30dBm anymore. Even though I think it wasn’t really transmitting at 30dBm

1 Like

Not really, they said 4.6+
Not 4.6 :slightly_smiling_face:
I realized SMB was better for my use case than FTP and so far I don’t regret using it, I used FTP for some IP cams in the past but it is too insecure and old

1 Like

Snapshots don’t contain any changelogs because they are automatically generated.

Can any admin explain to me how the snapshot can be working in fullconenat and in the beta it stops working? If so, the beta was supposed to be more stable?
Didn’t anyone say anything about this?

2 Likes

@alex_zheng can you please provide some changelogs for the new beta firmware?

@admon Btw, Openwrt has snapshot changelogs

Building is automatic, but not the programming

https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog

I don’t understand why people are so keen on uploading changelogs and new versions here at the moment. Just let the developers do their job.
All these questions take up resources that the developers normally need for programming.

Yes, troubleshooting takes time. Yes, it’s not ideal that Flint 2 sometimes has significant bugs - but until a “stable” version is released, all the asking is pointless.

1 Like

It’s useless this service you’re doing saying this shit, man look at the name of the topic created… flint-2-gl-mt6000-bug-reports-collective-thread
If it’s not here to report bugs, where will it be? In your email? Will I send a letter to your house? It’s very ignorant of you to say that.

Reporting bugs while talking about snapshots is useless.


And apart from that: How people report bugs is an important component. “Doesn’t work” is not helpful.

Most people following this thread don’t have much idea how to report a bug correctly. That’s not a bad thing either! But then you don’t have to test the latest versions either …

1 Like

They compiled the beta with the old fullconenat settings that didn’t work in the pppoe connection, for it to work you have to copy the settings from the snapshot version until they compile it with the new and correct settings.

Below is the functional fullconenat in pppoe connections.

path /etc/init.d/fullconenat

#!/bin/sh /etc/rc.common

START=99

set_rules() {
    iptables -t nat -I POSTROUTING -o $1 -j FULLCONENAT 2>/dev/null
    iptables -t nat -I PREROUTING -i $1 -j FULLCONENAT 2>/dev/null
}

clear_rules() {
    local ifaces=$(iptables -t nat -nvL POSTROUTING|grep FULLCONENAT|awk -F' ' '{print $7}')
    for item in $ifaces; of
        iptables -t nat -D POSTROUTING -o $item -j FULLCONENAT 2>/dev/null
        iptables -t nat -D PREROUTING -i $item -j FULLCONENAT 2>/dev/null
    done
}

find_wan_gw()
{
    local wan_list=$(ubus list|grep interface.|grep -v -E 'lan|loopback|4|6')
    for item in $wan_list; of
        local ubus_data=$(ubus call $item status)
        local up="$(echo $ubus_data|jsonfilter -e '@.up')"
        [ "$up" = "true" ] || continues

        local gw="$(echo $ubus_data|jsonfilter -e '@.l3_device')"
        [ -n "$gw" ] && set_rules $gw
    done
}

stop() {
    clear_rules
}

start() {
    if [ "$(uci get fullconenat.global.enable)" = "1" ]; then
        local ifaces=$(iptables -t nat -nvL POSTROUTING|grep FULLCONENAT|awk -F' ' '{print $7}')
        [ -z "$ifaces" ] && find_wan_gw
    fi
}

better?

I don’t think so, a snapshot is experimental to be tested, without the aquired feedback things will remain present.

This on the latter has potentional bringing breaking bugs into a ‘release’, and then brick.

However since release also contains bugs similar to the snapshots and the assumption got more or less created releases are always experimental, that means the workflow isn’t working as expected and the process is unresponsive, you need to implement a strong bond and set of abstract rules, how commits are formated, to a person who manages PSAs, and when a firmware is bad it should stay but there needs to be a system which marks the build bad and inform people, so people can always read why it failed, instead of seeing nothing happened and there is a new snapshot with no version bump.

And then there is a issue i have with firmwares being removed, and reintroduced with the same version but different checksum, for a user there is no proper safe guard to see what is changed.

And then i understand why people want notes, you don’t want to run a snapshot changing the partition sizes or causing it to overlap and that can brick u-boot if such bug gets introduced, ive been looking to the brume2 aswell since i see a increase in partition issues on the forum.

If i can vote i would vote for a automation which can put the commit feed when creating a new release/tag on private github or gitlab and place that as text in the notes, and not the urls to the commits.

And a vote to aquire some person at GL who manages PSA/affairs and the rules of maintaining the project, i don’t want to sound too nosy like im a know it all, but without it everyone works through each other, and with no proper rules/ guidance you create a chaotic recipe.

Maybe at this point there should only be a ‘beta’ or pre candidate for the MTK version, but that is just my opinion, i definitely would have done that :+1: :wink:

3 Likes