Error with Network Browser Scan

[MrQuade]

For a little while now, I have been getting an error when attempting to perform a network scan using the WIz network browser function (prior to setting up a mount).

On a freshly rebooted U4, or V2, when I kick off the network scan, I get the following error:

I need to exit out of the browser, and restart my network interface, and once that completes, I can then return to the network browser and successfully scan the network.

Looking at /var/log/messages, I see this odd error on my U4 (but not on the V2).

Code: Select all

May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: irq_stat 0x40000000
May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: failed command: READ FPDMA QUEUED
May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: cmd 60/f0:c0:78:b0:da/01:00:8f:00:00/40 tag 24 ncq dma 253952 in
May 24 19:30:38 beyonwizu4 user.err kernel:          res 41/40:f0:78:b0:da/00:01:8f:00:00/00 Emask 0x409 (media error) <F>
May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: status: { DRDY ERR }
May 24 19:30:38 beyonwizu4 user.err kernel: ata1.00: error: { UNC }
May 24 19:30:38 beyonwizu4 user.info kernel: ata1.00: configured for UDMA/133
May 24 19:30:38 beyonwizu4 user.info kernel: sd 0:0:0:0: [sda] tag#24 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 24 19:30:38 beyonwizu4 user.info kernel: sd 0:0:0:0: [sda] tag#24 Sense Key : 0x3 [current]
May 24 19:30:38 beyonwizu4 user.info kernel: sd 0:0:0:0: [sda] tag#24 ASC=0x11 ASCQ=0x4
May 24 19:30:38 beyonwizu4 user.info kernel: sd 0:0:0:0: [sda] tag#24 CDB: opcode=0x28 28 00 8f da b0 78 00 01 f0 00
May 24 19:30:38 beyonwizu4 user.err kernel: blk_update_request: I/O error, dev sda, sector 2413473912
May 24 19:30:38 beyonwizu4 user.info kernel: ata1: EH complete

This looks to me like a HDD error, and not a network error, but this series of lines is logged continuously while the error window is displayed. When the error window is dismissed, those errors stop.
Not sure if that is a clue, or a red herring.


Anyone else seeing network browser scan errors after a reboot?

[peteru]

I need to exit out of the browser, and restart my network interface, and once that completes, I can then return to the network browser and successfully scan the network.

I have not noticed anything like that on a V2 (I don't have a U4 set up for testing at this point in time). Then again, I have not had the need to configure any new mounts on the V2 for a while.

Do you have more specific steps to reproduce? Does it require a clean USB flash of firmware to get this or is this something that happens after every reboot?

Not sure if that is a clue, or a red herring.

I think the HDD errors may be (mostly) unrelated. It looks like there are bad blocks on the HDD and something is trying to read that part of the disk. It's very likely that smartctl -x /dev/sda will show a few bad sectors. There are ways of dealing with those, but to be honest, if you start seeing such problems it's probably best to replace the HDD.

I've been running an old 1TB HDD (which every now and then throws a few bad blocks) for about 5 years now. It's been fine because it's on a RAID mirror and on the rare occasion where this happens the problem can be automatically repaired on the fly. However, I'd never consider using that drive in a system without redundancy.

[MrQuade]

Do you have more specific steps to reproduce? Does it require a clean USB flash of firmware to get this or is this something that happens after every reboot?

No additional steps required.

Straight after a normal reboot, if I look at my Network Interface status, I see this with all fields showing N/A.

I can access the V2 over the network with ftp, ssh, telnet, SMB, OpenWebIf etc, using its DNS name or its IP address.
The only thing that doesn't work is the network browser scan function.

Restarting the network fixes both the Network Information screen, and the network browser scan.

[MrQuade]

I think the HDD errors may be (mostly) unrelated. It looks like there are bad blocks on the HDD and something is trying to read that part of the disk. It's very likely that smartctl -x /dev/sda will show a few bad sectors. There are ways of dealing with those, but to be honest, if you start seeing such problems it's probably best to replace the HDD.

I've been running an old 1TB HDD (which every now and then throws a few bad blocks) for about 5 years now. It's been fine because it's on a RAID mirror and on the rare occasion where this happens the problem can be automatically repaired on the fly. However, I'd never consider using that drive in a system without redundancy.

Yea, It might be on its way out. Perhaps the timing was coincidental with the fresh reboot. It does look like it throws a burst of them after a fresh boot, and then stops.

I'll look into binning it.

That's the same Seagate shingled drive that I bought a couple of years ago to stress test. It hasn't really skipped a beat performance wise, but maybe it has just demonstrated reliability may not be all that.

[Paul_oz53]

Returning to your first post, I've seen that message when I try DHCP with a wireless adapter.

Manually setting the IP address, netmask and gateway makes the message go away.

Can't recall ever seeing it on an ethernet connection.

[peteru]

Restarting the network fixes both the Network Information screen, and the network browser scan.

What about restarting the GUI only, does that help?

[MrQuade]

What about restarting the GUI only, does that help?

Hmm, good thinking, that hadn't occurred to me!

And yes it does help. So it looks like it is just the GUI doesn't have the IP address information, but everything is otherwise working fine under the hood.

Maybe on reboot, it tries to retrieve the IP address information before DHCP has finished doing its job? (the Wiz units are all set to DHCP with a static lease set on my DHCP server)

For the record, I only noticed this happening prior to testing with prl's recent "Use as HDD" patches (but the problem isn't as a result of those patches). So perhaps there were odd changes in the boot sequence just before that time?

