In the forums, linuxero posted a fix for the problem that some hidden networks are displayed as \x00\x00* in draknetcenter. (Filip posted about it on dev ml, on February 23rd) https://forums.mageia.org/en/viewtopic.php?f=8&t=7077 It would be very nice to have that fix included in Mageia, it can make the difference between having a working network or not, and between getting auto-reconnected when the network drops, or having to go through the "Set up a new network interface" steps of drakconnect again. I just tested it after installing pre-Mga5alpha1 and it works fine.
Whiteboard: (none) => MGA4TOO, MGA3TOO, 5alpha1
CC: (none) => thierry.vignaud
Humm. In the old days, we used gethostby*() with dietlibc. Then we switched from gethostby*() to getaddrinfo(): http://gitweb.mageia.org/software/drakx/log/mdk-stage1/dns.c Then we switched from dietlibc to glibc when using dracut (which makes use gethostby*() again). Just after mga4, I made us use the same code with glibc that we used with dietlibc: http://gitweb.mageia.org/software/drakx/commit/mdk-stage1/dns.c?id=6d8df12830883d6537e6844a6deae8adb8bfe37c This seems to be the root cause of this issue. Maybe glibc's resolver needs some file we lack?
Assignee: mageia => bugsquadCC: (none) => mageia, mageia
Actually, the following lines cause issues with glibc: /* prevent from timeouts */ if (_res.nscount == 0) return -1; Blino, any idea? Maybe do we lack a call to res_init() in some code path?
Created attachment 5262 [details] workaround
(In reply to Thierry Vignaud from comment #1) > Just after mga4, I made us use the same code with glibc that we used with > dietlibc: > http://gitweb.mageia.org/software/drakx/commit/mdk-stage1/dns. > c?id=6d8df12830883d6537e6844a6deae8adb8bfe37c > > This seems to be the root cause of this issue. > Maybe glibc's resolver needs some file we lack? That sounds as if this problem was only introduced after Mga4, but it already existed (at least) a year earlier. At that time it wasn't a big issue for me, because I didn't have that laptop yet which so easily loses the wlan connection. https://bugs.mageia.org/show_bug.cgi?id=8942#c8
Sorry I commented on wrong bug report :-(
Attachment 5262 is obsolete: 0 => 1
CC: mageia => (none)
No problem. I'm glad our tools aren't so complicated that stage1 code influences drakx-net in an installed system ;-)
linuxero from QA just hit it with iso testing
Whiteboard: MGA4TOO, MGA3TOO, 5alpha1 => MGA4TOO, MGA3TOO, 5RCCC: (none) => mageia
Keywords: (none) => Triaged
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 :-)
CC: (none) => doktor5000
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)
If you want to test patched drakx-net, then please install the packages that you find here: http://waesvanm.home.xs4all.nl/Packaging/Bug13685/ After installing those packages and also after rebooting, the network works fine here, but I cannot test whether the packages fix this bug, because our "\x00" access point seems dead since ± last week.
Keywords: (none) => PATCH
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) => FIXEDStatus: 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) => reneStatus: 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 => NEEDINFOWhiteboard: 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.
Attachment 9207 mime type: application/x-pagemaker => text/plain
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)
Whiteboard: MGA5TOO => MGA5TOO, unrelated_comments_1-6_hidden
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 ...
Comment 1 is private: 1 => 0 Comment 2 is private: 1 => 0 Comment 3 is private: 1 => 0 Comment 4 is private: 1 => 0 Comment 5 is private: 1 => 0 Comment 6 is private: 1 => 0Whiteboard: MGA5TOO, unrelated_comments_1-6_hidden => MGA5TOO,
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 => RESOLVEDResolution: (none) => FIXED