mt76x0 bug report

mt76x0 bug report

[Sid Hayn]

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

mt76x0 bug report

[Sid Hayn]

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

Re: mt76x0 bug report

[Lorenzo Bianconi]

>
> 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

Re: mt76x0 bug report

[Lorenzo Bianconi]

>
> 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

Re: mt76x0 bug report

[Sid Hayn]

On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
<lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Stanislaw Gruszka]

On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> <lorenzo.bianconi@redhat.com> 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

[Stanislaw Gruszka]

On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>
> On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > <lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Lorenzo Bianconi]

>
> On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >
> > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > <lorenzo.bianconi@redhat.com> 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

[Lorenzo Bianconi]

>
> On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 11:43 AM Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> wrote:
>
> >
> > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > >
> > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > > <lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 11:43 AM Lorenzo Bianconi
<lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> >
> > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > >
> > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Lorenzo Bianconi]

> 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

[Lorenzo Bianconi]

> 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);

Re: mt76x0 bug report

[Sid Hayn]

On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
<lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

*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 <sidhayn@gmail.com> wrote:
>
> On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> <lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

*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 <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Davide Caratti]

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

[Davide Caratti]

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

[Lorenzo Bianconi]

>
> *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 <sidhayn@gmail.com> wrote:
> >
> > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > <lorenzo.bianconi@redhat.com> 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

[Lorenzo Bianconi]

>
> *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 <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> 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 <sidhayn@gmail.com> wrote:
> > >
> > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > > <lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi
<lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Fri, Sep 14, 2018 at 11:51 AM Sid Hayn <sidhayn@gmail.com> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi
> <lorenzo.bianconi@redhat.com> 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 <sidhayn@gmail.com> wrote:
> > > >
> > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > > > <lorenzo.bianconi@redhat.com> 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

[Sid Hayn]

On Fri, Sep 14, 2018 at 11:51 AM Sid Hayn <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi
> <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> > > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Stanislaw Gruszka]

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

[Stanislaw Gruszka]

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

[Sid Hayn]

On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka <sgruszka@redhat.com> 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

[Sid Hayn]

On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Stanislaw Gruszka]

On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote:
> On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka <sgruszka@redhat.com> 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

[Stanislaw Gruszka]

On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote:
> On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Wed, Sep 19, 2018 at 7:15 AM Stanislaw Gruszka <sgruszka@redhat.com> wro=
te:
>
> On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote:
> > On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka <sgruszka@redhat.com>=
 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 bu=
t....
> > > >
> > > > So was testing all of my dongles that use the driver you are workin=
g
> > > > 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, bu=
t
> > > > it actually got enough scan data back to attempt authentication wit=
h 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 t=
ime
> > > > 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 proba=
bly
> > > > hardware lying to you is now even lower on your list since this saf=
ely
> > > > 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, =E2=80=98you can=E2=80=99t find the 5GHz network any more."

Yup, I agree, it's wierd.

-Zero

>
> Regards
> Stanislaw

Re: mt76x0 bug report

[Sid Hayn]

On Wed, Sep 19, 2018 at 7:15 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>
> On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > <lorenzo.bianconi@redhat.com> 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.200008] 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: 76100002 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

[Sid Hayn]

On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.200008] 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: 76100002 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

[Lorenzo Bianconi]

> On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >
> > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > <lorenzo.bianconi@redhat.com> 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.200008] 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: 76100002 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

[Lorenzo Bianconi]

> On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.200008] 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: 76100002 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

[Lorenzo Bianconi]

>
> > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > >
> > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > > <lorenzo.bianconi@redhat.com> 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

[Lorenzo Bianconi]

>
> > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > >
> > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote:
> > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi
> > > > <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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