Unable to open mounted network drives

[bruceb]

I have three Beyonwiz receivers a T4 and two V2s. For some years I have had the recording drives on these receivers networked but after a recent modem reset I get "directory does not exist" errors when attempting to open drives that have (supposably) been successfully mounted using the network menu. I can open my NAS drives but not those on other receivers. I can open these receiver drives through my network PC, so I can be sure of the correct IP addresses and they are the same as those that appear in the Network Interface field for each receiver. I have done network resets and rebooted the receivers and the modem several times - but the problem persists. All the receivers have had the most recent firmware upgrade so maybe that is the problem because it all worked prior to the upgrade

Assistance appreciated.

Bruce

[MrQuade]

All the receivers have had the most recent firmware upgrade so maybe that is the problem because it all worked prior to the upgrade

But they also worked after the upgrade too I am assuming?

I can open these receiver drives through my network PC, so I can be sure of the correct IP addresses and they are the same as those that appear in the Network Interface field for each receiver.

So you are accessing the Wizs from the PC via IP address (eg. \\192.168.x.x\movie)?

The first thing that springs to mind after a router reboot is that the IP addresses changed since the DHCP leases would have expired, but if you can absolutely confirm that those addresses are still correct, then that's ruled out (the mounts use IP addresses, and not network names).


Can you confirm that the shares are not working from T4 to V2, and V2, to V2, and V2 to T4? The SMB versions on both boxes are different, so mount direction can matter.

Some people seem to have more luck using fstab style mounts instead of autofs mounts. I don't know why this would make any difference, and I have never had trouble with autofs mounts.

If you do want to change a mount type, you should delete the old mount, and recreate it. You should not change the mount type and save over an old definition, as doing so can cause problems.

The SMB versions can make a difference, though between a T4 and a V2, the 'default' setting should work fine too.

Can you post a screenshot of the mount configuration screen as it is at the moment.

[bruceb]

Thank you

The networking continued as normal after the upgrade it was only when I had a recent power cut to the modem which forced a reboot and a reallocation of IP addresses. In the past all I had to do was restart the networking on my receivers and confirm any change to the IP address. I would then delete all previous mounts and scan the the network and mount the new drives and would be able to access the the drives on my receivers in my recordings menu. Now I seem to get successful mounts of the drives but "directory does not exist" errors when I attempt to access the drives in the recordings menu. Yes I can access the Wizs on my PC from the IP addresses as listed in my modems LAN settings. It doesn't seem to to matter which direction I try to access the shares eg T4 to V2 , V2 to V2 or v2 to V1 none of them work

Not sure what the mount configuration screen is.

Regards

Bruce

[sub3R]

Bruce, I get a similar situation when I get a 240V power outage & one or more of my U4s are either on or in standby at the time. With my situation something happened a few years ago that caused this server/client issue after power outages (prior to this it never happened). I can guarantee if I get a 240V power outage the U4 that is either on or in standby will need to have a USB f/w reflash with restore settings so the other U4 (the client U4) can access the recordings on that U4 (the server U4) over the LAN. This happens even though the IP addresses haven’t changed *anywhere* (including on the router) & access to/from my PC to/from either U4 over the LAN works perfectly.

In fact I just had to USB f/w reflash both U4s today after a short power outage so they could access each others recordings over the LAN (both U4s were either on or in standby at the time & both came up with the dreaded ‘directory does not exist’ error when trying to access the other U4 over the LAN after the outage). This is the first time I’ve had to do both, usually one or the other is in deep standby.

If MrQuade or anyone else can’t help with other suggestions, I suggest as a last resort USB f/w reflashing the server wiz (the one you are trying to access over the LAN from the client wiz) with restore settings to see if the client wiz can then see the recordings on the server wiz. If that works you may need to USB f/w reflash with restore settings the other wizzes to get the server/client working on those if they were on or in standby at the time of the power outage.

[Blot]

Have you tried using a static ip? Just pick a number outside your modems dhcp pool. Like if your pool is 192.168.1.100-192.168.1.200 use 192.168.1.99 for the first Beyonwiz and 192.168.1.98 for the second 192.168.1.97….

[MrQuade]

Have you tried using a static ip? Just pick a number outside your modems dhcp pool. Like if your pool is 192.168.1.100-192.168.1.200 use 192.168.1.99 for the first Beyonwiz and 192.168.1.98 for the second 192.168.1.97….