Or maybe something on my network's side is being delayed. I have recently changed over to Ubiquiti switches around the house, but I can't imagine how they might be interacting.

I had also re-shuffled the static leases on my DHCP server to make more logical sense, but again, I am struggling to think how that might be a problem too.

[peteru]

On a freshly rebooted U4, or V2, when I kick off the network scan, I get the following error:
...
I need to exit out of the browser, and restart my network interface, and once that completes, I can then return to the network browser and successfully scan the network.

I can not reproduce this.

However, I did notice that the default network config that ships in the package is completely inappropriate.

I'm about to push out a beta update that will:

• Include a more sane default network configuration.
• Show more information in the error message to (maybe) start making some guesses as to what is wrong.

I have a suspicion that you may have a really slow DHCP server and as a result the interface has not been assigned an IP and a netmask by the time the enigma2 code tries to collect that information.

[MrQuade]

I have a suspicion that you may have a really slow DHCP server and as a result the interface has not been assigned an IP and a netmask by the time the enigma2 code tries to collect that information.

How slow is slow?
The T3 doesn't seem to suffer the problem, but it would be significantly slower to start the enigma2 process than the U4 or V2, so it might be marginal.

This issue has only been apparent in the last couple of months....but as I mentioned, one or two changes had been made within my network (including router upgrades which is currently serving the DCHP requests).

Running an "ipconfig /renew" from Windows 10 results in a return to the command prompt within roughly 5s.

One of my CentOS VMs reports DCHP renewal in 3.3s.

[peteru]

That is very slow. On my network, the entire DHCP discover, offer, request, ack process takes less than a second.

[MrQuade]

Installed latest beta update, and the resulting error message is as expected.

1_0_16_683_607_1014_EEEE0000_0_0_0_20210603213416.jpg (88.73 KiB) Viewed 3299 times

[MrQuade]

I have thrown the query out onto the Asus "Merlin" forums for some feedback.

My router is a pretty capable unit, and isn't under much load, so I don't know why it may be taking overly long to renew addresses.

It has a table of 42 MACs with manual IP assignments. Possibly excessive for a simple home network, but not out of the ordinary in the scheme of things.

[peteru]

The router config does not sound unreasonable in terms of assigned MAC size. I have over 80 entries. About half of those are for devices that are mostly retired.

Your router is probably running dnsmasq. Try the dhcp-authoritative option in the dnsmasq.conf file.

[MrQuade]

Your router is probably running dnsmasq. Try the dhcp-authoritative option in the dnsmasq.conf file.

That one is already enabled by default.

I'll keep digging.

[peteru]

If you want to, I can take a look at your dnsmasq configuration file and see if anything obvious jumps out. You can send it to me in a private message if you prefer.

[MrQuade]

So it is looking like this is normal and expected behaviour for the dnsmasq in use on my router.

DHCP performs a ping test prior to issuing an address, and the timeout is hard-coded to 3s it seems.
https://github.com/RMerl/asuswrt-merlin ... nfig.h#L38

I thought I read somewhere that if a host has an IP defined by its MAC, then the ping test doesn't get executed.....though I can't find reference to that again now. After all, what does it do if the pre-defined IP is already in use....just not issue the address, or simply give out another one from the pool?

Anyway, it looks like it is indeed waiting 3s despite me providing a fixed address via MAC.

I could try using the no-ping option, but that sounds like it could cause more problems (much like I had with my old Billion router which would often give out duplicate addresses to mobile equipment).

[peteru]

Definitely turn off the ping test. You only need the ping test if you have another (rogue) DHCP server on the same network, have statically assigned IP addresses in the DHCP range, or your router is so flaky it regularly loses track of allocated addresses. All of the above reasons are issues that need to be resolved properly, rather than mitigated using a ping test.

