new mt7628 mt7612 mt7615 mt7915 wireless driver support

[DragonBluep]

I have collected some new versions of wireless drivers to help with this project. Although it seems like there's always some way to get the latest driver. Thank you for your effort. It's a really cool project. link

MT7622_7615_SoftAP_5.0.5.4_57a62f_20200814.tar.xz mt7915_20200814-bb4577.tar.xz （v7.3.0.1 already include） MT76x2E_MT7620_LinuxAP_V3.0.4.0_P3_DPA_20180201.bz2 (seems not official) MT76x2E_MT7620_LinuxAP_V3.0.5.0_DPA_20160121.tar.bz2 (already include) MT7628_LinuxAP_V4.1.1.0_DPA_20190925.tar.bz2

add driver pack reported by lukasz1992, thx, MT7603e_LinuxAP_V4.1.2.1_20190503-ac1d3fab.tar.bz2 MT7663_LinuxAP_6.0.3.0_20200106-775e6a.tar.bz2

[lukasz1992]

https://dlink-gpl.s3.amazonaws.com/GPL2000220/DIR2150_A1_V1.01B04_GPLCode_20201211.tar.gz contains also newer MT7603 and MT7663 drivers than publicly available

MT7603e_LinuxAP_V4.1.2.1_20190503-ac1d3fab.tar.bz2 MT7663_LinuxAP_6.0.3.0_20200106-775e6a.tar.bz2

[MeIsReallyBa]

https://www.downloads.netgear.com/files/GPL/WAX206_V1.0.3.0_Source.rar

mt7615 5.1.0.0

[i3roly]

ping @hanwckf @yonsm please update to new driver so my patching is easier.

[i3roly]

new driver is incredibly fast and much better. WOW.

i still have to figure out why wlan mac addresses are not being read correctly, and why client information is showing up partially wrong!

lots of changes to the code it seems

[i3roly]

getting better but the changes for the "new ui" are making ioctl for connected clients a nightmare

there are some notable changes to how RTMPIoctlGetMacTableStaInfo reports connected clients, where the virtual interfaces (ra1/ra2/rai1/rai2/rax1/rax2 etc) are now excluded from the "main interface". the fix to report the right number of clients is straightforward just comment out the following:

                //if (pEntry->wdev != NULL) {
                        /* As per new GUI design ifname with index as ra0/ra1/rai0/rai1/... (may not work with older GUI)*/
                        //if (!strcmp(wrq->ifr_ifrn.ifrn_name, pEntry->wdev->if_dev->name))
                        //      need_send = TRUE;
                        //else
                        //      need_send = FALSE;
                //}

however, as should be clear from the picture, i have yet to solve the following issues:

1. counting the packets from these virtual interfaces into the main interface.
2. reporting the correct connected time for any or all clients not connected to the 'main interface', but one of its virtual interfaces.
3. reporting the correct mac addresses for the connected clients.

it's weird because the clients connected to the 5G "main interface" have the right statistics, but the rest do not.

we need you @hanwckf @yonsm!! apply your patches to make our lives easy!

[i3roly]

ping @Paldier

i think new 5.1.0.0 driver is broken. something is wrong with mac entry storage.

everything is fine on 5.0.5.1. i know you're very busy with other builds, but could you ask your people about the changes?

even if MTK/RALINK changed interface association of VIFs in main IF, it does not explain the corrupted HTTTRANSMIT struct.

i have compared embedded/common/cmm_info.c between 5.0.5.1 and 5.1.0.0 in great detail, and it seems to me there is some issue with how clients are being stored in 5.1.0.0, as the last client is reported to be fictitious with an invalid HT mode.

[paldier]

i think it is same as 7915, so you should update your userspace struct

[i3roly]

I did man.

It's something *else.

oid.h is the same for 5.0.5.1 and 5.1.0.0:

https://github.com/hanwckf/rt-n56u/blob/23387b278a7cf728748af606760758f5d59d1451/trunk/proprietary/rt_wifi/rtpci/5.0.5.1/mt7615/embedded/include/oid.h#L1100-L1125

and

https://github.com/SWRT-dev/rtax53u/blob/139a32fea902da013b22f01af7280fd37e241a74/release/src-ra-openwrt-4210/linux/linux-4.4.198/drivers/net/wireless/mediatek/mt7615/5.1.0.0/mt_wifi/embedded/include/oid.h#L1126-L1151

@paldier

i am going to check more

[i3roly]

@paldier after further evaluation, there is something most definitely wrong with how MacTab.Entry[idx].Content is being stored/addressed in 5.1.0.0 in comparison to 5.0.5.1.

i am not able to say which file, but i can assure you that the user space structure that you're referencing is not the problem here.

the only way to substantiate the 'working normally' claim is if people are using RTPRIV_IOCTL_GET_MAC_TABLE in the RA IOCTL, instead of RTPRIV_IOCTL_GET_MAC_STRUCT that i am using.

GET_MAC_TABLE seems to be used in the ralink httpd:

https://github.com/SWRT-dev/rtax53u/blob/83c197bde9dea24ad3fad0e320f9386d592cfc74/release/src/router/httpd/sysdeps/web-ralink.c#L1221-L1229

MAC_TABLE_ENTRY_STRUCT Is a superior way to handle all clients, as it does not require distinction of the radio, which can be abstracted one level lower, removing the need to create separate functions to handle the 2g and 5g radio.

i assure you there is some change made to MacTab's entries that corrupt it. as you can see in my previous screenshots, the first client's information is reported correctly. however, every client afterwards is not. sometimes a second client will display information correctly, but this is not consistent behaviour.

something is wrong L:(

[i3roly]

@paldier do you think your updates to cr4 and rom patch may help tthis issue? no, right? i don't even know if mac table is managed internally by andes, and also by driver that talks to andes

[paldier]

I‘m working on it

[i3roly]

thanks for the information!

[i3roly]

@paldier i know you said you're working on it, and i'm using 5.0.5.1 happily, but i'm somewhat distraught the driver wasn't checked prior to release as "5.1.0.0" (meaning 'big update').

seems much better performance-wise, but what is the point of that performance if we cannot collect statistics properly.

only developers are going to know where this bug is. something is causing MacTab.Contents[] to get overwritten to null for every client after the first one.

we are probably better off waiting for 5.1.x.x.

[paldier]

typedef struct _RT_802_11_MAC_ENTRY {
    unsigned char ApIdx;
    unsigned char Addr[MAC_ADDR_LEN];
    unsigned char Aid;
    unsigned char Psm;      /* 0:PWR_ACTIVE, 1:PWR_SAVE */
    unsigned char MimoPs;       /* 0:MMPS_STATIC, 1:MMPS_DYNAMIC, 3:MMPS_Enabled */
    signed char AvgRssi0;
    signed char AvgRssi1;
    signed char AvgRssi2;
    unsigned int ConnectedTime;
    HTTRANSMIT_SETTING TxRate;
    unsigned int LastRxRate;
    /*
        sync with WEB UI's structure for ioctl usage.
    */
    unsigned short StreamSnr[3];                /* BF SNR from RXWI. Units=0.25 dB. 22 dB offset removed */
    unsigned short SoundingRespSnr[3];          /* SNR from Sounding Response. Units=0.25 dB. 22 dB offset removed */
    /*  SHORT TxPER;    */                  /* TX PER over the last second. Percent */
    /*  SHORT reserved;*/
} RT_802_11_MAC_ENTRY, *PRT_802_11_MAC_ENTRY;

typedef struct _RT_802_11_MAC_TABLE {
    unsigned long Num;
    RT_802_11_MAC_ENTRY Entry[MAX_NUMBER_OF_MAC];
} RT_802_11_MAC_TABLE, *PRT_802_11_MAC_TABLE;

typedef struct _RT_802_11_MAC_ENTRY {
    UCHAR ApIdx;
    UCHAR Addr[MAC_ADDR_LEN];
    UCHAR Aid;
    UCHAR Psm;      /* 0:PWR_ACTIVE, 1:PWR_SAVE */
    UCHAR MimoPs;       /* 0:MMPS_STATIC, 1:MMPS_DYNAMIC, 3:MMPS_Enabled */
    CHAR AvgRssi0;
    CHAR AvgRssi1;
    CHAR AvgRssi2;
    CHAR AvgRssi3;
    UINT32 ConnectedTime;
    HTTRANSMIT_SETTING TxRate;
#ifdef CUSTOMER_DCC_FEATURE
    UINT32 AvgSnr;
#endif /* CUSTOMER_DCC_FEATURE */
    UINT32 LastRxRate;
    /*
        sync with WEB UI's structure for ioctl usage.
    */
#ifndef CUSTOMER_DCC_FEATURE
    SHORT StreamSnr[3];             /* BF SNR from RXWI. Units=0.25 dB. 22 dB offset removed */
    SHORT SoundingRespSnr[3];           /* SNR from Sounding Response. Units=0.25 dB. 22 dB offset removed */
    /*  SHORT TxPER;    */                  /* TX PER over the last second. Percent */
    /*  SHORT reserved;*/
#endif /* !CUSTOMER_DCC_FEATURE */
} RT_802_11_MAC_ENTRY, *PRT_802_11_MAC_ENTRY;

typedef struct _RT_802_11_MAC_TABLE {
    ULONG Num;
    RT_802_11_MAC_ENTRY Entry[MAX_NUMBER_OF_MAC];
} RT_802_11_MAC_TABLE, *PRT_802_11_MAC_TABLE;

It's different, you should update your userspace struct and httpd code.

[i3roly]

nah man, i made the changes to 5.0.5.1 so it's the following:

typedef struct _RT_802_11_MAC_ENTRY {
        UCHAR ApIdx;
        UCHAR Addr[MAC_ADDR_LEN];
        UCHAR Aid;
        UCHAR Psm;              /* 0:PWR_ACTIVE, 1:PWR_SAVE */
        UCHAR MimoPs;           /* 0:MMPS_STATIC, 1:MMPS_DYNAMIC, 3:MMPS_Enabled */
        CHAR AvgRssi0;
        CHAR AvgRssi1;
        CHAR AvgRssi2;
#ifdef CUSTOMER_DCC_FEATURE
        CHAR AvgRssi3;
#endif
        UINT32 ConnectedTime;
        HTTRANSMIT_SETTING TxRate;
#ifdef CUSTOMER_DCC_FEATURE
        UINT32 AvgSnr;
#endif /* CUSTOMER_DCC_FEATURE */
        UINT32 LastRxRate;
        /*
                sync with WEB UI's structure for ioctl usage.
        */
#if 0
        SHORT StreamSnr[3];                             /* BF SNR from RXWI. Units=0.25 dB. 22 dB offset removed */
        SHORT SoundingRespSnr[3];                       /* SNR from Sounding Response. Units=0.25 dB. 22 dB offset removed */
        /*      SHORT TxPER;    */                                      /* TX PER over the last second. Percent */
        /*      SHORT reserved;*/
#endif /* !CUSTOMER_DCC_FEATURE */
} RT_802_11_MAC_ENTRY, *PRT_802_11_MAC_ENTRY;

and my 5.1.0.0 is:

typedef struct _RT_802_11_MAC_ENTRY {
        UCHAR ApIdx;
        UCHAR Addr[MAC_ADDR_LEN];
        UCHAR Aid;
        UCHAR Psm;              /* 0:PWR_ACTIVE, 1:PWR_SAVE */
        UCHAR MimoPs;           /* 0:MMPS_STATIC, 1:MMPS_DYNAMIC, 3:MMPS_Enabled */
        CHAR AvgRssi0;
        CHAR AvgRssi1;
        CHAR AvgRssi2;
#ifdef CUSTOMER_DCC_FEATURE
        CHAR AvgRssi3;
#endif
        UINT32 ConnectedTime;
        HTTRANSMIT_SETTING TxRate;
#ifdef CUSTOMER_DCC_FEATURE
        UINT32 AvgSnr;
#endif /* CUSTOMER_DCC_FEATURE */
        UINT32 LastRxRate;
        /*
                sync with WEB UI's structure for ioctl usage.
        */
#ifndef CUSTOMER_DCC_FEATURE
        SHORT StreamSnr[3];                             /* BF SNR from RXWI. Units=0.25 dB. 22 dB offset removed */
        SHORT SoundingRespSnr[3];                       /* SNR from Sounding Response. Units=0.25 dB. 22 dB offset removed */
        /*      SHORT TxPER;    */                                      /* TX PER over the last second. Percent */
        /*      SHORT reserved;*/
#endif /* !CUSTOMER_DCC_FEATURE */
} RT_802_11_MAC_ENTRY, *PRT_802_11_MAC_ENTRY;

i don't enable CUSTOMER_DCC_FEATURE, so the structs are the same....

[i3roly]

oh shit, it says ifNdef cusxtomer_dcc_Feature

fuck. let me try this again :p

[i3roly]

my-hi-hi-hi-hi-hi chaaaineeese brotha @paldier

hahahaha nice job 👊🤘🤘🤘🤘👊

[i3roly]

@paldier

[lukasz1992]

https://www.downloads.netgear.com/files/GPL/WAX206_V1.0.3.0_Source.rar

mt7615 5.1.0.0

this archive contains also newer version of mt7915 driver (7.4.0.0), filename: mt7915_20201106-34067b.tar

[annick96]

help with RT1800 GL source

i build with Mint 18 or 19

when i tag in enuconfig mt7915 MTK driver mt_wifi.ko error

[DragonBluep]

This repository is now archive only. I'll close this issue.

BTW, the mt76 open source driver is stable enough for most use cases recently. Let's look forward.

Thank you for your attention!

[i3roly]

i highly doubt this to be the case.

i remember looking into this earlier in the year, and nothing has changed. if you're referencing the ability to stay connected, maybe that has 9improved, but i know performance has not.

it's just a dirty secret that the mt76 driver is not a performer. its strength is GPL. that's all. it's always been that way. most people that use openwrt are a part of the project, and outsiders who try it don't ever hang around long enough to complain about it.

[rodsmar]

i highly doubt this to be the case.

i remember looking into this earlier in the year, and nothing has changed. if you're referencing the ability to stay connected, maybe that has 9improved, but i know performance has not.

it's just a dirty secret that the mt76 driver is not a performer. its strength is GPL. that's all. it's always been that way. most people that use openwrt are a part of the project, and outsiders who try it don't ever hang around long enough to complain about it.

in my opinion, the mt76 driver is very stable and solid on the newer devices (mt7615+), incorporating features such as TX/RX disaggregation and Wireless Ethernet Dispatch. It should also be noted that some MediaTek engineers are working on the latest chips. Older chips, such as mt7603 and mt7612 should only receive occasional improvements, but without many advances.

[i3roly]

Hahahaha okay man.

Mt76 rulz.

Sent from my BlackBerry 10 smartphone. From: Rodrigo B. de Sousa Martins Sent: Monday, 9 October 2023 6:18 PM To: hanwckf/rt-n56u Reply To: hanwckf/rt-n56u Cc: gagan sidhu; Comment Subject: Re: [hanwckf/rt-n56u] new mt7628 mt7612 mt7615 mt7915 wireless driver support (Issue #738)

i highly doubt this to be the case.

i remember looking into this earlier in the year, and nothing has changed. if you're referencing the ability to stay connected, maybe that has 9improved, but i know performance has not.

it's just a dirty secret that the mt76 driver is not a performer. its strength is GPL. that's all. it's always been that way. most people that use openwrt are a part of the project, and outsiders who try it don't ever hang around long enough to complain about it.

in my opinion, the mt76 driver is very stable and solid on the newer devices (mt7615+), incorporating features such as TX/RX disaggregation and Wireless Ethernet Dispatch. It should also be noted that some MediaTek engineers are working on the latest chips. Older chips, such as mt7603 and mt7612 should only receive occasional improvements, but without many advances.

— Reply to this email directly, view it on GitHubhttps://github.com/hanwckf/rt-n56u/issues/738#issuecomment-1753382143, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEGZIV5D5X5JIBQF6I53X6QWWVAVCNFSM5KBR2M7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGMZTQMRRGQZQ. You are receiving this because you commented.Message ID: @.***>