Even better, if your router supports it (and most do), then assigning a static IP via a DHCP reservation in the router will give you the dual benefit of having that fixed IP address, as well as allowing the router to link that address to its own DNS server, so your network's name resolution works properly.


So what I am hearing here, is that yes, the IP addresses changed, and that deleting and re-creating the mounts via the network browser interface has not properly restored those mounts.

This suggests to me that there are possibly some old settings hanging around behind the scenes that aren't visible in the user interface. (I am still keen to see a screenshot of the mount definition if possible though).
My suggestion would be to delete the mounts entirely, and then reboot.
Then re-create the mount via the network browser interface.
My suggestion here would be to make sure that when the mount has been created, and the "success" popup is visible, that you press the OK button to dismiss the popup, and not the EXIT button. Pressing EXIT, *used* to be a problem, and the mount creation would only be partially completed. prl put some love and attention into this part of the user interface, and fixed this up, but I think it is still worth trying the old fix of making sure you press "OK" just for good measure.

[bruceb]

Thank you for all these helpful suggestions. Fortunately changing to FSTABS style mounts solved the problem (but I will look into using a static IP). This must be something new with the latest firmware as AUTOFS has always worked in the past.

Regards

Bruce

[MrQuade]

Thank you for all these helpful suggestions. Fortunately changing to FSTABS style mounts solved the problem (but I will look into using a static IP). This must be something new with the latest firmware as AUTOFS has always worked in the past.

The problem with fstab is that if the mount location is not available when the Wiz boots up, then the mount will fail, and will never try to connect again even when the mount location becomes available (until you reboot again). fstab is boot connect only, whereas Autofs will connect when required.

[Blot]

I changed my network address today and now no matter what I do I can not seem to get any files/folders in the mount on my v2. It sets up ok, sometimes it is there and does not have anything in it and sometimes it is not there at all (seemingly random as I remove reboot add remove add edit disable enable in all sorts of combos).

I changed my network to 192.168.1.x from 192.168.8.x and set up reservations (my router is buggy and only allows you to set up reservations when it is 192.168.1.1, so I thought it would be a good idea to change my whole network). It is no longer static anymore as the reservations allow dhcp. I will try static with reservations.

It seems though that the Beyonwiz remembers something incorrectly about the old address and never sets up a new one properly.

[Blot]

Never mind. I forget to change the qnap nfs mask from 192.168.8.0/24 to 192.168.1.0/24

After I changed it and rebooted the qnap and the v2. It took a while for the files to show.

[MrQuade]

Never mind. I forget to change the qnap nfs mask from 192.168.8.0/24 to 192.168.1.0/24

