VM email advisement of local (Hove) upgrade after weekend with typically no further usefull detail offered so I’m assuming it’s part of 1GBps rollout?
I monitor several Hub3’s on same cable segment (7060 ?) so this is a placeholder in case It goes “pear shaped”:
https://www.thinkbroadband.com/broadband/monitoring/quality/share/554536fa212e1a842d8fcd954fe0c404c7...
https://www.thinkbroadband.com/broadband/monitoring/quality/share/e523ab5975e7a037c54fa2651bb9292455...
DEFROCKED
@Steven_L wrote: …….We can only go through the diagnosis that is available to us on the system. …….
Thanks for your reply/effort @Steven_L but clearly having to rely on any management directives to only follow automated Traffic Light System diagnosis will severely restrict identifying technical training opportunities and thus system improvements (IMHO based on 40yrs hands on experience) !
However understand the asinine restrictions you’re forced to comply with…. Fortunately many users and this forum (unless you’re ex CA/SU/VIP) allow technical discussion to promote mutual learning et al.
@Steven_L wrote: …….I have done a thorough check of your account and the local area, after doing this I cannot find any issues at the moment with your connection. ……
Therefore If you are discouraged from reviewing users symptoms during time line and delays between posts on same thread then you’ll miss the obvious as in this case:
- Remote (soft/warm) POR failed to correct U/S T3’s until User returned on 4Jan to perform a (hard/cold) power on reset.
- Thus when you checked as per your 10thJan21. Post then it was possibly after a subsequent warm POR I did at 8am that day to resolve a TBB BQM “red wall resource” issue (ergo not shown on “f8lure” alternate ICMP alternative plot)? So I agree/confirm you would not find any T3 issues because until yesterday(13Jan) neither did I.
- Unfortunately on Thursday, Hub then started to produce DHCP errors on WiFi (ENET still working) which both soft & hard POR attempts failed to resolve Necessitating a FR.
- Again had time/management allowed you to review the thread you would have seen the NMS firm ware update AND why I had not immediately performed a Factory Reset. Thus the firmware has now regressed back to level used before U/S noise started at beginning of this thread and no immediate indications of any significant T3 issues so far.
My current hypothesis therefore is unless “thorough check” of users “account and local area” included firmware comparisons and SNR over the whole time period of thread and users on my (7060?) cable segment then regrettably I suspect we are both wasting our time if you cannot access IPDR/similar data from host end?
That said I can provide “user symptom stats detail” to illustrate all the above. Furthermore I’ll continue to stress test current Hub + VM Powerline, and VM Pods to identify any re-occurrence or additional “issues”. (Unless forum management interpret this as an attempt to circumvent previous Trial/test NDA’s 😛 )
Thanks again for your response and I trust you’ll accept the above lengthy comments in reply are not intended as any personal critique but merely the restrictions imposed on you and your colleagues by management.
@Molly_T wrote:Hi Tony,
Thank you for your thorough response, and understanding regarding some of the limitations of our systems. ……
….Please do let us know how you are getting on with things.
I haven’t updated recently because clearly I’m wasting my time trying to discuss technical (educate wrt) issues with ForumTeam respondents that don’t appear to have access to IPDR backend systems without using asinine “traffic light system” and/or Level2/3 Networking support directly.
Summary:
- I used (explicit) FR to reverse NMS FIRMWARE update that VM had pushed earlier in start of year which “stalled”
- Clearly [sic] apparently VM have advised local BN3 7N* network “improvements” - the last being 15Feb2022 which have created erratic “SNR” issues on TBB/BQM and U/S channels….
- Lately this has been superceeded by “central core” [sic - routing] issues that require alternate Firebrick/ICMP plotting (egMouselike.com)
- currently then 32.6Mhz is more stable and freq offsets are now showing minor T3’s on other U/S Chans….
I can provide more detail if FT are willing to commit but as stated I’m not wasting my time if they are restricted by management. ;(
SNR issues appear to have resolved but another NMS upgrade recently forced me to perform a further HARD FR to regress back to “config software update”. Which is currently now using 46.2Mhz u/s without any obvious SNR issues.
Of course I can publish further supportive detail that demonstrates those few of us “ex SuperUsers”that still attempt to support community are deliberately being excluded with asinine incompetence of management by VM ineptly ignoring 10yrs of previous Trials configuration.
Again VM Networks pushed a repeated NMS firmware push on Tuesday 24/5/22:
24/05/2022 00:24:34 notice. SW download Successful - Via NMS
24/05/2022 00:21:55 notice SW Download INIT - Via NMS
This time [Somewhat predictably] VM Networks have “apparently” modified the DNS/CM MAC options on my V10 Hub so that now, no amount of “soft” or “hard” FR’s will “toggle/reset” back to “sw config” release! [**]
Thus 9.1.2109.200 firmware won’t regress back to previous 9.1.1912.304 version.
NB[**] That said and to be fair I/we can’t discount V10 VMDG505 Hub failure either causing this “resource issue”?
Again I can provide daily/weekly elaboration detail since last (and earlier posta) to Networks but I’m confident they are fully aware of BRIG19 AND ASSOCIATED CABLE SEGMENT NOISE BALANCING. However I’m NO LONGER prepared to waste my time to “sanitise” posts for public media but only for PM/DM to Networks or ForumTeam.
@Paul_DN wrote: ………..How are things today, I have run further checks our side and cannot see any issues at all.>…>…………
Please expand on “further checks” but since 14:00 on 7th June I lost all remote contact (port 7979) to my Hub. This was preceded with 101 T3’s on 32.6Mhz upstream although 46.2 was primary locked ch. Please confirm my 81.*.*.182:7979 has not changed and “flap list” not indicated any local disco.
Suggest you invite a PM/DM so I can provide authentication + end user diags to illustrate - thanks
@Tom_W1 wrote:Hi @horseman thanks for your reply.
- We have a number of diagnostics we run using different tools and software which check your network, which is what we've exhausted in our previous reply to you
- When you say you've lost all remote contact to your Hub, are you fully offline at the moment?
- Can you perhaps provide a screenshot of what lights are currently showing on your Hub?
Reply/comments:
2. No “smart devices” and Amazon echo devices accessible but TBB/BQM resumed 4:30pm on 13thJune!
3. NO - OK did kick the seagulls off roof of our Selsey beach hut but even with my x20 binocs I couldn’t see my Hub 38(road) miles away in Hove… (the clue is in “remote access” 😛 )
1. Unless your “number of diagnostics” and “different tools and software” are still reporting/diluted by “traffic light” system then it would be far more helpful to confirm or comment on following:
1.1 Has my Public IP changed?
1.2 Has my remote access port changed? (Also tried 8443 default)
1.3 My hypothesis is my remaining v1.0 Hub3 with 10 devices is “resource constrained”? Before April this year I could also use comparative diags on my trial v1.1 Hub3 and move end devices to investigate further.