Also, be aware that IP allocation in dnsmasq is a bit more intelligent than the monotonically increasing algorithm used in Billion routers. The IPs are assigned based on the hash of the MAC address, so they are mostly predictable and consistent. In cases where hash collisions occur, you are still unlikely to see issues if your router has reasonable uptime and has kept track of assigned IPs. If you are rebooting your router daily or weekly and loosing track of assigned IPs, you have a router problem and need to replace the router with something that can have uptime that's measured in years, not hours.

BTW: We had a scheduled power outage recently (cabling between house and pole was being pre-emptively replaced by Ausgrid) and before shutting down the router I checked the uptime. It was a few days over 2 years and 8 months.

[MrQuade]

Hmmmmmmmmmm.

Ok, so some further digging, and dnsmasq does indeed not perform a ping for manually defined addresses.

And on looking at my client logs a wee bit closer, the request and ACK are happening in less than a second. I had been looking at the wrong line, and reading it incorrectly. I thought it was saying renewal took 3500ms (or so), but it was instead telling me when the lease was to be renewed in SECONDS.



Anyway. It looks like I am actually getting addresses back within a second, which should be well quick enough to happen before enigma2 starts.

At least I have learned a little more about dnsmasq in the meantime...

[peteru]

Interesting. So the original problem may not be caused by slow DHCP. I have not managed to reproduce this condition.

Do you happen to be in a position to capture serial debug output when this happens?

[MrQuade]

Do you happen to be in a position to capture serial debug output when this happens?

I don't have one of the serial interface adaptors required to connect to the U4 motherboard unfortunately.
I only have the standard off the shelf RS232 gear for talking to the T series.

[peteru]

I've been trying to reproduce this with a V2, not a U4.

The V2 has a 3.5mm serial port socket that will work with a standard 5V TTL serial adaptor.

Tip = TX
Ring = RX
Sleeve = GND

It's a bit simpler than the U4, where you need to open up the unit to add a serial adaptor.

[MrQuade]

The V2 has a 3.5mm serial port socket that will work with a standard 5V TTL serial adaptor.

Hmm, a few options there, but the simplest option might be to just grab part from RS
https://au.rs-online.com/web/p/developm ... s/6877774/

I can reproduce the error on the V2, so that should work.

Save me soldering something, or having to open up boxes.
There are cheaper alternatives on Amazon, but US, meaning delivery delays, and a variety of Altronics/Jayjar USB/Serial ones that would need some degree of buggering about with.


Before that, I might see if I can move the V2 to a different switch and see if it still plays up.

[peteru]

That RS part looks about right, but it is pricey. I use a PL2303 based cable, but it's pretty much the same thing.

When you factor in delivery, you are looking at around $50 and there are no guarantees that the captured output will get us anywhere.

The main reason to go with the serial debug output is that it includes all the logs (kernel, boot scripts and enigma2) in chronological sequence. It may be easier to spot a timing issue with the single log, but it may also not show anything new or obvious.

[MrQuade]

I caved and ended up getting a cheaper Altronics one and some audio plugs....my thriftiness outpaced my laziness.
https://www.altronics.com.au/p/z6522a-f ... rial-lead/

A shame it is a 5V one since this one would be more easily physically modified to suit the U4.

[Paul_oz53]

I don't want to hijack the discussion but when I ran the network browser scan on the Lounge U4 it simply worked as expected up to a point. Just checking if I could reproduce the initial problem but I couldn't.

It produced the list of shares which were: the router, four Wizzes and two PCs. When I expand each the expected list of available shares appears with the green tick or red cross correctly displayed against each shared folder as appropriate.

However, in the case of the Lounge U4, the pop-up dialog for username and password appears only for the T4. It puzzles me why it only appears for the T4. On the Study U4 the pop-up appears for all of the other three Wizzes.

It takes a long time (seems around 20 to 30 seconds) to expand but it is otherwise perfectly valid whenever the pop-up is triggered on either U4. Even the Windows shares which have passwords do not trigger the pop-up on the Lounge U4.

As the setup of the shares in mount manager are identical for the other Wizzes, it puzzles me what triggers the pop-up. In particular, why for most shares but not some on the Lounge U4.

[Grumpy_Geoff]

However, ...

I had a wry smile after reading that - you and Wiz networking haven't been the best of friends.

[prl]

However, in the case of the Lounge U4, the pop-up dialog for username and password appears only for the T4. It puzzles me why it only appears for the T4. On the Study U4 the pop-up appears for all of the other three Wizzes.