Just "subnet". The mask is just the "/24" part, and NFS means something different (it's like a filter storage sharing protocol).

Good job getting your mounts working anyhoo .

[Blot]

Thanks. I see now the were not using nfs.

It’s the sagemcom modem that only likes 192.168.1.1
Just in case someone is googling it. “Operation could not complete. Something wrong happened”. I googled the same error for a completely different model so maybe it is common. Such a great error message, lol.

Safer to change it back to 192.168.1.1 just in case more stuff is hard coded.

[Paul_oz53]

Thank you for all these helpful suggestions. Fortunately changing to FSTABS style mounts solved the problem (but I will look into using a static IP). This must be something new with the latest firmware as AUTOFS has always worked in the past.

Regards

Bruce

I too have had problems with AUTOFS in the 19.3 firmware and rely on FSTAB mounts between the T4 and U4s but AUTOFS is fine with the T3 and Windows.

You will be well served to install the fstab-editor plugin via the Plugins >> Download plugins dialogue. FSTAB mounts can become duplicated if edited so you will need this for housekeeping and sometimes for reloading a mount that has become inactive. Mount manager does not delete these mounts and old versions can become hidden if edited.

[sub3R]

I too have had problems with AUTOFS in the 19.3 firmware and rely on FSTAB mounts between the T4 and U4s but AUTOFS is fine with the T3 and Windows.

It was about the time of beta f/w 19.3 20200919 when I started to get server/client issues after a 240V power outage (using AUTOFS on an Ethernet LAN). But I don’t know if I had any power outages with the two previous beta 19.3 f/w versions, so the issue could have started during that time period. I had no server/client issues at all running 17.5 series f/w after a power outage. I can’t say for certain that f/w is the cause, only that it was about that time when those issues started for me.

In the router/modem I use reserved IP addresses at the top of the reserved address range based on MAC addresses, but I’ve never done a clean install of 19.3 series f/w - always restore settings. Sometimes I wonder if a clean f/w install on both U4s would resolve these issues.

Good tip about the fstab-editor plugin.

[Paul_oz53]

...

In the router/modem I use reserved IP addresses at the top of the reserved address range based on MAC addresses, but I’ve never done a clean install of 19.3 series f/w - always restore settings. Sometimes I wonder if a clean f/w install on both U4s would resolve these issues.

Good tip about the fstab-editor plugin.

Hi Dennis,

I too use reserved IP addresses based on MAC addresses but I have tried clean installs with exactly the same problem with AUTOFS mounts. So no, I don't think a clean install will help.

I agree that AUTOFS used to be fine until around the time of 19.3 20200919. What puzzles me is that only some of us have a problem. I note that at one point Grumpy_Geoff mused the problems may have something to do with ARM vs MIPs processors but I've had problems with both types of machines.

My suspicion is that maybe it's the router that's the weak link. Mine is a TPG supplied thing that reports as an Archer 1600v. Seviceable but unremarkable.

We're moving in 4 weeks so I'll have to setup everything again. I may buy a new router to improve WiFi reception. (Suggestions welcome MrQuade / Grumpy_Geoff / prl / others with working AUTOFS.)

The new place has the NBN connection at the opposite end of the house and is not wired for ethernet but I plan on changing that eventually.

[sub3R]

I too use reserved IP addresses based on MAC addresses but I have tried clean installs with exactly the same problem with AUTOFS mounts. So no, I don't think a clean install will help.

Well that rules out one suspicion I had & saved me a bit of time. Thanks for that info.

I have suspected my router (a Telstra suppled Technicolor DJA0230TLS modem/router) but I had no server/client issues when I was running that router & 17.5 series f/w.

In my case I don’t think it’s an IP address screw-up that happens after a power outage because access to/from my PC to/from either U4 over the LAN still works perfectly & the IP addresses everywhere are still correct. It seems like an outage corrupts something in the U4 that is either on or in standby at the time & only a USB re-flash with restore settings will fix it.

My system is pretty basic; modem/router Ethernet to a TP-Link TP-SG108 switch (No.1) in the study (the PC connects to this). Ethernet from switch No.1 to a TP-Link TP-SG108 switch (No.2) in the lounge room where one U4 is connected to. And Ethernet from switch No.1 to a TP-Link TP-SG105 switch (No.3) in the Living room where the second U4 is connected to. Other devices are also connected to those 3 switches. No wireless involved.

Good luck with the move. I would be interested if the new setup fixes anything, especially if you get another router.

[Paul_oz53]

Everything you said mirrors my experience. And your network configuration is close to mine except for the T4 in the kitchen not having a switch.

As you say, not a problem on 17.5 with the same hardware. The router definitely seems the possible point of difference.

[Grumpy_Geoff]

The router definitely seems the possible point of difference.

I use an ASUS router as does MrQuade.
I had the issue for a while, then it went away. To my recollection, MrQuade has not had the issue.

What puzzles me is that only some of us have a problem. I note that at one point Grumpy_Geoff mused the problems may have something to do with ARM vs MIPs processors but I've had problems with both types of machines.

I did say that in a post to dRrdoS7 -
"In my testing of a T2, T4, and U4, the MIPS boxes using AUTOFS mounts can't get to shares from the ARM box, whereas they can if they change to using FSTAB mounts.
The ARM box can get to the MIPS boxes' shares using AUTOFS mounts.

Your experience seems to change this to - MIPS/ARM boxes using AUTOFS mounts can't get to shares from ARM boxes, whereas they can if they change to using FSTAB mounts."
(here)

[Grumpy_Geoff]

We're moving in 4 weeks so I'll have to setup everything again. I may buy a new router to improve WiFi reception. (Suggestions welcome MrQuade / Grumpy_Geoff / prl / others with working AUTOFS.)

The new place has the NBN connection at the opposite end of the house and is not wired for ethernet but I plan on changing that eventually.

What NBN access type is in use at the new premises?
Do you use VoIP with TPG?

[MrQuade]

I had the issue for a while, then it went away. To my recollection, MrQuade has not had the issue.

I've not been able to reproduce the fault.
I would love to see it in action so that I could debug it though!!

Suggestions welcome MrQuade / Grumpy_Geoff / prl / others with working AUTOFS

It would be interesting to work out if the router/DHCP/DNS server had anything to do with the issue, that's for sure.

The Asus RT series are generally good for WiFi coverage, but you may also want to look into a suite of products that offer meshing capability. The Asus products can do that as well, but it is more of an "also" feature.

I use the older RT-AC86U router, which is generally regarded as being stable and reasonably powerful.
Of the newer range, the equivalent RT-AX86U would be my recommendation without spending a fortune.

I am slowly swapping out all of my network equipment for Ubiquiti Unifi brand gear. More for poser points than anything really, but I wanted to switch all of my WiFi equipment over to their products to make central management easier. I will eventually retire my Asus router for a Ubiquiti UDM-Pro (or equivalent) when I am feeling rich, or when NBN Corp graces me with a FTTP connection.

All my Wiz units are hard-wired anyway, so the WiFi doesn't factor in to my network connections.

[Paul_oz53]

We're moving in 4 weeks so I'll have to setup everything again. I may buy a new router to improve WiFi reception. (Suggestions welcome MrQuade / Grumpy_Geoff / prl / others with working AUTOFS.)

The new place has the NBN connection at the opposite end of the house and is not wired for ethernet but I plan on changing that eventually.

What NBN access type is in use at the new premises?
Do you use VoIP with TPG?

Easy questions first while between calls: Not absolutely sure but there is an NBN box on the wall in the garage with ethernet out to the current owner's router. The underground connection is possibly fibre or fibre to the kerb but couldn't rule out cable.

We don't use VOIP - mobiles have been sufficient for us.

[Grumpy_Geoff]

Easy questions first while between calls: Not absolutely sure but there is an NBN box on the wall in the garage with ethernet out to the current owner's router. The underground connection is possibly fibre or fibre to the kerb but couldn't rule out cable.

Let's get the definitive answer. Plug your address in here -
https://www.nbnco.com.au/connect-home-o ... ur-address

What does it return for "Technology used in your connection"?

It doesn't sound like FTTP if there's a single box on the garage wall and no corresponding box inside.
It doesn't sound like FTTC as a copper lead-in from the kerb goes to an internal wall socket, connecting to an NBN-supplied VDSL2 modem (white/cream).
It's possibly HFC, but there will be an internal NBN-supplied Arris modem (black).

[Paul_oz53]

...

Suggestions welcome MrQuade / Grumpy_Geoff / prl / others with working AUTOFS

It would be interesting to work out if the router/DHCP/DNS server had anything to do with the issue, that's for sure.

Indeed it would - could be that cheap, telco-supplied routers are the real culprit.

The Asus RT series are generally good for WiFi coverage, but you may also want to look into a suite of products that offer meshing capability. The Asus products can do that as well, but it is more of an "also" feature.

We're unlikely to need mesh capabilities as we will have two living areas needing coverage at opposite ends of the house. The router will be near the front. I was thinking of adding a WiFi access point at the rear if necessary since that will be our main living area.

I use the older RT-AC86U router, which is generally regarded as being stable and reasonably powerful.
Of the newer range, the equivalent RT-AX86U would be my recommendation without spending a fortune.

I was thinking of buying something that's known to work.

I am slowly swapping out all of my network equipment for Ubiquiti Unifi brand gear. More for poser points than anything really, but I wanted to switch all of my WiFi equipment over to their products to make central management easier. I will eventually retire my Asus router for a Ubiquiti UDM-Pro (or equivalent) when I am feeling rich, or when NBN Corp graces me with a FTTP connection.

If that's likely in the coming weeks I'd be happy to buy the ASUS. Not in a mad rush.

All my Wiz units are hard-wired anyway, so the WiFi doesn't factor in to my network connections.

That's my intention too but I expect to have fewer viewing points.

[MrQuade]

We're unlikely to need mesh capabilities as we will have two living areas needing coverage at opposite ends of the house. The router will be near the front. I was thinking of adding a WiFi access point at the rear if necessary since that will be our main living area.

Mesh systems aren't much more than extra WiFi access points that can use a (mostly config free) wireless backhaul to your main router. If you are interested in extending wireless coverage to other areas of the house without in-wall cabling, then a mesh system is the type of solution that you want.
Ideally you would buy into a system that will be able to utilise a wired backhaul later on when you have had a chance to install the fixed wiring.

If that's likely in the coming weeks I'd be happy to buy the ASUS. Not in a mad rush.

Unlikely at this stage. It is sounding like a 2023 upgrade to me.

I was thinking of buying something that's known to work.

As far as Asus is concerned, it is a bit of a minefield as to which model router to use. Despite them using a common firmware platform, and having similar model numbers, there are subtle but important differences in both the SOC and wireless chipsets used in each.

I recommended the AC86U as I had direct experience with it, and from user feedback, it is a very solid router with few gochas. The RT-AC88U on the other hand, despite seeming to be the upgraded model, actually uses an older chipset and has significant problems with its WiFi and has a slower CPU.
The RT-AX86U has newer WiFi standards, but does suffer from one or two teething problems being that it is newer and the drivers don't seem to be as mature. I have been recently reading about some minor QoS and NAT acceleration bugs as well. Any minor problems here would hopefully be solvable in firmware.
The RT-AX88U is similar to the AC88U model in that it is riddled with problems.

The big AX triple-band routers seem to be decent options, but boy they cost a lot.

I honestly haven't done a lot of deep diving on alternative brands (other than Ubiquiti), as I have not ever had a need to look elsewhere. Others may have some opinions on Netgear, Linksys, TPLink, or even one of the ISP white box alternatives (The Telstra Technicolour-made routers are great performers for example, but are a bit more locked down).

[Gully]

We're unlikely to need mesh capabilities as we will have two living areas needing coverage at opposite ends of the house. The router will be near the front. I was thinking of adding a WiFi access point at the rear if necessary since that will be our main living area.

Mesh systems aren't much more than extra WiFi access points that can use a (mostly config free) wireless backhaul to your main router. If you are interested in extending wireless coverage to other areas of the house without in-wall cabling, then a mesh system is the type of solution that you want.
Ideally you would buy into a system that will be able to utilise a wired backhaul later on when you have had a chance to install the fixed wiring.

Netgear Orbi are great that way as you can set them up either with wireless or wired backhaul, the latter as you say is preferable. I have been very happy with mine as have a few mates with their set ups as well both wired and wireless backhaul between the units.

[Paul_oz53]

Thanks MrQuade & Gully,

I plan on getting the place wired up as an early priority so mesh WiFi is a low priority. Gully's Orbi solution may get a guernsey if I have any gaps.

[Paul_oz53]

Hi guys,

Time for an update on the new place network configuration.

Moved in in August and had hard points installed in both studies and the rear of the house. Router in garage at front connected to the NBN FTH point.

WiFi coverage only covered the front so we have a TP-Link RE 405 configured as an access point in the rear. Works fine. The rear U4, Foxtel and TV are ethernet connected via a switch. All work well.

In my study is a switch serving two PCs and the T4. My work laptop only works properly when connected by WiFi, not ethernet. Apparently, a work VPN conflict which locks me out of our secure systems.

In the other study, the PC is directly connected to ethernet. Lastly, the front U4 is directly connected to the router through the wall. The TV and Denon connect via WiFi.

A few weeks back the modem died so I bought an ASUS AC86U secondhand. A bit tedious to setup but it's now working fine, both wired and wirelessly.

So I thought I would try configuring the U4s and T4 to use AUTOFS in the hope that changing the router would fix my problem of AUTOFS not working. Long story short, no change. No matter what I tried, no improvement. It all works using FSTAB but not AUTOFS.

The only other component that might explain the problem with AUTOFS is the switches. Since it's working there's no immediate need to swap them out.

TLDR: Changing the router did not fix my AUTOFS not working issue. Maybe it's the switches.

[peteru]

It's extremely unlikely that a switch would cause that kind of change in behaviour. Switches work at low layers of the networking protocol and have very standardised behaviour. Even the cheapest switches do the right thing. If they didn't most things would break.

Look for the source of problems elsewhere.

[sub3R]

Time for an update on the new place network configuration.
...
Long story short, no change. No matter what I tried, no improvement. It all works using FSTAB but not AUTOFS.
...
The only other component that might explain the problem with AUTOFS is the switches.

That’s disappointing. I have been wondering how your setup was going after you moved.

My issue is a bit different to yours, but I’m still having the same U4 server/client issues where the client U4 stops seeing the server U4’s recordings folder after a power outage. A USB firmware re-install on the server U4 being the only fix for this. It’s as if something gets corrupted in whichever U4 is on at the time. The client U4 not seeing the server U4’s recordings folder is the only thing that stops working after a power outage.

I did have the reserved IP addresses for both U4s quite high in the reserved DHCP address list, but after installing a Wi-Fi Extender to cater for a new security camera I noticed the Wi-Fi Extender was consistently being allocated a higher DHCP IP address than both U4s. All other devices have always been allocated DHCP IP addresses very low in the DHCP address list, but not this Wi-Fi Extender.

After observing that, I reserved the IP addresses for both U4s at the two highest addresses in the DHCP address list.

I’ll see what happens after the next power outage but I doubt allocating the higher addresses will fix the server/client issue because neither U4 loses its IP address as confirmed by my PC.

I’m using three unmanaged switches on my LAN setup (one TP-Link TP-SG108 v1.3 at the router, one TP-Link TP-SG108 V3 at one U4 & one TP-Link TP-SG105 V1.3 at the other U4). Ethernet connected from the router to the TP-SG108. Ethernet run from the TP-SG108 near the router to a TP-SG108, & Ethernet run from the TP-SG108 near the router to a TP-SG105. I doubt the switches are the cause of my issues.

I know how frustrating it can be, so good luck with your fault finding.

[Paul_oz53]

It's extremely unlikely that a switch would cause that kind of change in behaviour. Switches work at low layers of the networking protocol and have very standardised behaviour. Even the cheapest switches do the right thing. If they didn't most things would break.

Look for the source of problems elsewhere.

I agree that the switches are unlikely candidates for being the cause of the AUTOFS issue. But, given I've reflashed firmware many times on all the machines and have completely replaced all the other network components, I'm left with either my U4s have a later ethernet chipset, in which case nothing will rectify the problem because of some minor driver issue, or the switches are at fault.

If only to be thorough in the process of elimination I should try replacing one at some stage. Regardless, I don't plan on replacing the switches anytime soon, except if one fails or if one falls into my lap.

[Paul_oz53]

Hi Dennis,

I note your issue is different to mine and even harder to understand. I have tried your approach through, but it makes no difference in my case.

In the new configuration I had some grief getting the allocation of IP addresses to stick because the access point created some conflicts with some addresses allocated by MAC address. Sorted now.

As I mentioned above, it is doubtful it could be the switches but I have changed everything else and now use a router known to work for others. Either it's due to some difference internally in my U4s or it's the switches. Since FSTAB works and getting access is a problem, may be a while before I do anything more.

[peteru]

I can tell you that the following switches definitely work in my setup:

• TP-Link SG108D
• D-Link DGS108
• Asus GXD1081

As well as the built-in switches on:

• Asus RT-N16
• Netgear Orbi 75x series routers and satellites
• Netgear Orbi 30 and 40 series routers and satellites
• ACCC (SamKnows) NBN monitoring box

[peteru]

my U4s have a later ethernet chipset

That's unlikely. As far as I know, there was only one manufacturing run for the U4 and all the parts came from the same lot.

[peteru]

In the new configuration I had some grief getting the allocation of IP addresses to stick because the access point created some conflicts with some addresses allocated by MAC address. Sorted now.

That smells like a smoking gun. Do you have multiple subnets and/or multiple DHCP servers? What is the DNS authority for your local network and what software is it running?

On another note, I'm not sure if the Asus AC86U router is actually known to be good. I know Mr. Quade had issues with his network that he never resolved. In particular, slow DHCP response / ARP timeouts, which would certainly lead to resources not being available early in the boot process. The symptoms could include one type of mount not working and a different type (with slightly different timing sequence) working.

[IanL-S]

I have also had issues with the Asus AC86U, and with other Asus router which form my mesh network. The main issue I had was with inexplicible dropouts of the wifi network - devices would then go to my the wifi on my Bigopond router. This problem seems to have been fixed in recent firmware versions. So, make sure the router is running the latest firmware.

Ian

[sub3R]

...
After observing that, I reserved the IP addresses for both U4s at the two highest addresses in the DHCP address list.
...

I forgot to mention, but just for the record, when I changed the reserved IP addresses I deleted all traces of the U4 recording folder shares for both U4s on each U4 in the U4’s GUI Network setup (I retained all the PC shares), then made new shares with the new reserved IP addresses. I had done this before, but I back then I used the original reserved IP addresses.

If I still get problems I may swap the TP-SG108s around so the latest version is at the router (v1.3 <-> v3).

[Paul_oz53]

In the new configuration I had some grief getting the allocation of IP addresses to stick because the access point created some conflicts with some addresses allocated by MAC address. Sorted now.

That smells like a smoking gun. Do you have multiple subnets and/or multiple DHCP servers? What is the DNS authority for your local network and what software is it running?

On another note, I'm not sure if the Asus AC86U router is actually known to be good. I know Mr. Quade had issues with his network that he never resolved. In particular, slow DHCP response / ARP timeouts, which would certainly lead to resources not being available early in the boot process. The symptoms could include one type of mount not working and a different type (with slightly different timing sequence) working.

Only one subnet and one DHCP server. Hear what you're saying about the ASUS router. I meant "good" only in the sense MrQuade can use AUTOFS mounts.

The issue with the access point was it tried to allocate the address 192.xxx,xxx.50 to my phone as a wireless connection but the router had already allocated 192.xxx.xxx.50 to the rear U4. I had added the MAC address of the U4 with a reserved address 115 in the router but had not rebooted the router because the other half was watching Foxtel, which is internet connected. As soon as I rebooted the router, the address conflict was resolved correctly.

The DNS is derived from TPG's standard settings accessed by the router. I have no idea of the DNS authority for my local network and what software is it running. Of course, it is conceivable my problem is due to TPG as that is a common factor over time.

My switches are TP-Link SG1008Ds. I couldn't find the SG108D on the TP-Link website so maybe a typo? If the chipsets in the U4s were from one batch we can cross that off as a cause.

I'm now wondering if the real cause is that my ISP is TPG. If so, I'll live with the problem because professionally speaking, I rely on colleagues and professional advisers using my TPG email address.

I have also had issues with the Asus AC86U, and with other Asus router which form my mesh network. The main issue I had was with inexplicible dropouts of the wifi network - devices would then go to my the wifi on my Bigopond router. This problem seems to have been fixed in recent firmware versions. So, make sure the router is running the latest firmware.

Ian

Good suggestion. I'll follow up on that.

[MrQuade]

For the record, my RT-AC86U has been a solid performer, and I have never been able to reproduce this specific mount issue in all the years it has been reported.

The DHCP delay I experience remains a mystery. It appears like the delay in issuing addresses is only in the order of a hundred milliseconds or so, and only the U4, and V2 seem to care about that. This issue only stops the network browser from working properly, as the browser relies on a boot-time record of the STB's IP address and subnet information to work out what subnet to scan. Restarting the GUI fixes that glitch for me, though I would prefer it if the network browser didn't rely on a race condition to operate.

Speculatively, the delay might be due to the fact I am running the custom Merlin firmware, which expands the DHCP reservation pool. It's possible that since the DHCP table might no longer be permanently in memory, the delay required to find and read the table from flash is enough to delay the issuing of addresses.

[blip]

If the access point is allocating addresses as well as the router allocating addresses doesn't that mean they are both running DHCP servers?

[MrQuade]

If the access point is allocating addresses as well as the router allocating addresses doesn't that mean they are both running DHCP servers?

Yes, well spotted.

The issue with the access point was it tried to allocate the address 192.xxx,xxx.50 to my phone as a wireless connection but the router had already allocated 192.xxx.xxx.50 to the rear U4. I had added the MAC address of the U4 with a reserved address 115 in the router but had not rebooted the router because the other half was watching Foxtel, which is internet connected. As soon as I rebooted the router, the address conflict was resolved correctly.

Paul_oz53, make sure you only have one DHCP server running on your network. It is a spectacularly bad idea to have more than one running.

Your access points must only be there to provide the wireless connection, and you must turn off all other smart functions.....DHCP, DNS, routing, etc etc.

The same goes for IanL-S. The talk of devices switching between the Asus and Bigpond routers rings some alarm bells.

[IanL-S]

The same goes for IanL-S. The talk of devices switching between the Asus and Bigpond routers rings some alarm bells.

MrQuade,you are correct in pointing out the dangers of having two routers on the sane network. Double NAT is not something to be attempted lightly. I use this method because Telstra routers are traditionally security challenged. I have to use the Telstra router as it provides my land line and has the G4 fall over. To get the benefit of the G4 the Ausus router WAN port has to connect to one of the Telstra LAN ports. Do not remember how it is configured as it is many years since I did the configuration. I suspect I disabled the DHCP server, or limited it so it only works for wifi connections. Devices connected to the Telstra wifi cannot [easily?] access devices connected to the Asus router. The IP address for devices connected to the Ausus router are xxx.xxx.xxx.### and for the Telstra router xxx.xxx.yyy.###.

Ian

[MrQuade]

MrQuade,you are correct in pointing out the dangers of having two routers on the sane network. Double NAT is not something to be attempted lightly. I use this method because Telstra routers are traditionally security challenged. I have to use the Telstra router as it provides my land line and has the G4 fall over. To get the benefit of the G4 the Ausus router WAN port has to connect to one of the Telstra LAN ports. Do not remember how it is configured as it is many years since I did the configuration. I suspect I disabled the DHCP server, or limited it so it only works for wifi connections. Devices connected to the Telstra wifi cannot [easily?] access devices connected to the Asus router. The IP address for devices connected to the Ausus router are xxx.xxx.xxx.### and for the Telstra router xxx.xxx.yyy.###.

Ian

If you are using double NAT in that fashion then you should either turn off the WiFi on the telstra router entirely, or else set the SSID to a completely different name to the rest of your ASUS routers/APs and reserve that Telstra WiFi network for specific tasks that do not require access to your LAN (like IoT devices).

Ideally, just set the Telstra router up in bridged mode so that it acts only as a modem. Turn off wifi, and all other services and forget about the 4G failover. For the amount of time 4G actually gets used, it is not with it.

[Paul_oz53]

If the access point is allocating addresses as well as the router allocating addresses doesn't that mean they are both running DHCP servers?

Yes, well spotted.

The issue with the access point was it tried to allocate the address 192.xxx,xxx.50 to my phone as a wireless connection but the router had already allocated 192.xxx.xxx.50 to the rear U4. I had added the MAC address of the U4 with a reserved address 115 in the router but had not rebooted the router because the other half was watching Foxtel, which is internet connected. As soon as I rebooted the router, the address conflict was resolved correctly.

Paul_oz53, make sure you only have one DHCP server running on your network. It is a spectacularly bad idea to have more than one running.

Your access points must only be there to provide the wireless connection, and you must turn off all other smart functions.....DHCP, DNS, routing, etc etc.

The same goes for IanL-S. The talk of devices switching between the Asus and Bigpond routers rings some alarm bells.

Thanks for pointing that out guys. I have disabled DHCP - it was on auto.

[IanL-S]

If you are using double NAT in that fashion then you should either turn off the WiFi on the telstra router entirely, or else set the SSID to a completely different name to the rest of your ASUS routers/APs and reserve that Telstra WiFi network for specific tasks that do not require access to your LAN (like IoT devices).

Ideally, just set the Telstra router up in bridged mode so that it acts only as a modem. Turn off wifi, and all other services and forget about the 4G failover. For the amount of time 4G actually gets used, it is not with it.

The Telsta router wifi is completely different SSID.

[MrQuade]

The Telsta router wifi is completely different SSID.

Ok, no worries. Just the way you initially described it, it sounded like devices were switching automatically to the Bigpond WiFi which made it seem like the two WiFi domains were linked together.

[Paul_oz53]

A question for the WiFi experts amongst us.

Background:
We have have a long, skinny unit and live 99% of waking hours at the rear. The internet comes in at the front so we run wired ethernet to the front room, two studies and the rear living room. We run the U4, Foxtel, rear TV and the access point off a switch at the rear.

The SSID of the front 2.4GHz WiFi is "ASUS-17". This is the main router and is the DHCP server. The SSID of the rear of house access point is "Rear_WiFi_2.4". The 5GHz band SSIDs are separately named.

Our robot vacuum cleaner is on the rear 2.4GHz band but appears to stop cleaning when the WiFi signal strength becomes too weak as it heads to the front of the house.

Question:
Can I set the SSIDs of both 2.4GHz transmitting devices to the same name and password and expect the robot cleaner and other devices to work?

It's easy enough to change the front router SSID and password to experiment but the robot is charging just now. If it works I will only need to change one other 2.4GHz device. Most devices are 5GHz.

[MrQuade]

Yes. Your client devices should be able to roam between the access points when they are configured with the same SSID. (Though it may not always behave exactly as you'd want it to, some devices do like to stubbornly hold onto a weaker signal)

[Paul_oz53]

Yes. Your client devices should be able to roam between the access points when they are configured with the same SSID. (Though it may not always behave exactly as you'd want it to, some devices do like to stubbornly hold onto a weaker signal)

Thanks, in hindsight I wish I had set it up that way to start with.

[peteru]

It's unlikely to work too well. You'll end up with the same MAC address appearing on more than one switch port at the same time. When that happens, some switches will disable that physical switch port for a period of time. That can translate to issues such as your WiFi router (or a big segment of your network) going off-line for 30 seconds or even several minutes when a device changes networks.

Get a proper mesh network that can perform proper handovers.