Bug 13685

linuxero from QA just hit it with iso testing

Whiteboard: MGA4TOO, MGA3TOO, 5alpha1 => MGA4TOO, MGA3TOO, 5RC
CC: (none) => mageia

Adding Martin in CC too.

CC: (none) => mageia

Btw, I can confirm I've still seen this with several 5RC isos (did not test the very last round, yet), but it didn't sink in because I can connect to different access point at home, now :-/

Forgot to include QA team, when I replied to linuxer's mail, but it belongs in the bug report, anyway.

Op 23-04-15 om 12:45 schreef Linuxero:
> Yes indeed ! I hope this can be fixed before the final release. It is a pity
> not to be able to recommend Mageia professionally for such a bug
>

There is not a _very_ big chance.

blino (Olivier Blin) who used to take care of drakx-net is almost without any free time.

tv (Thierry Vignaud) won't fix non-release-blocking DrakX issues so late in the release cycle, if he doesn't know that specific DrakX tool so well that he is sure not to get unwanted regressions or side-effects.

So unless some perl guru who knows our tools very well says this can't break things, it won't be done before Mageia 5 release.

However, when cauldron reopens, ± a week after Mageia 5 release, we can change the code in http://gitweb.mageia.org/software/drakx-net/tree/lib/network/monitor.pm like you proposed in
https://forums.mageia.org/en/viewtopic.php?f=8&t=7077

I assume nothing will be broken by your fix and that it'll end up nicely in Mageia 6

Cheers,
marja

Oh, for installed systems, it can then be pushed to 5 updates_testing :-)

Created attachment 6354 [details]
1st of two drakx-net patches that include linuxero's fix

Created attachment 6355 [details]
2nd patch (too update NEWS and version)

Created attachment 6363 [details]
/usr/lib/libDrakX/network/monitor.pm after installing the packages

Just for the record, those packages were made after adding those patches to yesterday's
http://gitweb.mageia.org/software/drakx-net/ 

@ linuxero

there is more chance your fix can be added before Mga 5 is released, this is a discussion with one of my mentors on #mageia-mentoring


> 2015:04:25:19:00 < marja11> doktor5000: about the \x00 bug, I'm starting to
> think that that doesn't need to wait till after Mga5 release
> 2015:04:25:19:01 < marja11> doktor5000: the only thing linuxero's code does,
> is remove any '\x00's it sees
> 2015:04:25:19:01 < marja11> doktor5000: I cannot imagine that that could 
> break anything
> 2015:04:25:19:02 < marja11> (but I can confirm that it worked when I added
> his lines locally, last year)

> 2015:04:25:19:05 < doktor5000> marja11: if it fixes the issue it should be in 
> before release - but you should find at least one or two people to verify the 
> new packages fix the issue

So, if you see a chance to test the packages...

My only concern is, that I may have made a typo in the first patch, but don't see it. Other than that, there is no reason it shouldn't work.

I'll attach the /usr/lib/libDrakX/network/monitor.pm that was created when I installed the new packages yesterday.

(Its owner will try to revive the WAP at home that had the \x00 issue, but even if the packages work for me, that doesn't count because I made them...)

CC'ing anaselli and pasmatt, because I think pasmatt already ported some of the drakx-net code, just in case /lib/network/monitor.pm was among it.

CC: (none) => anaselli, matteo.pasotti

Created attachment 6364 [details]
drakx-net shows mac address now instead of repeated \x00

that WAP works again :-)

The output from "iwlist scan" at the bottom, says that 00:18:F8:7A:17:91 has ESSID:"\x00\x00"

However, draknetcenter above it, now correctly shows the Mac address instead of the fake ESSID

Comment on attachment 6354 [details]
1st of two drakx-net patches that include linuxero's fix

don't assign to $_
Just use sg lik:
  $essid =~ s/\\x00//g;

