Re: mt76x0 bug report
On Wed, Sep 19, 2018 at 7:15 AM Stanislaw Gruszka wrote: > > On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote: > > On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka > > wrote: > > > > > > On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > > > > Sorry to bump the one thing that we both agreed was low priority but > > > > > > > > So was testing all of my dongles that use the driver you are working > > > > on, and running them through my connect scripts. I moved the AP to > > > > maybe <5ft from the clients and something wierd happened. The t1u > > > > tried to connect to one of the 2.4GHz only networks. It failed, but > > > > it actually got enough scan data back to attempt authentication with a > > > > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > > > > lying and your parsing of it is correct. Something obviously makes > > > > this a 5GHz only device, as the connection failed and most of the time > > > > nothing at all is seen on 2.4GHz, but clearly it's some filter or > > > > antenna or some other mechanism which makes it 5GHz only. So probably > > > > hardware lying to you is now even lower on your list since this safely > > > > rules out the driver parsing the eeprom incorrectly. > > > > > > First of all would be good to check if problem is not already solved, > > > latest version of the driver can be found here: > > > https://github.com/nbd168/wireless > > > > Booting that kernel gets me instant to near instant kernel panics, so > > I am unable to test much. > > This has to be fixed as well, can you provide kernel messages ? Working on it, please stand by. > > > > Second, is there vendor driver available for this particular device? > > > Perhaps there are some tweeks needed that are not provided by generic > > > driver. > > > > No clue, haven't even tried to look. This hardware was all sitting on > > a shelf till it looked like a real driver was being merged into the > > kernel so um, thanks :-) > > Why do you think device is 5GHz only? This is very unusual. I know > only single-band 2.4GHz or dual-band 2.4GHz & 5GHz devices. https://www.tp-link.com/us/faq-2253.html "Note: Before you do these troubleshooting, please kindly check whether the adapter you use is Archer T1U. For this model, it only supports 5GHz network. So if the router you use only provides 2.4GHz network, ‘you can’t find the 5GHz network any more." Yup, I agree, it's wierd. -Zero > > Regards > Stanislaw
Re: mt76x0 bug report
On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote: > On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka wrote: > > > > On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > > > Sorry to bump the one thing that we both agreed was low priority but > > > > > > So was testing all of my dongles that use the driver you are working > > > on, and running them through my connect scripts. I moved the AP to > > > maybe <5ft from the clients and something wierd happened. The t1u > > > tried to connect to one of the 2.4GHz only networks. It failed, but > > > it actually got enough scan data back to attempt authentication with a > > > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > > > lying and your parsing of it is correct. Something obviously makes > > > this a 5GHz only device, as the connection failed and most of the time > > > nothing at all is seen on 2.4GHz, but clearly it's some filter or > > > antenna or some other mechanism which makes it 5GHz only. So probably > > > hardware lying to you is now even lower on your list since this safely > > > rules out the driver parsing the eeprom incorrectly. > > > > First of all would be good to check if problem is not already solved, > > latest version of the driver can be found here: > > https://github.com/nbd168/wireless > > Booting that kernel gets me instant to near instant kernel panics, so > I am unable to test much. This has to be fixed as well, can you provide kernel messages ? > > Second, is there vendor driver available for this particular device? > > Perhaps there are some tweeks needed that are not provided by generic > > driver. > > No clue, haven't even tried to look. This hardware was all sitting on > a shelf till it looked like a real driver was being merged into the > kernel so um, thanks :-) Why do you think device is 5GHz only? This is very unusual. I know only single-band 2.4GHz or dual-band 2.4GHz & 5GHz devices. Regards Stanislaw
Re: mt76x0 bug report
On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka wrote: > > On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > > Sorry to bump the one thing that we both agreed was low priority but > > > > So was testing all of my dongles that use the driver you are working > > on, and running them through my connect scripts. I moved the AP to > > maybe <5ft from the clients and something wierd happened. The t1u > > tried to connect to one of the 2.4GHz only networks. It failed, but > > it actually got enough scan data back to attempt authentication with a > > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > > lying and your parsing of it is correct. Something obviously makes > > this a 5GHz only device, as the connection failed and most of the time > > nothing at all is seen on 2.4GHz, but clearly it's some filter or > > antenna or some other mechanism which makes it 5GHz only. So probably > > hardware lying to you is now even lower on your list since this safely > > rules out the driver parsing the eeprom incorrectly. > > First of all would be good to check if problem is not already solved, > latest version of the driver can be found here: > https://github.com/nbd168/wireless Booting that kernel gets me instant to near instant kernel panics, so I am unable to test much. > > Second, is there vendor driver available for this particular device? > Perhaps there are some tweeks needed that are not provided by generic > driver. No clue, haven't even tried to look. This hardware was all sitting on a shelf till it looked like a real driver was being merged into the kernel so um, thanks :-) -Zero > > Thanks > Stanislaw
Re: mt76x0 bug report
On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > Sorry to bump the one thing that we both agreed was low priority but > > So was testing all of my dongles that use the driver you are working > on, and running them through my connect scripts. I moved the AP to > maybe <5ft from the clients and something wierd happened. The t1u > tried to connect to one of the 2.4GHz only networks. It failed, but > it actually got enough scan data back to attempt authentication with a > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > lying and your parsing of it is correct. Something obviously makes > this a 5GHz only device, as the connection failed and most of the time > nothing at all is seen on 2.4GHz, but clearly it's some filter or > antenna or some other mechanism which makes it 5GHz only. So probably > hardware lying to you is now even lower on your list since this safely > rules out the driver parsing the eeprom incorrectly. First of all would be good to check if problem is not already solved, latest version of the driver can be found here: https://github.com/nbd168/wireless Second, is there vendor driver available for this particular device? Perhaps there are some tweeks needed that are not provided by generic driver. Thanks Stanislaw
Re: mt76x0 bug report
On Fri, Sep 14, 2018 at 11:51 AM Sid Hayn wrote: > > On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi > wrote: > > > > > > > > *bump* > > > > > > Been a few days, just a reminder that your monitor mode patch fixed > > > all channels below 144 but something appears incorrect in regdomain > > > handling as I cannot get channels 144 or higher working (my main AP > > > being on channel 149. Again, this works on mt76x2u but not on mt76x0. > > > The patch I tested doesn't appear to have landed in wireless-testing > > > yet, so if you haven't, please do push that up. > > > > I have already sent the patch to linux-wireless ml > > https://patchwork.kernel.org/patch/10592597/ > > Excellent, thank you. Is someone working on the channel/regdomain > issue as well? > > > > > > > > Secondarily, ethtool still doesn't report firmware version and that > > > would be a very helpful thing to have before 4.19 hits. > > > > > > > +Davide Caratti > > Thanks, saw his message and will watch for it to test. > > > > > Additionally, with much less severity, t1u still thinks it is dual > > > band and I'm happy to run any command, test any patch, etc. I > > > honestly don't care about this at all short term, but it does slow the > > > hardware down tuning to a bunch of channels which it cannot access so > > > long term it should probably be fixed in some way. > > > > > > > I am busy with other mt76 activities at the moment, I will look into > > it as soon as I have time > > Listed third and we seem to agree this is a "as time allows" task. Sorry to bump the one thing that we both agreed was low priority but So was testing all of my dongles that use the driver you are working on, and running them through my connect scripts. I moved the AP to maybe <5ft from the clients and something wierd happened. The t1u tried to connect to one of the 2.4GHz only networks. It failed, but it actually got enough scan data back to attempt authentication with a valid 2.4GHz only bssid. Which means in short, that the eeprom isn't lying and your parsing of it is correct. Something obviously makes this a 5GHz only device, as the connection failed and most of the time nothing at all is seen on 2.4GHz, but clearly it's some filter or antenna or some other mechanism which makes it 5GHz only. So probably hardware lying to you is now even lower on your list since this safely rules out the driver parsing the eeprom incorrectly. Thanks, Zero > > Thanks for the prompt response. > > -Zero > > > > Regards, > > Lorenzo > > > > > Thanks again for all your hard work, watching the mailing list it is > > > obvious how much effort is going into this right now. > > > > > > -Zero > > > On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > > > > > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > Actions like that have caused great problems in the past, as the > > > > > > kernel won't allow channel control of a monitor interface at all > > > > > > when > > > > > > there is a managed interface on the same phy (afaik). > > > > > > > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > > > > > > > Test 1: "iwconfig t2u mode monitor" > > > > > > Sees nothing on any channel, no packets reported > > > > > > > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type > > > > > > monitor" > > > > > > Sees nothing on any channel, no packets reported. > > > > > > Despite having a monitor and managed interface on the same phy, > > > > > > iwconfig is reporting that the channel is changing as requested. So > > > > > > perhaps my above "afaik" comment is partially outdated. > > > > > > > > > > > > For both tests the interface was not used to connect to any ap prior > > > > > > to or during testing. > > > > > > > > > > > > > > > > Could you please try following patch? > > > > > > > > Excellent! This seems to work for all channels up to 140, however, > > > > not 144 or above. "iw list" shows these are supported but I cannot > > > > set them in monitor mode: > > > > > > > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > > > > * 5745 MHz [149] (22.0 dBm) (no IR) > > > > * 5765 MHz [153] (22.0 dBm) (no IR) > > > > * 5785 MHz [157] (22.0 dBm) (no IR) > > > > * 5805 MHz [161] (22.0 dBm) (no IR) > > > > * 5825 MHz [165] (22.0 dBm) (no IR) > > > > > > > > remote2 ~ # iw dev t2uhmon set channel 140 > > > > remote2 ~ # iw dev t2uhmon set channel 144 > > > > command failed: Invalid argument (-22) > > > > > > > > Thanks, > > > > Zero > > > > > > > > > Regards, > > > > > > > > > > Lorenzo > > > > > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > > > > > > > /* Vendor driver don't do it */ > > > > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > > > > + mt76x0_vco_cal(dev,
Re: mt76x0 bug report
On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi wrote: > > > > > *bump* > > > > Been a few days, just a reminder that your monitor mode patch fixed > > all channels below 144 but something appears incorrect in regdomain > > handling as I cannot get channels 144 or higher working (my main AP > > being on channel 149. Again, this works on mt76x2u but not on mt76x0. > > The patch I tested doesn't appear to have landed in wireless-testing > > yet, so if you haven't, please do push that up. > > I have already sent the patch to linux-wireless ml > https://patchwork.kernel.org/patch/10592597/ Excellent, thank you. Is someone working on the channel/regdomain issue as well? > > > > > Secondarily, ethtool still doesn't report firmware version and that > > would be a very helpful thing to have before 4.19 hits. > > > > +Davide Caratti Thanks, saw his message and will watch for it to test. > > > Additionally, with much less severity, t1u still thinks it is dual > > band and I'm happy to run any command, test any patch, etc. I > > honestly don't care about this at all short term, but it does slow the > > hardware down tuning to a bunch of channels which it cannot access so > > long term it should probably be fixed in some way. > > > > I am busy with other mt76 activities at the moment, I will look into > it as soon as I have time Listed third and we seem to agree this is a "as time allows" task. Thanks for the prompt response. -Zero > > Regards, > Lorenzo > > > Thanks again for all your hard work, watching the mailing list it is > > obvious how much effort is going into this right now. > > > > -Zero > > On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > > > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > Actions like that have caused great problems in the past, as the > > > > > kernel won't allow channel control of a monitor interface at all when > > > > > there is a managed interface on the same phy (afaik). > > > > > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > > > > > Test 1: "iwconfig t2u mode monitor" > > > > > Sees nothing on any channel, no packets reported > > > > > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type > > > > > monitor" > > > > > Sees nothing on any channel, no packets reported. > > > > > Despite having a monitor and managed interface on the same phy, > > > > > iwconfig is reporting that the channel is changing as requested. So > > > > > perhaps my above "afaik" comment is partially outdated. > > > > > > > > > > For both tests the interface was not used to connect to any ap prior > > > > > to or during testing. > > > > > > > > > > > > > Could you please try following patch? > > > > > > Excellent! This seems to work for all channels up to 140, however, > > > not 144 or above. "iw list" shows these are supported but I cannot > > > set them in monitor mode: > > > > > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > > > * 5745 MHz [149] (22.0 dBm) (no IR) > > > * 5765 MHz [153] (22.0 dBm) (no IR) > > > * 5785 MHz [157] (22.0 dBm) (no IR) > > > * 5805 MHz [161] (22.0 dBm) (no IR) > > > * 5825 MHz [165] (22.0 dBm) (no IR) > > > > > > remote2 ~ # iw dev t2uhmon set channel 140 > > > remote2 ~ # iw dev t2uhmon set channel 144 > > > command failed: Invalid argument (-22) > > > > > > Thanks, > > > Zero > > > > > > > Regards, > > > > > > > > Lorenzo > > > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > > > > > /* Vendor driver don't do it */ > > > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > > > + mt76x0_vco_cal(dev, channel); > > > > > > > > if (scan) > > > > - mt76x0_vco_cal(dev, channel); > > > > - > > > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > > > > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
> > *bump* > > Been a few days, just a reminder that your monitor mode patch fixed > all channels below 144 but something appears incorrect in regdomain > handling as I cannot get channels 144 or higher working (my main AP > being on channel 149. Again, this works on mt76x2u but not on mt76x0. > The patch I tested doesn't appear to have landed in wireless-testing > yet, so if you haven't, please do push that up. I have already sent the patch to linux-wireless ml https://patchwork.kernel.org/patch/10592597/ > > Secondarily, ethtool still doesn't report firmware version and that > would be a very helpful thing to have before 4.19 hits. > +Davide Caratti > Additionally, with much less severity, t1u still thinks it is dual > band and I'm happy to run any command, test any patch, etc. I > honestly don't care about this at all short term, but it does slow the > hardware down tuning to a bunch of channels which it cannot access so > long term it should probably be fixed in some way. > I am busy with other mt76 activities at the moment, I will look into it as soon as I have time Regards, Lorenzo > Thanks again for all your hard work, watching the mailing list it is > obvious how much effort is going into this right now. > > -Zero > On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > > wrote: > > > > > > > Actions like that have caused great problems in the past, as the > > > > kernel won't allow channel control of a monitor interface at all when > > > > there is a managed interface on the same phy (afaik). > > > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > > > Test 1: "iwconfig t2u mode monitor" > > > > Sees nothing on any channel, no packets reported > > > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type > > > > monitor" > > > > Sees nothing on any channel, no packets reported. > > > > Despite having a monitor and managed interface on the same phy, > > > > iwconfig is reporting that the channel is changing as requested. So > > > > perhaps my above "afaik" comment is partially outdated. > > > > > > > > For both tests the interface was not used to connect to any ap prior > > > > to or during testing. > > > > > > > > > > Could you please try following patch? > > > > Excellent! This seems to work for all channels up to 140, however, > > not 144 or above. "iw list" shows these are supported but I cannot > > set them in monitor mode: > > > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > > * 5745 MHz [149] (22.0 dBm) (no IR) > > * 5765 MHz [153] (22.0 dBm) (no IR) > > * 5785 MHz [157] (22.0 dBm) (no IR) > > * 5805 MHz [161] (22.0 dBm) (no IR) > > * 5825 MHz [165] (22.0 dBm) (no IR) > > > > remote2 ~ # iw dev t2uhmon set channel 140 > > remote2 ~ # iw dev t2uhmon set channel 144 > > command failed: Invalid argument (-22) > > > > Thanks, > > Zero > > > > > Regards, > > > > > > Lorenzo > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > > > /* Vendor driver don't do it */ > > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > > + mt76x0_vco_cal(dev, channel); > > > > > > if (scan) > > > - mt76x0_vco_cal(dev, channel); > > > - > > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
On Fri, 2018-09-14 at 11:32 -0400, Sid Hayn wrote: > Secondarily, ethtool still doesn't report firmware version and that > would be a very helpful thing to have before 4.19 hits. hello, I just tested a draft patch for mt76 addressing the missing FW version in ethtool, will send it to the ML in the next days. regards, -- davide
Re: mt76x0 bug report
*bump* Been a few days, just a reminder that your monitor mode patch fixed all channels below 144 but something appears incorrect in regdomain handling as I cannot get channels 144 or higher working (my main AP being on channel 149. Again, this works on mt76x2u but not on mt76x0. The patch I tested doesn't appear to have landed in wireless-testing yet, so if you haven't, please do push that up. Secondarily, ethtool still doesn't report firmware version and that would be a very helpful thing to have before 4.19 hits. Additionally, with much less severity, t1u still thinks it is dual band and I'm happy to run any command, test any patch, etc. I honestly don't care about this at all short term, but it does slow the hardware down tuning to a bunch of channels which it cannot access so long term it should probably be fixed in some way. Thanks again for all your hard work, watching the mailing list it is obvious how much effort is going into this right now. -Zero On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > wrote: > > > > > Actions like that have caused great problems in the past, as the > > > kernel won't allow channel control of a monitor interface at all when > > > there is a managed interface on the same phy (afaik). > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > Test 1: "iwconfig t2u mode monitor" > > > Sees nothing on any channel, no packets reported > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > > > Sees nothing on any channel, no packets reported. > > > Despite having a monitor and managed interface on the same phy, > > > iwconfig is reporting that the channel is changing as requested. So > > > perhaps my above "afaik" comment is partially outdated. > > > > > > For both tests the interface was not used to connect to any ap prior > > > to or during testing. > > > > > > > Could you please try following patch? > > Excellent! This seems to work for all channels up to 140, however, > not 144 or above. "iw list" shows these are supported but I cannot > set them in monitor mode: > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > * 5745 MHz [149] (22.0 dBm) (no IR) > * 5765 MHz [153] (22.0 dBm) (no IR) > * 5785 MHz [157] (22.0 dBm) (no IR) > * 5805 MHz [161] (22.0 dBm) (no IR) > * 5825 MHz [165] (22.0 dBm) (no IR) > > remote2 ~ # iw dev t2uhmon set channel 140 > remote2 ~ # iw dev t2uhmon set channel 144 > command failed: Invalid argument (-22) > > Thanks, > Zero > > > Regards, > > > > Lorenzo > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > /* Vendor driver don't do it */ > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > + mt76x0_vco_cal(dev, channel); > > > > if (scan) > > - mt76x0_vco_cal(dev, channel); > > - > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi wrote: > > > Actions like that have caused great problems in the past, as the > > kernel won't allow channel control of a monitor interface at all when > > there is a managed interface on the same phy (afaik). > > > > But just for fun and codepath testing here are two test scenarios: > > > > Test 1: "iwconfig t2u mode monitor" > > Sees nothing on any channel, no packets reported > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > > Sees nothing on any channel, no packets reported. > > Despite having a monitor and managed interface on the same phy, > > iwconfig is reporting that the channel is changing as requested. So > > perhaps my above "afaik" comment is partially outdated. > > > > For both tests the interface was not used to connect to any ap prior > > to or during testing. > > > > Could you please try following patch? Excellent! This seems to work for all channels up to 140, however, not 144 or above. "iw list" shows these are supported but I cannot set them in monitor mode: * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) * 5745 MHz [149] (22.0 dBm) (no IR) * 5765 MHz [153] (22.0 dBm) (no IR) * 5785 MHz [157] (22.0 dBm) (no IR) * 5805 MHz [161] (22.0 dBm) (no IR) * 5825 MHz [165] (22.0 dBm) (no IR) remote2 ~ # iw dev t2uhmon set channel 140 remote2 ~ # iw dev t2uhmon set channel 144 command failed: Invalid argument (-22) Thanks, Zero > Regards, > > Lorenzo > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > /* Vendor driver don't do it */ > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > + mt76x0_vco_cal(dev, channel); > > if (scan) > - mt76x0_vco_cal(dev, channel); > - > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > mt76x0_phy_set_chan_pwr(dev, channel); > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
> Actions like that have caused great problems in the past, as the > kernel won't allow channel control of a monitor interface at all when > there is a managed interface on the same phy (afaik). > > But just for fun and codepath testing here are two test scenarios: > > Test 1: "iwconfig t2u mode monitor" > Sees nothing on any channel, no packets reported > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > Sees nothing on any channel, no packets reported. > Despite having a monitor and managed interface on the same phy, > iwconfig is reporting that the channel is changing as requested. So > perhaps my above "afaik" comment is partially outdated. > > For both tests the interface was not used to connect to any ap prior > to or during testing. > Could you please try following patch? Regards, Lorenzo --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, /* Vendor driver don't do it */ /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ + mt76x0_vco_cal(dev, channel); if (scan) - mt76x0_vco_cal(dev, channel); - - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); mt76x0_phy_set_chan_pwr(dev, channel); dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
> > > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka > > wrote: > > > > > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > > > > > First issue, is that it appears the mt76x0 devices don't work > > > > > > properly > > > > > > in monitor mode. Sometimes they seem to monitor one channel > > > > > > properly, > > > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > > > packets, etc. > > > > > > > > > > Could you elaborate a little bit please? how can you reproduce the > > > > > issue? > > > > > just add an interface in monitor mode and run a scan? > > > > > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > > > use iw to remove managed mode interface, run some tool such as kismet > > > > or airodump-ng or even wireshark. > > > I think I understood the monitor mode issue with mt76x0 driver. I will send you a patch tomorrow for testing Regards, Lorenzo
Re: mt76x0 bug report
> On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > > wrote: > > > > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > > packets, etc. > > > > > > > > Could you elaborate a little bit please? how can you reproduce the > > > > issue? > > > > just add an interface in monitor mode and run a scan? > > > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > > use iw to remove managed mode interface, run some tool such as kismet > > > or airodump-ng or even wireshark. > > > > But what exactly are the syptomps, I don't understand what you mean by > > "mt76x0 devices don't work properly in monitor mode" ? > > > > > > I guess it depends on eeprom values. Could you please enable debug > > > > messages a paste > > > > syslog output? > > > > > > I don't see a mediatek specific debug near the driver selection in > > > menuconfig, what debug messages do you want me to enable and how? > > > > You need to uncomment this line: > > > > # ccflags-y := -DDEBUG > > > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile > > I have done this change, rebooted, and plugged in the TP-Link t1u > dongle which is 5GHz only. This is dmesg: > [ 30.058587] usb 2-2: new high-speed USB device number 3 using xhci_hcd > [ 30.28] usb 2-2: New USB device found, idVendor=2357, > idProduct=0105, bcdDevice= 1.00 > [ 30.200010] usb 2-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 30.200012] usb 2-2: Product: WiFi > [ 30.200013] usb 2-2: Manufacturer: MediaTek > [ 30.200015] usb 2-2: SerialNumber: 1.0 > [ 30.332895] usb 2-2: reset high-speed USB device number 3 using xhci_hcd > [ 30.466124] mt76x0 2-2:1.0: ASIC revision: 7612 MAC revision: 76502000 > [ 30.467534] mt76x0 2-2:1.0: Firmware Version: 0.1.00 Build: 7640 > Build time: 201308221655 > [ 30.789455] mt76x0 2-2:1.0: loading FW - ILM 68716 + IVB 64 > [ 30.844588] mt76x0 2-2:1.0: loading FW - DLM 11476 > [ 31.172677] mt76x0 2-2:1.0: Firmware running! > [ 31.378879] mt76x0 2-2:1.0: MCU not ready > [ 31.393770] BBP version f000f200 > [ 31.410935] mt76x0 2-2:1.0: EEPROM ver:02 fae:01 > [ 31.411086] mt76x0 2-2:1.0: NIC_CONF0: fd11 NIC_CONF1: 3084 > [ 31.411088] mt76x0 2-2:1.0: Has 2GHZ 1 5GHZ 1 as you can see the eeprom reports both bands. I will review mt76x0 eeprom layout later today Regards, Lorenzo > [ 31.411089] mt76x0 2-2:1.0: PA Type 1 > [ 31.411090] mt76x0 2-2:1.0: REG 2GHZ 0 REG 5GHZ 9 > [ 31.411092] mt76x0 2-2:1.0: EEPROM country region 00 (channels 1-11) > [ 31.416308] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' > [ 31.417285] usbcore: registered new interface driver mt76x0 > > What would you like next? > > -Zero > > > > Thanks > > Stanislaw > >
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > wrote: > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > packets, etc. > > > > > > Could you elaborate a little bit please? how can you reproduce the issue? > > > just add an interface in monitor mode and run a scan? > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > use iw to remove managed mode interface, run some tool such as kismet > > or airodump-ng or even wireshark. > > But what exactly are the syptomps, I don't understand what you mean by > "mt76x0 devices don't work properly in monitor mode" ? > > > > I guess it depends on eeprom values. Could you please enable debug > > > messages a paste > > > syslog output? > > > > I don't see a mediatek specific debug near the driver selection in > > menuconfig, what debug messages do you want me to enable and how? > > You need to uncomment this line: > > # ccflags-y := -DDEBUG > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile I have done this change, rebooted, and plugged in the TP-Link t1u dongle which is 5GHz only. This is dmesg: [ 30.058587] usb 2-2: new high-speed USB device number 3 using xhci_hcd [ 30.28] usb 2-2: New USB device found, idVendor=2357, idProduct=0105, bcdDevice= 1.00 [ 30.200010] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 30.200012] usb 2-2: Product: WiFi [ 30.200013] usb 2-2: Manufacturer: MediaTek [ 30.200015] usb 2-2: SerialNumber: 1.0 [ 30.332895] usb 2-2: reset high-speed USB device number 3 using xhci_hcd [ 30.466124] mt76x0 2-2:1.0: ASIC revision: 7612 MAC revision: 76502000 [ 30.467534] mt76x0 2-2:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201308221655 [ 30.789455] mt76x0 2-2:1.0: loading FW - ILM 68716 + IVB 64 [ 30.844588] mt76x0 2-2:1.0: loading FW - DLM 11476 [ 31.172677] mt76x0 2-2:1.0: Firmware running! [ 31.378879] mt76x0 2-2:1.0: MCU not ready [ 31.393770] BBP version f000f200 [ 31.410935] mt76x0 2-2:1.0: EEPROM ver:02 fae:01 [ 31.411086] mt76x0 2-2:1.0: NIC_CONF0: fd11 NIC_CONF1: 3084 [ 31.411088] mt76x0 2-2:1.0: Has 2GHZ 1 5GHZ 1 [ 31.411089] mt76x0 2-2:1.0: PA Type 1 [ 31.411090] mt76x0 2-2:1.0: REG 2GHZ 0 REG 5GHZ 9 [ 31.411092] mt76x0 2-2:1.0: EEPROM country region 00 (channels 1-11) [ 31.416308] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 31.417285] usbcore: registered new interface driver mt76x0 What would you like next? -Zero > > Thanks > Stanislaw >
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 11:43 AM Lorenzo Bianconi wrote: > > > > > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka > > wrote: > > > > > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > > > > > First issue, is that it appears the mt76x0 devices don't work > > > > > > properly > > > > > > in monitor mode. Sometimes they seem to monitor one channel > > > > > > properly, > > > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > > > packets, etc. > > > > > > > > > > Could you elaborate a little bit please? how can you reproduce the > > > > > issue? > > > > > just add an interface in monitor mode and run a scan? > > > > > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > > > use iw to remove managed mode interface, run some tool such as kismet > > > > or airodump-ng or even wireshark. > > > > > > But what exactly are the syptomps, I don't understand what you mean by > > > "mt76x0 devices don't work properly in monitor mode" ? > > > > Basically, when I put a device using mt76x0 into monitor mode (adding > > a monitor interface with iw and removing the managed interface) it > > will not report packets on any channel, or sometimes it will report > > packets on one channel but not any others. I can switch channels as > > much, for example hopping channel 1-11, but it will only see packets > > on channel 7 and report no other packets on any other channels. In my > > actual test case it was channel 44 that successfully reported packets, > > but even that mostly doesn't work. I suspect the reason it reported > > packets on channel 44 in one of my tests is because the channel was > > set to 44 while in managed mode (connected to an AP). If I put the > > device in monitor mode before connecting to any AP, it reports packets > > on no channels. As such, I'm suspecting this has something to do with > > channel control in monitor mode. > > What about if you do not remove the managed interface and sniff on the > monitor one? Actions like that have caused great problems in the past, as the kernel won't allow channel control of a monitor interface at all when there is a managed interface on the same phy (afaik). But just for fun and codepath testing here are two test scenarios: Test 1: "iwconfig t2u mode monitor" Sees nothing on any channel, no packets reported Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" Sees nothing on any channel, no packets reported. Despite having a monitor and managed interface on the same phy, iwconfig is reporting that the channel is changing as requested. So perhaps my above "afaik" comment is partially outdated. For both tests the interface was not used to connect to any ap prior to or during testing. Thanks, Zero > > Regards, > Lorenzo > > > > > > > > > I guess it depends on eeprom values. Could you please enable debug > > > > > messages a paste > > > > > syslog output? > > > > > > > > I don't see a mediatek specific debug near the driver selection in > > > > menuconfig, what debug messages do you want me to enable and how? > > > > > > You need to uncomment this line: > > > > > > # ccflags-y := -DDEBUG > > > > > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile > > > > found it. this box takes a few min to rebuild a kernel, so I'll get > > back with this response later today hopefully. > > > > Thanks, > > Zero > > > > > > Thanks > > > Stanislaw > > >
Re: mt76x0 bug report
> > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > > wrote: > > > > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > > packets, etc. > > > > > > > > Could you elaborate a little bit please? how can you reproduce the > > > > issue? > > > > just add an interface in monitor mode and run a scan? > > > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > > use iw to remove managed mode interface, run some tool such as kismet > > > or airodump-ng or even wireshark. > > > > But what exactly are the syptomps, I don't understand what you mean by > > "mt76x0 devices don't work properly in monitor mode" ? > > Basically, when I put a device using mt76x0 into monitor mode (adding > a monitor interface with iw and removing the managed interface) it > will not report packets on any channel, or sometimes it will report > packets on one channel but not any others. I can switch channels as > much, for example hopping channel 1-11, but it will only see packets > on channel 7 and report no other packets on any other channels. In my > actual test case it was channel 44 that successfully reported packets, > but even that mostly doesn't work. I suspect the reason it reported > packets on channel 44 in one of my tests is because the channel was > set to 44 while in managed mode (connected to an AP). If I put the > device in monitor mode before connecting to any AP, it reports packets > on no channels. As such, I'm suspecting this has something to do with > channel control in monitor mode. What about if you do not remove the managed interface and sniff on the monitor one? Regards, Lorenzo > > > > > > I guess it depends on eeprom values. Could you please enable debug > > > > messages a paste > > > > syslog output? > > > > > > I don't see a mediatek specific debug near the driver selection in > > > menuconfig, what debug messages do you want me to enable and how? > > > > You need to uncomment this line: > > > > # ccflags-y := -DDEBUG > > > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile > > found it. this box takes a few min to rebuild a kernel, so I'll get > back with this response later today hopefully. > > Thanks, > Zero > > > > Thanks > > Stanislaw > >
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > wrote: > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > packets, etc. > > > > > > Could you elaborate a little bit please? how can you reproduce the issue? > > > just add an interface in monitor mode and run a scan? > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > use iw to remove managed mode interface, run some tool such as kismet > > or airodump-ng or even wireshark. > > But what exactly are the syptomps, I don't understand what you mean by > "mt76x0 devices don't work properly in monitor mode" ? Basically, when I put a device using mt76x0 into monitor mode (adding a monitor interface with iw and removing the managed interface) it will not report packets on any channel, or sometimes it will report packets on one channel but not any others. I can switch channels as much, for example hopping channel 1-11, but it will only see packets on channel 7 and report no other packets on any other channels. In my actual test case it was channel 44 that successfully reported packets, but even that mostly doesn't work. I suspect the reason it reported packets on channel 44 in one of my tests is because the channel was set to 44 while in managed mode (connected to an AP). If I put the device in monitor mode before connecting to any AP, it reports packets on no channels. As such, I'm suspecting this has something to do with channel control in monitor mode. > > > > I guess it depends on eeprom values. Could you please enable debug > > > messages a paste > > > syslog output? > > > > I don't see a mediatek specific debug near the driver selection in > > menuconfig, what debug messages do you want me to enable and how? > > You need to uncomment this line: > > # ccflags-y := -DDEBUG > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile found it. this box takes a few min to rebuild a kernel, so I'll get back with this response later today hopefully. Thanks, Zero > > Thanks > Stanislaw >
Re: mt76x0 bug report
On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > wrote: > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > I've noticed two additional issues in my testing. > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > but nothing else. The mt76x2u works great, channel control, lots of > > > packets, etc. > > > > Could you elaborate a little bit please? how can you reproduce the issue? > > just add an interface in monitor mode and run a scan? > > Correct, standard stuff, use iw to create a monitor mode interface, > use iw to remove managed mode interface, run some tool such as kismet > or airodump-ng or even wireshark. But what exactly are the syptomps, I don't understand what you mean by "mt76x0 devices don't work properly in monitor mode" ? > > I guess it depends on eeprom values. Could you please enable debug > > messages a paste > > syslog output? > > I don't see a mediatek specific debug near the driver selection in > menuconfig, what debug messages do you want me to enable and how? You need to uncomment this line: # ccflags-y := -DDEBUG in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile Thanks Stanislaw
Re: mt76x0 bug report
On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi wrote: > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > I've noticed two additional issues in my testing. > > > > First issue, is that it appears the mt76x0 devices don't work properly > > in monitor mode. Sometimes they seem to monitor one channel properly, > > but nothing else. The mt76x2u works great, channel control, lots of > > packets, etc. > > Could you elaborate a little bit please? how can you reproduce the issue? > just add an interface in monitor mode and run a scan? Correct, standard stuff, use iw to create a monitor mode interface, use iw to remove managed mode interface, run some tool such as kismet or airodump-ng or even wireshark. > > > > > Second issue, and frankly a very minor one, is that the TP-Link T1U > > (which is a 5GHz only device) still thinks it has support for 2.4GHz, > > both in managed and monitor mode. > > I guess it depends on eeprom values. Could you please enable debug > messages a paste > syslog output? I don't see a mediatek specific debug near the driver selection in menuconfig, what debug messages do you want me to enable and how? Thanks, Zero > > > > > Lastly, I already mentioned in the other thread, but it would be > > awesome if firmware version was available to ethtool. > > > > Ack, I will take care of it > Regards, > > Lorenzo > > > Thanks for all your hard work on this, > > Zero
Re: mt76x0 bug report
> > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > I've noticed two additional issues in my testing. > > First issue, is that it appears the mt76x0 devices don't work properly > in monitor mode. Sometimes they seem to monitor one channel properly, > but nothing else. The mt76x2u works great, channel control, lots of > packets, etc. Could you elaborate a little bit please? how can you reproduce the issue? just add an interface in monitor mode and run a scan? > > Second issue, and frankly a very minor one, is that the TP-Link T1U > (which is a 5GHz only device) still thinks it has support for 2.4GHz, > both in managed and monitor mode. I guess it depends on eeprom values. Could you please enable debug messages a paste syslog output? > > Lastly, I already mentioned in the other thread, but it would be > awesome if firmware version was available to ethtool. > Ack, I will take care of it Regards, Lorenzo > Thanks for all your hard work on this, > Zero
mt76x0 bug report
I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. I've noticed two additional issues in my testing. First issue, is that it appears the mt76x0 devices don't work properly in monitor mode. Sometimes they seem to monitor one channel properly, but nothing else. The mt76x2u works great, channel control, lots of packets, etc. Second issue, and frankly a very minor one, is that the TP-Link T1U (which is a 5GHz only device) still thinks it has support for 2.4GHz, both in managed and monitor mode. Lastly, I already mentioned in the other thread, but it would be awesome if firmware version was available to ethtool. Thanks for all your hard work on this, Zero