The popup will only appear if there is no username/password set for the server. It's possible that you've set username/password pairs on the U4 for all the other boxes except the T4. The username/password pairs are quite "sticky".

I have fixes in in preparation that will only ask for a username/password in circumstances where it makes sense - e.g. if a server only offers NFS shares, a username/password won't be asked for for that server.

[Paul_oz53]

However, ...

I had a wry smile after reading that - you and Wiz networking haven't been the best of friends.

Your capacity for understatement is truly a gift


But seriously, it does my head in why two identical machines behave differently when accessing the same shares.

[Paul_oz53]

...
The popup will only appear if there is no username/password set for the server. It's possible that you've set username/password pairs on the U4 for all the other boxes except the T4. The username/password pairs are quite "sticky".

Thanks Peter but, if the T3 is a server, where would I set the username and password for external access?

And, if I did set a username and password wouldn't both U4s not pop-up? (Sorry for the double negative.)

The system is working fine regardless of the quirks above and with FSTAB vs AUTOFS so it's more an academic question but as I said earlier, it's doing my head in trying to figure out why it's misbehaving. Not so long ago it all worked.

[Grumpy_Geoff]

The system is working fine regardless of the quirks above and with FSTAB vs AUTOFS so it's more an academic question but as I said earlier, it's doing my head in trying to figure out why it's misbehaving. Not so long ago it all worked.

I don't have an answer, other than I'm thinking some mount "stuff" is cached "somewhere", because I don't have the below mount defined for example -

Code: Select all

Jan  5 22:25:01 beyonwizu4 daemon.info automount[734]: key "NAS2" not found in map source(s).
Jan  5 22:25:04 beyonwizu4 daemon.info automount[734]: rmdir_path: lstat of /media/autofs/NAS2 failed

At one point in time, I renamed "NAS" to "NAS2", but then changed it back some weeks later and that was long ago.
[ignore the timestamp, this is from today's boot]

[Grumpy_Geoff]

I don't have an answer, other than I'm thinking some mount "stuff" is cached "somewhere", because I don't have the below mount defined for example -

Code: Select all

Jan  5 22:25:01 beyonwizu4 daemon.info automount[734]: key "NAS2" not found in map source(s).
Jan  5 22:25:04 beyonwizu4 daemon.info automount[734]: rmdir_path: lstat of /media/autofs/NAS2 failed

At one point in time, I renamed "NAS" to "NAS2", but then changed it back some weeks later and that was long ago.
[ignore the timestamp, this is from today's boot]

Okay, that name appears in the bookmarks but it isn't shown in the GUI - it appears in setting config.movielist.videodirs.
I shutdown the GUI, edited the setting via command line and it's no longer reported at startup.
The value is also present in the resume points file (resumepoints.pkl) but it doesn't cause "automount" to report the entry.

I do however still get entries for -

Code: Select all

Jun 13 14:23:29 beyonwizu4 daemon.info automount[735]: key "T2_Movie" not found in map source(s).
Jun 13 14:23:30 beyonwizu4 daemon.info automount[735]: key "logs" not found in map source(s).

T2_Movie is an inactive share in automounts.xml, whilst I've no idea where "logs" is defined.

[MrQuade]

I don't like the way that bookmarks are simply hidden in the GUI if the destination is not available.

Makes it a bit hard to delete dead ones of you can't see them.

It also makes the location popup populate in an unpredictable way.

[prl]

...
The popup will only appear if there is no username/password set for the server. It's possible that you've set username/password pairs on the U4 for all the other boxes except the T4. The username/password pairs are quite "sticky".

Thanks Peter but, if the T3 is a server, where would I set the username and password for external access?

And, if I did set a username and password wouldn't both U4s not pop-up? (Sorry for the double negative.)

The current setup for the username/password credentials is that they are asked for on the client if they haven't been set on the client, whether the server requires them or not. The Beyonwiz Samba servers don't require a password by default, though PC and NAS servers often do.

[Grumpy_Geoff]

And, if I did set a username and password wouldn't both U4s not pop-up? (Sorry for the double negative.)

I think the username & password are stored in the {server}.cache files in /etc/enigma2 directory so you can check there.

[prl]

And, if I did set a username and password wouldn't both U4s not pop-up? (Sorry for the double negative.)

I think the username & password are stored in the {server}.cache files in /etc/enigma2 directory so you can check there.

That is correct, where {server} is the server IP address used in the client share mount setup. It is safe to delete these files if you're not in the NetworkBrowser plugin screens. Deleting the file (or renaming it) will force NetworkBrowser to ask for the credentials the next time the server is expanded in the scan list or a setup screen for a share on the server is opened.

[Paul_oz53]

And, if I did set a username and password wouldn't both U4s not pop-up? (Sorry for the double negative.)

I think the username & password are stored in the {server}.cache files in /etc/enigma2 directory so you can check there.

That is correct, where {server} is the server IP address used in the client share mount setup. It is safe to delete these files if you're not in the NetworkBrowser plugin screens. Deleting the file (or renaming it) will force NetworkBrowser to ask for the credentials the next time the server is expanded in the scan list or a setup screen for a share on the server is opened.

Thanks guys.

The lounge U4 has the set of (server).cache files whereas the study U4 has none. Both have the Networkbrowser.cache file which are consistent with each other and contain the fullset of shares machine IPs. Each machine has its own entry last. Each entry appears twice, presumably account then password. (The text is unreadable apart from the IP addresses.)

Of relevance, the lounge U4 does not have the T4 cache file. So this explains why the Lounge doesn't pop-up for shares other than the T4.

[peteru]

I do however still get entries for -

Code: Select all

Jun 13 14:23:29 beyonwizu4 daemon.info automount[735]: key "T2_Movie" not found in map source(s).
Jun 13 14:23:30 beyonwizu4 daemon.info automount[735]: key "logs" not found in map source(s).

T2_Movie is an inactive share in automounts.xml, whilst I've no idea where "logs" is defined.

Those log entries are from the automounter daemon. It does not care about the XML file at all. The automounter will only use /etc/auto* files for it's configuration, unless you have changed the defaults in /etc/nsswitch.conf. I used to have a setup where the automounter maps came from a NIS server so that the config was available on all networked machines, but that's a fairly advanced setup that is beyond most home users.

[Grumpy_Geoff]

I do however still get entries for -

Code: Select all

Jun 13 14:23:29 beyonwizu4 daemon.info automount[735]: key "T2_Movie" not found in map source(s).
Jun 13 14:23:30 beyonwizu4 daemon.info automount[735]: key "logs" not found in map source(s).

T2_Movie is an inactive share in automounts.xml, whilst I've no idea where "logs" is defined.

Those log entries are from the automounter daemon. It does not care about the XML file at all. The automounter will only use /etc/auto* files for it's configuration, unless you have changed the defaults in /etc/nsswitch.conf. I used to have a setup where the automounter maps came from a NIS server so that the config was available on all networked machines, but that's a fairly advanced setup that is beyond most home users.

They're not from /etc/enigma2/auto.network. That file contains only active mount definitions.
The T2_Movie mount is an inactive definition in /etc/enigma2/automounts.xml. It wasn't bookmarked neither.
After I deleted the inactive mount definition for T2_Movie and rebooted, it was no longer reported in the messages file. The automounter daemon must process the automounts.xml in some way.

The "logs" entry is from a source unknown to me.
I'd be interested to know if anyone else has it reported -

Code: Select all

root@beyonwizu4:~# grep automount /var/log/messages
Jun 14 13:36:31 beyonwizu4 daemon.info automount[738]: key "logs" not found in map source(s).
root@beyonwizu4:~#

[peteru]

What I'm trying to say is that automounter never ever looks at the XML file. The messages you are seeing are due to some other process trying to access an automounted directory that is not defined. For example:

Code: Select all

root@devv2:~# ls /media/autofs/logs ; tail -1 /var/log/messages
ls: /media/autofs/logs: No such file or directory
Jun 14 16:48:16 devv2 daemon.info automount[1910]: key "logs" not found in map source(s).

Getting rid of those messages in the logs would either require adding the missing entries to the automounter maps or identifying the process that is attempting to access those paths and then taking appropriate action to stop it from doing so. In this case, the other process is almost certainly enigma2.

[adoxa]

The "logs" entry is coming from LogManager, which checks all mounts for a logs directory.

[Grumpy_Geoff]

The "logs" entry is coming from LogManager, which checks all mounts for a logs directory.

I was just about to post this when I saw your reply -
The "logs" lookup may come from LogManager (when probing folders).
I disabled debug logging and restarted and no entry for "logs" appeared.

[Grumpy_Geoff]

I think the "something in enigma2" that is attempting to access an inactive mount entry is OpenWebif (I'm guessing to list the shares under the "Network Shares" banner on the Box Info page).

[Paul_oz53]

Apologies if this is off-topic.

I have noticed the network mounts on the U4 which are of the type "fstab" work but the media player screen reports the host disc size as 66kB and the available space also as 66kB. The "autofs" variant reports correct values in GB ranges corresponding to the installed disc. Not causing any practical issues though.