(In reply to Thierry Vignaud from comment #18)
> Comment on attachment 6354 [details]
> 1st of two drakx-net patches that include linuxero's fix
> 
> don't assign to $_
> Just use sg lik:
>   $essid =~ s/\\x00//g;

is that valid, too, when there's a dereferencer, so to improve:

 $_ = $net->{essid};
 s/\\x00//g;
 $net->{essid} = $_;

can the following be used instead: 

$net->{essid} =~ s/\\x00//g;

(should have added a "?")

ah, it must be valid, found an example, thx to Shlomi who helped me when I didn't manage to find this with grep, and proposed to use
ack '(?:=~.*?->)|(?:->.*?=~)'



software/DocTeam_drakx/images/make_boot_img
135:    $_->{append} =~ s/\s+/ /g;

yes.
But see bellow.

Created attachment 6365 [details]
just skip bogus ESSID when reading it

It's simpler to just skip the bogus ESSID when reading it.
After all, it could affect other places.
Though it would be best if either iwlist or the driver could be fixed...
(which is unlikely if the bug is in iwlist)
Can you test that patch?

Created attachment 6366 [details]
first of 3 patches that replace the 2 patches we had

Attachment 6354 is obsolete: 0 => 1

Created attachment 6367 [details]
2nd replaced patch

Attachment 6355 is obsolete: 0 => 1

Created attachment 6368 [details]
3rd from the patch set

last of the new set of patches, with linuxero's fix and thierry's improvement to it

(In reply to Thierry Vignaud from comment #23)
> Created attachment 6365 [details]
> just skip bogus ESSID when reading it
> 
> It's simpler to just skip the bogus ESSID when reading it.
> After all, it could affect other places.
> Though it would be best if either iwlist or the driver could be fixed...
> (which is unlikely if the bug is in iwlist)
> Can you test that patch?

Why didn't I see this comment?

I'll test the patch, provided that \x00 network isn't down again

BTW if would go your way, the patches should just be collapsed into just one.
But I think my patch is better as only one place needs to be fixed

Actually anyone with an hidden network should be able to test

(In reply to Thierry Vignaud from comment #28)
> BTW if would go your way, the patches should just be collapsed into just one.

I agree

> But I think my patch is better as only one place needs to be fixed

uploaded the packages with your patch here
http://waesvanm.home.xs4all.nl/Packaging/Bug13685_2/(In reply to Thierry Vignaud from comment #29)

> Actually anyone with an hidden network should be able to test

What will change for them, then? (asking, because the \x00 network is down again)

Oh, wait, you mean test for regressions?

oops, sorry for the missing return after the link

http://waesvanm.home.xs4all.nl/Packaging/Bug13685_2/

I downgraded the 4 drakx-net packages to the current cauldron version, updated them to the ones in the link above and rebooted.

Then my brother kicked the \x00 network, so it's up again.

Thierry's single patch does indeed fix the problem, I see the mac address instead of the fake SSID in draknetcenter.

Also, line 99-103 of /usr/lib/libDrakX/network/monitor.pm on my system is now:

  /Address: (.*)/ and $net->{ap} = lc($1);
            if (my ($essid) = /ESSID:"(.*?)"/) {
                $essid !~ /^\\x00/ and $net->{essid} = $essid;
            }
            /Mode:(\S*)/ and $net->{mode} = $1;

Weird, installed the same packages on a different partition.

However, when trying to set up the network, I accidentally chose the wrong hidden network (by choosing the wrong mac address) and gave it the SSID of the other one.

that made the fake \x00 SSID pop up again in draknetcenter.

I'll reboot into it and see what it looks like, now

(In reply to Marja van Waes from comment #33)
> Weird, installed the same packages on a different partition.
> 
> However, when trying to set up the network, I accidentally chose the wrong
> hidden network (by choosing the wrong mac address) and gave it the SSID of
> the other one.
> 
> that made the fake \x00 SSID pop up again in draknetcenter.
> 
> I'll reboot into it and see what it looks like, now

after reboot it still had the \x00

I'm no longer sure it was my mistake to select the wrong mac address, to my surprise I saw (after removing anything that referred to the "\x00" network in /etc/wpa_supplicant.conf, /etc/sysconfig/network-scripts/ and in /etc/sysconfig/network-scripts/wireless.d/ that I could think of, that a _not_ hidden network that I used with that partition before, showed the bssid (mac address) of the hidden \x00 network in wpa_supplicant. I'm sure I hadn't touched that part.

I've tried everything to reproduce the mix-up, however now with the first set of packages but didn't manage to. The only thing that happened was, once a connection to a not-hidden network had been set up, it was impossible to let draknetcenter show the true SSID after filling out the fields for name and password. Selecting the mac address and trying to connect, it would connect to the not-hidden network. It would only show the true SSID, and only make it possible to connect to it, after removing the not-hidden network from /etc/sysconfig/network-scripts/wireless.d/ and /etc/wpa_supplicant.

s/wpa_supplicant/wpa_supplicant.conf/

(In reply to Thierry Vignaud from comment #29)
> Actually anyone with an hidden network should be able to test

I was going to test this, but I don't see the problem with my current hardware - no problem connecting to a hidden network (using a Live DVD to make sure I have no configuration left lying around). I know I did see the \x00 issue in the past, but I've changed both laptop and access point since then.

(In reply to Martin Whitaker from comment #36)

> 
> I was going to test this, but I don't see the problem with my current
> hardware - no problem connecting to a hidden network (using a Live DVD to
> make sure I have no configuration left lying around). I know I did see the
> \x00 issue in the past, but I've changed both laptop and access point since
> then.

It must have been the access point, I've seen it with 6 or 7 different wlan adapters, on 5 different systems, but it was always the same access point that had it.

Anyway, Thierry pushed the fix, so closing this report.

I don't think it needs to be kept open in case someone gets the same issue I hit while testing: I doubt there'll be anyone who'll try to connect to a hidden network, if there's a not hidden one available that has been used before. 

However, feel free to reopen this report if anyone still sees "\x00"s

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Sorry but there seems to be a regression - both on platform MGA5 and MGA6.

At least I again encounter the severe problems establishing/keeping coonection(s) to my hidden network after the latest upgrades on both platforms.

/René

Resolution: FIXED => (none)
CC: (none) => rene
Status: RESOLVED => REOPENED

(In reply to René Lagoni Neukirch from comment #38)
> Sorry but there seems to be a regression - both on platform MGA5 and MGA6.
> 
> At least I again encounter the severe problems establishing/keeping
> coonection(s) to my hidden network after the latest upgrades on both
> platforms.
> 
> /René

You're not mentioning that your access point is listed as \x00\x00 or so in draknetcenter, so in this screen http://doc.mageia.org/mcc/5/en/content/images/draknetcenter1.png

Is it?

If not, then please file a separate bug report and close this one as FIXED again.

Assignee: bugsquad => mageiatools

(In reply to Marja van Waes from comment #39)
> (In reply to René Lagoni Neukirch from comment #38)
> > Sorry but there seems to be a regression - both on platform MGA5 and MGA6.
> > 
> > At least I again encounter the severe problems establishing/keeping
> > coonection(s) to my hidden network after the latest upgrades on both
> > platforms.
> > 
> > /René
> 
> You're not mentioning that your access point is listed as \x00\x00 or so in
> draknetcenter, so in this screen
> http://doc.mageia.org/mcc/5/en/content/images/draknetcenter1.png
> 
> Is it?
> 
> If not, then please file a separate bug report and close this one as FIXED
> again.

Well, yes, the \x00's were both present on draknet center view and in the /etc/wpa_supplicant.conf (the net_applet ?)

I edited the /usr/lib/libDrakX/network/monitor.pm file in two places as described (the things with $essid =~ s/\\x00//g and ...net->...) and after a boot or two it worked fine again on both platforms (MGA5 and MGA6).

(In reply to René Lagoni Neukirch from comment #40)

> 
> Well, yes, the \x00's were both present on draknet center view and in the
> /etc/wpa_supplicant.conf (the net_applet ?)
> 
> I edited the /usr/lib/libDrakX/network/monitor.pm file in two places as
> described (the things with $essid =~ s/\\x00//g and ...net->...) and after a
> boot or two it worked fine again on both platforms (MGA5 and MGA6).

Thanks.

The fix that solved this bug was committed here:

http://gitweb.mageia.org/software/drakx-net/commit/?id=cc48b5ef34849a2daa5645841f618d389c8179b0

It is still there
http://gitweb.mageia.org/software/drakx-net/tree/lib/network/monitor.pm#n100

and it is still in my /usr/lib/libDrakX/network/monitor.pm (from libdrakx-net-2.31-1.mga6)


René, can you confirm that fix was still (line numbers in Mga5 may differ) in your /usr/lib/libDrakX/network/monitor.pm before you started editing it? 

Please do also tell with which updates the bug returned.

It is probably easiest to do that in Mageia 5, first (because Mageia 5 gets less updates than Mageia 6)

 run e.g. 

    rpm -qa --last | head -n100 

and increase or decrease "100" until you're sure all updates are in it that you did before you hit this issue again _and_ the ones that your did between the two reboots preceding seeing this issue again.

Please _attach_ that list, after removing the updates at the top of the list of which you are sure they were done after seeing this issue again.

Repeat for Mageia 6 if you like (I'm not sure that is needed)

(Note that it is most likely needed to file a separate bug report, but let's first try to find out what is going on, before cloning and closing this report)

Keywords: Triaged => NEEDINFO
Whiteboard: MGA4TOO, MGA3TOO, 5RC => MGA5TOO

Created attachment 9207 [details]
/usr/lib/libDrakX/network/monitor.pm with two editions, after line 38 & line 94

Hi Marja,

I will this evening obtain the versioning et al. info requested.

Before that, it just might clarify if I attach my edited version of
/usr/lib/libDrakX/network/monitor.pm - enclosed pls find the file.

I added the substitions (mentioned in a previous bug report) in two places around line 38 and line 94. And for me it did the trick.
I've marked them "# Added manually /RLN".

If this alone clarifies, pls let me know. Otherwise I will supply the requested info.

And - maybe it's self evident - but I connect to a hidden network.

Created attachment 9208 [details]
Dump from the command: rpm -qa --last | head -n300

As requested.

Where did this text go - now added ...
------------------------------------------------------------------------------
Hi again Marja,

I just issued the command rpm -qa --last | head -n300.
As you requested.

Enclosed pls find the dump named Marja20170416.dump

I also checked /usr/lib/libDrakX/network/monitor.pm both on the MGA5 and 6 platform.
They seem completely alike and both have 154 lines (after my 4 extra lines).
I know nothing of PERL, but they look pretty much the same.

It seems that I edited both the ...monitor.pm and /etc/wpa_supplicant.conf on april 15'th 2017.

Hopes this both helps and clarifies.

/René

------------------------------------------------------------------------------

(In reply to René Lagoni Neukirch from comment #42)
> Created attachment 9207 [details]
> /usr/lib/libDrakX/network/monitor.pm with two editions, after line 38 & line
> 94
> 
> Hi Marja,
> 
> I will this evening obtain the versioning et al. info requested.
> 
> Before that, it just might clarify if I attach my edited version of
> /usr/lib/libDrakX/network/monitor.pm - enclosed pls find the file.
> 
> I added the substi[tu]tions (mentioned in a previous bug report) in two places
> around line 38 and line 94. And for me it did the trick.
> I've marked them "# Added manually /RLN".
> 
> If this alone clarifies, pls let me know. Otherwise I will supply the
> requested info.
> 
> And - maybe it's self evident - but I connect to a hidden network.(In reply to René Lagoni Neukirch from comment #43)
> Created attachment 9208 [details]
> Dump from the command: rpm -qa --last | head -n300
> 
> As requested.(In reply to René Lagoni Neukirch from comment #43)
> Created attachment 9208 [details]
> Dump from the command: rpm -qa --last | head -n300
> 
> As requested.

Just for the record.

The patches I made were found here (I think):
https://forums.mageia.org/en/viewtopic.php?f=8&t=7077

Unfortunately the link is dead - apparently the whole site is down/closed ?
****************************************************************************

(In reply to René Lagoni Neukirch from comment #44)
> Where did this text go - now added ...
> -----------------------------------------------------------------------------
> -
> Hi again Marja,
> 
> I just issued the command rpm -qa --last | head -n300.
> As you requested.
> 
> Enclosed pls find the dump named Marja20170416.dump
> 
> I also checked /usr/lib/libDrakX/network/monitor.pm both on the MGA5 and 6
> platform.
> They seem completely alike and both have 154 lines (after my 4 extra lines).
> I know nothing of PERL, but they look pretty much the same.
> 
> It seems that I edited both the ...monitor.pm and /etc/wpa_supplicant.conf
> on april 15'th 2017.
> 
> Hopes this both helps and clarifies.
> 
> /René
> 
> -----------------------------------------------------------------------------
> -
> 
> (In reply to René Lagoni Neukirch from comment #42)
> > Created attachment 9207 [details]
> > /usr/lib/libDrakX/network/monitor.pm with two editions, after line 38 & line
> > 94
> > 
> > Hi Marja,
> > 
> > I will this evening obtain the versioning et al. info requested.
> > 
> > Before that, it just might clarify if I attach my edited version of
> > /usr/lib/libDrakX/network/monitor.pm - enclosed pls find the file.
> > 
> > I added the substi[tu]tions (mentioned in a previous bug report) in two places
> > around line 38 and line 94. And for me it did the trick.
> > I've marked them "# Added manually /RLN".
> > 
> > If this alone clarifies, pls let me know. Otherwise I will supply the
> > requested info.
> > 
> > And - maybe it's self evident - but I connect to a hidden network.(In reply to René Lagoni Neukirch from comment #43)
> > Created attachment 9208 [details]
> > Dump from the command: rpm -qa --last | head -n300
> > 
> > As requested.(In reply to René Lagoni Neukirch from comment #43)
> > Created attachment 9208 [details]
> > Dump from the command: rpm -qa --last | head -n300
> > 
> > As requested.

Thanks for all the feedback, René


I understand you only rebooted once between October 4 and noticing the \x00 again?

No Marja, I boot every day as I close the machine(s) every night.

The problems were encountered approximately between April 8'th and 15'th.

The day I did the editing (both on MGA5 and 6), as far as I recall, I had to boot only once on MGA6 and 2-3 times on MGA5.

Sorry for being inaccurate, but I wasn't aware at the time to note strictly what happened, how, when and how many times...


In reply to Marja van Waes from comment #46)
> Thanks for all the feedback, René
> 
> 
> I understand you only rebooted once between October 4 and noticing the \x00
> again?

(In reply to René Lagoni Neukirch from comment #47)
> No Marja, I boot every day as I close the machine(s) every night.
> 
> The problems were encountered approximately between April 8'th and 15'th.

So your wrote comment #38 immediately after seeing the issue again, on April 8.
According to attachment #9208 [details] there were no updates in the last 48 hours before you filed this bug.

If an update really caused this regression, then the 5.1 and 6sta2 Live DVDs should not have this issue, because the packages on them date from before you started seeing \x00 again.

Do you mind checking?

Sorry, but I am to check what?
I just registeted a (new/recurring) behavior.
Reported "my" fix.
It works, so I really don't know-how to replay on that ...

(In reply to Marja van Waes from comment #48)
> (In reply to René Lagoni Neukirch from comment #47)
> > No Marja, I boot every day as I close the machine(s) every night.
> > 
> > The problems were encountered approximately between April 8'th and 15'th.
> 
> So your wrote comment #38 immediately after seeing the issue again, on April
> 8.
> According to attachment #9208 [details] there were no updates in the last 48
> hours before you filed this bug.
> 
> If an update really caused this regression, then the 5.1 and 6sta2 Live DVDs
> should not have this issue, because the packages on them date from before
> you started seeing \x00 again.
> 
> Do you mind checking?

(In reply to René Lagoni Neukirch from comment #49)
> Sorry, but I am to check what?

Do you mind starting a Mageia5.1 or a Mageia6sta2 Live DVD in Live mode, to check whether your access point is shown with its mac address in draknetcenter, or whether you see one or more  "\x00"s instead?

WILL DO ...

I will burn both Live DVDs today and I will make you a 4-way test (2 DVDs on 2 platforms).

I shall return with the results asap (i.e _probably_ tonight).

Info: I use an rtl8192cu USB (which by the way is detected as a bluetooth unit) on MGA5 and an Atheros WG311TV1H3 card on MGA6. My router is a Huawei 4G B310S-22.


(In reply to Marja van Waes from comment #50)
> (In reply to René Lagoni Neukirch from comment #49)
> > Sorry, but I am to check what?
> 
> Do you mind starting a Mageia5.1 or a Mageia6sta2 Live DVD in Live mode, to
> check whether your access point is shown with its mac address in
> draknetcenter, or whether you see one or more  "\x00"s instead?

@ René

Thanks for being so willing to help.

I don't think a 4-way test is needed, though ;-)

Instead of testing 4 times, could you: 

* test one or two times, but also, either in a normal install, or while testing:

* Hover over net-applet (the icon on your panel/taskbar/whatever you call it)
  to see what name your network card has. That should be something like "wlp3s0"

  Then run, as root (replace wlp3s0 with the correct string for your interface):

      iwlist wlp3s0 scan | grep '\\x00'

  and

      iw dev wlp3s0 scan | grep '\\x00'


  What does the first command return, and does the 2nd command return something,
  too (if so, what)?

* Can you tell whether shortly before you hit this issue again, you had
  connected to a different than usual wireless network with both Mga5 and
  Cauldron?

Well, Marja, you're right, there is NO need for a 4-way effort. :-)

My first (and only) test result was showing lots of \x00\x00's ...
Pls see attached pic.

The MGA6 Live DVD started all right, I then configured the network and it worked (but at very low speed ...). The Netapplet icon dissappeared, but "halfway" showed up when hovering it. But no click response, what so ever).

Then I just disconnected in the netcenter, and reconnected --- and --- all the \x00's were there (see pic).

So, to your last question, it does seem likely, that when disconnecting/reconnecting something goes wrong during network scan or during (trying to) connect phase. So in short: I did not connect, but maybe the network was lost somehow and reconnect failed somehow.

Hope this helps ... (I'm am talking end-user language, I know).


(In reply to Marja van Waes from comment #52)
> @ René
> 
> Thanks for being so willing to help.
> 
> I don't think a 4-way test is needed, though ;-)
> 
> Instead of testing 4 times, could you: 
> 
> * test one or two times, but also, either in a normal install, or while
> testing:
> 
> * Hover over net-applet (the icon on your panel/taskbar/whatever you call it)
>   to see what name your network card has. That should be something like
> "wlp3s0"
> 
>   Then run, as root (replace wlp3s0 with the correct string for your
> interface):
> 
>       iwlist wlp3s0 scan | grep '\\x00'
> 
>   and
> 
>       iw dev wlp3s0 scan | grep '\\x00'
> 
> 
>   What does the first command return, and does the 2nd command return
> something,
>   too (if so, what)?
> 
> * Can you tell whether shortly before you hit this issue again, you had
>   connected to a different than usual wireless network with both Mga5 and
>   Cauldron?

Created attachment 9217 [details]
Marja, MGA6 lots of x00x00x00 20170418

Marja, MGA6 lots of x00x00x00 20170418

(In reply to René Lagoni Neukirch from comment #54)
> Created attachment 9217 [details]
> Marja, MGA6 lots of x00x00x00 20170418
> 

With effort, I do see the \x00\x00\x00\x00 ;-)

The "iw" tool might perform better than "iwlist" (which is used by drakx-net), it would really help if you could do the 2nd thing requested in comment #52 :

> 
> * Hover over net-applet (the icon on your panel/taskbar/whatever you call it)
>   to see what name your network card has. That should be something like
>   "wlp3s0"
> 
>   Then run, as root (replace wlp3s0 with the correct string for your
>   interface):
> 
>       iwlist wlp3s0 scan | grep '\\x00'
> 
>   and
> 
>       iw dev wlp3s0 scan | grep '\\x00'
> 
> 
>   What does the first command return, and does the 2nd command return
>   something, too (if so, what)?


Do you think you could do that?

Two dumps below ...

And here is the 'iwlist scan' WITH \x00's from my "normal" MGA6:
(I note, that the number of \x00's match the number of characters ind the network name ...)

wlp6s1    Scan completed :
          Cell 01 - Address: D4:61:2E:7F:D9:71
                    Channel:7
                    Frequency:2.442 GHz (Channel 7)
                    Quality=66/70  Signal level=-44 dBm  
                    Encryption key:on
                    ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
                    Mode:Master
                    Extra:tsf=000000010361919e
                    Extra: Last beacon: 220ms ago
                    IE: Unknown: 00080000000000000000
                    IE: Unknown: 010882840B162430486C
                    IE: Unknown: 030107
                    IE: Unknown: 050400010000
                    IE: Unknown: 2A0100
                    IE: Unknown: 2F0100
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 32040C121860
                    IE: Unknown: 2D1ABC1917FFFF000001000000000000000000000000000000000000
                    IE: Unknown: 3D1607001700000000000000000000000000000000000000
                    IE: Unknown: 4A0E14000A002C01C800140005001900
                    IE: Unknown: 7F080500000000000040
                    IE: Unknown: DD090010180202000C0000
                    IE: Unknown: DD180050F2020101840003A4000027A4000042435E0062322F00
                    IE: Unknown: 46057208010000

And here is the 'iw wlp6s1 scan | head -n50' WITH \x00's, again from my "normal" MGA6:

iw wlp6s1 scan | head -n50
BSS d4:61:2e:7f:d9:71(on wlp6s1)
        TSF: 4801741191 usec (0d, 01:20:01)
        freq: 2442
        beacon interval: 100 TUs
        capability: ESS Privacy ShortSlotTime RadioMeasure (0x1411)
        signal: -44.00 dBm
        last seen: 170 ms ago
        Information elements from Probe Response frame:
        SSID: \x00\x00\x00\x00\x00\x00\x00\x00
        Supported rates: 1.0* 2.0* 5.5 11.0 18.0 24.0 36.0 54.0 
        DS Parameter set: channel 7
        TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
        ERP: <no flags>
        ERP D4.0: <no flags>
        RSN:     * Version: 1
                 * Group cipher: CCMP
                 * Pairwise ciphers: CCMP
                 * Authentication suites: PSK
                 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
        Extended supported rates: 6.0 9.0 12.0 48.0 
        HT capabilities:
                Capabilities: 0x19bc
                        HT20
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 7935 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT RX MCS rate indexes supported: 0-15, 32
                HT TX MCS rate indexes are undefined
        HT operation:
                 * primary channel: 7
                 * secondary channel offset: no secondary
                 * STA channel width: 20 MHz
                 * RIFS: 0
                 * HT protection: non-HT mixed
                 * non-GF present: 1
                 * OBSS non-GF present: 1
                 * dual beacon: 0
                 * dual CTS protection: 0
                 * STBC beacon: 0
                 * L-SIG TXOP Prot: 0
                 * PCO active: 0
                 * PCO phase: 0
        Overlapping BSS scan params:
                 * passive dwell: 20 TUs

Comment on attachment 9217 [details]
Marja, MGA6 lots of x00x00x00 20170418

Most sorry for the very bad quality - but it does the job ...

(In reply to René Lagoni Neukirch from comment #56)
> Two dumps below ...
> 
> And here is the 'iwlist scan' WITH \x00's from my "normal" MGA6:
> (I note, that the number of \x00's match the number of characters ind the
> network name ...)

>                     ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00"

> And here is the 'iw wlp6s1 scan | head -n50' WITH \x00's, again from my
> "normal" MGA6:

>         SSID: \x00\x00\x00\x00\x00\x00\x00\x00


So there's no difference, using iw instead of iwlist here
http://gitweb.mageia.org/software/drakx-net/tree/lib/network/monitor.pm#n81 :
  my @list = `$::prefix/sbin/iwlist $o_intf scanning 2>/dev/null`;

won't help to solve this.

Btw, I wasn't aware that using "iw wlp6s1 scan" instead of "iw dev wlp6s1 scan" works, too ;-) (It does, just tried)

Sorry about the very bad photo, but pls. find a screen dump from the network center on my "normal" MGA6 - i.e. the one witj the \x00's in both iw-dumps.


(In reply to Marja van Waes from comment #58)
> (In reply to René Lagoni Neukirch from comment #56)
> > Two dumps below ...
> > 
> > And here is the 'iwlist scan' WITH \x00's from my "normal" MGA6:
> > (I note, that the number of \x00's match the number of characters ind the
> > network name ...)
> 
> >                     ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00"
> 
> > And here is the 'iw wlp6s1 scan | head -n50' WITH \x00's, again from my
> > "normal" MGA6:
> 
> >         SSID: \x00\x00\x00\x00\x00\x00\x00\x00
> 
> 
> So there's no difference, using iw instead of iwlist here
> http://gitweb.mageia.org/software/drakx-net/tree/lib/network/monitor.pm#n81 :
>   my @list = `$::prefix/sbin/iwlist $o_intf scanning 2>/dev/null`;
> 
> won't help to solve this.
> 
> Btw, I wasn't aware that using "iw wlp6s1 scan" instead of "iw dev wlp6s1
> scan" works, too ;-) (It does, just tried)

Created attachment 9218 [details]
Marja, Netcenter view of the net (iw-commands showing \x00's) 20170418

Even this is somewhat bad quality, due to ip-scaling ...

PS: On the Live DVD try, Netcenter showed \x00's ...

The "normal" MGA6 runs with the edited ...monitor.pm

Just to be precise.

(In reply to René Lagoni Neukirch from comment #60)
> Created attachment 9218 [details]
> Marja, Netcenter view of the net (iw-commands showing \x00's) 20170418
> 
> Even this is somewhat bad quality, due to ip-scaling ...

Just extra observations:

I've now gone the "full Monty" and upgraded my "production" machine to MGA6/Sta2.

Again the \x00 problem was encountered until I did the editing of the monitor.pm file as previously reported.

And next - you will probably flush me ... redirect me to another bug number ...

BUT

It would be a really great service to include the proper driver for RTL8192cu et. al).
I followed the guide from somewhere on the Internet. Now I have just compiled the v. 1.10 driver - AND - it works properly.
The driver version included in Sta2 is far from operational. As has been since MGA4 !!!

So... [no-flush ...] could you pls. include the proper RTL8192cu:

# urpmi kernel-[server,desktop]-devel-latest dkms git

- Reboot to enable dkms (mandatory).

# cd /usr/src/
# git clone https://github.com/pvaret/rtl8192cu-fixes.git

- Retrieve driver version in dkms.conf (1.10 for me) by:

# cat ./rtl8192cu-fixes/dkms.conf
...
# mv rtl8192cu-fixes/ rtl8192cu-fixes-1.10/
# dkms add -m rtl8192cu-fixes -v 1.10
# dkms build -m rtl8192cu-fixes -v 1.10
# dkms install -m rtl8192cu-fixes -v 1.10
# depmod -a
# cp ./rtl8192cu-fixes-1.10/blacklist-native-rtl8192.conf /etc/modprobe.d/

- Reboot

PLEASE ... [no-flush ...]

(In reply to René Lagoni Neukirch from comment #61)
> PS: On the Live DVD try, Netcenter showed \x00's ...
> 
> The "normal" MGA6 runs with the edited ...monitor.pm
> 
> Just to be precise.
> 
> (In reply to René Lagoni Neukirch from comment #60)
> > Created attachment 9218 [details]
> > Marja, Netcenter view of the net (iw-commands showing \x00's) 20170418
> > 
> > Even this is somewhat bad quality, due to ip-scaling ...

After installing the sta2 Im sorry to report, that the \0x00's are still there.
I had a lost connection, which re-established itselv, and then ths (e)SSID was all \0x00's.
Pls see uploaded screendump.

Created attachment 9349 [details]
Still lots of 0x00's after lost connection

@ René

Is this issue still valid?

It is still valid

(In reply to Muhammad Tailounie from comment #66)
> It is still valid

And now? With which drakx-net version, if still valid?

(In reply to Marja Van Waes from comment #67)
> (In reply to Muhammad Tailounie from comment #66)
> > It is still valid
> 
> And now? With which drakx-net version, if still valid?

And: do only old, no longer supported wireless access points appear like that, or also still supported WAPs?

Hi Marja;

Sorry it took me some time to test. The thing is that it's been quite some time that I don't use net_applet. Anyways; I tested it on Plasma and the problem seems to be solved. The only thing that I could notice is that the system try's icon does not update status on live boot.

Bottom line; no more \x00 showing up. I am not aware of other WIFI adpters, but I could try to do some further testing the coming days.

Thank you all

(In reply to Muhammad Tailounie from comment #69)
> Hi Marja;
> 
> Sorry it took me some time to test. The thing is that it's been quite some
> time that I don't use net_applet. Anyways; I tested it on Plasma and the
> problem seems to be solved. The only thing that I could notice is that the
> system try's icon does not update status on live boot.
> 
> Bottom line; no more \x00 showing up. I am not aware of other WIFI adpters,
> but I could try to do some further testing the coming days.
> 
> Thank you all

Thanks for testing, Muhammad. Closing as fixed then, since I assume you would have reported if you had found another access point erroneously showing up like that. Please reopen if I'm closing this report too fast.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED