Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on November 27, 2018, 10:37:57 AM
-
I do seem to have angered the ZyXEL and gods. My delight at seeing yet another all time downstream speed record of 3.26 Mbps for the line #1 modem, with all modems over 3 Mbps downstream has offended the dark deities.
The modem #1 has gone into the weird state that I experienced ages ago, where it works, talks to the internet but the admin webserver doesn’t work any more. I rebooted it with a reboot command at the CLI and even that did not restore the functioning of the admin web server. So I have asked Mrs Weaver to switch it off and it is being left off for a while.
Meanwhile, this morning, line #4 downstream SNRM zoomed quickly down to -4 dB and it resynched. The d/s noise level has gone up such a lot that when it came back up it had lost just over 550 kbps in d/s sync rate. So the DSL copper gods have been offended too. So that modem is now turned off too, having a long rest as well.
-
:'(
-
This morning, the VMG 1312-B10A that was in use on line 4 became really unstable, dropping the link, noise readings reportedly went up, d/s sync speed dropped down to 2Mbps v approx. After leaving it switched off for a long while, turned it back on and things git much worse, resynching often, d/s sync speed then down to ~1.1Mbps. This evening, put a DLink in in place on line 4, service restored, sync rate up to 2.8 / 0.55 Mbps, downstream SNRM 3.4 Mbps. I have not got round to flashing and configuring a replacement B10Aye5, but I have several spares lined up. So an exact repeat performance of what happened a couple of weeks ago with this particular individual B10A. It has been sentenced to death.
-
even though I've swapped out the modem, the replacement modem on line 4 is now (I think) not in sync having lost the connection at 20:22 on wed evening, and it has remained down, never reconnected for some reason. I did a BT copper line test, no problems and I'm stuck now. Next thing is to power-cycle the modem.
-
Engineer came out to line 4 on Monday. Fixed it up on Tuesday morning.
Managed to break line 3 the moment he arrived! Bit of a coincidence that it failed the exact time he turned up. Another engineer coming on Fri to mend line 3 now. Told AA this.
intermittent DeltaR / Autoprotective PQT test performed at NTE back plate. The test passed with resistance within permissible range for broadband on 04/12/2018.TDR completed. PQT performed at NTE backplate. The test failed on 04/12/2018.No noise, misrouted / crossed lines or left in FTTC jumpers in PCP on the line identified. Fault located in the D side underground network. Base module checks completed. Resolved issue in joint. Network module completed as amber parameters were identified. Engineer checked the pair quality on D-side. D-side underground network upgraded. No change in the broadband Stability / speed / sync, despite improving the PQT parameters. NTE not replaced. Final PQT performed at the NTE back plate. The test passed with amber parameters on 04/12/2018.Final FastTest completed. The test passed on 04/12/2018
I found a reference to ‘delta-R’ in another Kitz thread. I’m thinking this means resistance measurements made but with two tests, injecting two different voltages ? Is that right? In case too much injected test voltage is providing wetting current for a junction? Test-injected voltage fixing the problem? I’m just guessing.
It’s not true the bit about speed sync stability improved as line 4 is fine now, speed back up to what it should be roughly and it is stable.
I’m trying to remember. I don’t think this is the only time OR has come out to fix one line and broken another one :-( No compensation for me and AA for the cost, loss of service and the hassle.
-
It goes on :( and on. :'(
-
Spinning plates.
-
Crazy. Just highlights the problems with ancient copper... openreach man goes in a cavern or up a poll, wobbles stuff and it breaks. 21st century network!
-
It seems to me that CPs ought to be able to require a physical quality review of an entire group of metallic paths. Not just those belonging to one end-user, but all circuits in a particular run that belong to their end users. And the output of that should be a required re-work and reliability upgrade plan that will radically reduce the number of future faults where applicable. I have thoughts regarding a metric.
-
Today’s visit - wet, corrosion
Note Please find the engineer notes without check list :- I completed the ring ahead with the end customer and progressed to their premises. End customer advised there is a broadband issue. I have resolved the fault located at the D-side including aerial cables / lead-in / block terminal. The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable. The fault was fixed by clearing in joint. No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding. Engineer has not visited end customer premises. I performed final Fast Test from the customer premise. Engineer notes with check list :- 07/12/2018 13:52:00 ===Point Of Intervention notes=== Between this point... - Location: 80ms below cattle grid - Work Point: JB23 At this point... Plant details... - Plant affected: JNT100 - Plant type: UCJ Multiple Intervention?: Y ===Point Of Intervention notes ends=== (No manually entered closure notes) ===QBC Summary Start===I completed the ring ahead with the end customer and progressed to their premises. End customer advised there is a broadband issue. I have resolved the fault located at the D-side including aerial cables / lead-in / block terminal. The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable. The fault was fixed by clearing in joint. No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding. Engineer has not visited end customer premises. I performed final Fast Test from the customer premise. The test passed on 07/12/2018 13:45:16.===QBC Summary End===
Can / should something be done to keep the wet and salt out?
-
In theory, the clip-type joint closure should be watertight. They often spend a lot of time submerged in murky, stagnant, water within a footway or roadway joint box/chamber.
Without actually seeing what the technician saw it is difficult to say anything more.
-
By taking a copy of the above quotation block and formatting it locally, by liberally inserting <New Line> characters, we can now see --
Note Please find the engineer notes without check list :-
I completed the ring ahead with the end customer and progressed to their premises.
End customer advised there is a broadband issue.
I have resolved the fault located at the D-side including aerial cables / lead-in / block terminal.
The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable.
The fault was fixed by clearing in joint.
No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding.
Engineer has not visited end customer premises.
I performed final Fast Test from the customer premise.
Engineer notes with check list :-
07/12/2018 13:52:00
===Point Of Intervention notes===
Between this point... - Location: 80ms below cattle grid - Work Point: JB23
At this point...
Plant details... - Plant affected: JNT100 - Plant type: UCJ Multiple Intervention?: Y
===Point Of Intervention notes ends===
(No manually entered closure notes)
===QBC Summary Start===
I completed the ring ahead with the end customer and progressed to their premises.
End customer advised there is a broadband issue.
I have resolved the fault located at the D-side including aerial cables / lead-in / block terminal.
The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable.
The fault was fixed by clearing in joint.
No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding.
Engineer has not visited end customer premises.
I performed final Fast Test from the customer premise.
The test passed on 07/12/2018 13:45:16.
===QBC Summary End===
-
We really need the services of Black Sheep, liquorice or 4c to translate the above.
My attempts --
Work Point: JB23 . . . . . . . . . . . . Joint Box 23 ?
Plant affected: JNT100 . . . . . . I suspect that is a reference to a 100 pair cable.
Plant type: UCJ . . . . . . . . . . . . . Universal Clip Joint ?
-
Is Jb23 a part code? Or a location?
-
I'm uncertain as to its precise meaning. :-\
Working from the notes (and knowing your location & environment well (with the help of Google's Street View)) . . .
Location: 80ms below cattle grid - Work Point: JB23
Taking the "80ms" to be "80 metres" (not 80 milliseconds) and "below cattle grid" to be "beyond the cattle grid, downhill towards the village", then that puts "Work Point: JB23" to be at the foot of the carrier pole from which your four aerial feeds emanate.
Probably that point is marked in the network records as "JB23".
-
Since 11:30 Saturday morning, line three, having just been ‘fixed’ was constantly losing sync, with massive packet loss. Downstream sync speed dropped from 3.15 Mbps down to ~740k and upstream speed is now a miserable ~160k.
>:( ??? :no:
-
You need A&A to reopen the fault report to Openreach, if possible, otherwise submit a new fault report and have it escalated. :(
-
I dropped a line to AA just in case they do not notice that that line is still very sickly indeed, frequent resynchs and syncing at low speed.
The clueless logs tell me that AA has left itself a reminder re this line - ‘needs a management review’ which hopefully means what it says on the tin. Sounds encouraging anyway, perhaps implies that they would have taken another look at it regardless.
-
It was actually all the way down to 300k downstream yesterday, because I had pushed the target SNRM all the way right up to 12dB in an attempt to put a stop to its constant resynching. It’s back up to where it should be now, at 2.68Mbps d/s @ dB SNRM.
Unplugged the modem from the line so AA could do some more tests.
Today 10:05:02 Today 13:05:02 Management review TR H18KKT needs a review @aa
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Informational Message: 4058 Notification Only - Fault is assigned to Engineer. Fault status is now PONR. bt
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Estimated Response Time: 2018-12-11T23:59:59 bt
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Status: Open - Past PONR bt
Today 09:47:59
Today 09:46:49 Tomorrow 09:46:49 Track fault and update customer PSTN Fault - NSY @aa
Today 09:46:49 Tomorrow 09:46:49 Wait for supplier to confirm fault cleared PSTN Fault - NSY @aa
Waiting on faultbtconfirm Wait customer confirms fault closed PSTN Fault - NSY @aa
Today 08:40:10 Today 17:00:00 ToDo Check Line since an SNR Reset was run @aa
Today 10:05:02 Today 13:05:02 Management review TR H18KKT needs a review @aa
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Informational Message: 4058 Notification Only - Fault is assigned to Engineer. Fault status is now PONR. bt
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Estimated Response Time: 2018-12-11T23:59:59 bt
Today 09:59:45 Track PSTN Fault 5-7-168934119702 Status: Open - Past PONR bt
Today 09:47:59 Track PSTN Fault 5-7-168934119702 Notes Field:
**Line Stability:
**Network Stability:
**Test Outcome: Fail
**MFL: LN
**Term Statement: LINE TERMINATION DETECTED
**Line Signature:
**Distance to Fault: 0
**Cable length: 8.05
**Test Start Time: 2018-12-10T09:47:52
**Test Stop Time: 2018-12-10T09:47:52 bt
Today 09:47:59 Track PSTN Fault 5-7-168934119702 Informational Message: 4465 Please refer to the Notes field for the actual message bt
Today 09:47:59 Track PSTN Fault 5-7-168934119702 Estimated Response Time: 2018-12-11T23:59:59 bt
Today 09:47:59 Track PSTN Fault 5-7-168934119702 Status: Open - Associating Info bt
Today 09:47:09 Track PSTN Fault 5-7-168934119702 Informational Message: 4040 Notification only - Estimated Response Time. bt
Today 09:47:09 Track PSTN Fault 5-7-168934119702 Informational Message: 3100 Trouble Report Accepted bt
Today 09:47:09 Track PSTN Fault 5-7-168934119702 Estimated Response Time: 2018-12-11T23:59:59 bt
Today 09:47:09 Track PSTN Fault 5-7-168934119702 Status: Open - New bt
Today 09:46:56 Track PSTN Fault 5-7-168934119702 Message Informational 9323 The asset care level 2.5 will be applied rather than the specified service level. bt
Today 09:46:56 Track PSTN Fault 5-7-168934119702 Message Informational 3241 Notification Only - Trouble Report Creation Request is Pending bt
7 Dec 15:05:02 Today 09:58:46 Management review TR H18KKT needs a review @aa
Today 09:46:28 WLR3Test NSY dys00556dat01:142978817: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement: @aa
Today 09:45:27 WLR3Test WLR3_CIDT_Test dys00556app04:426519159: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement: @aa
Today 08:43:14 WLR3Test WLR3_CIDT_Test dys00556dat01:142960265: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired
Does that say 8.05 km? Really?
So, BatteryContact again.
And we talked about this before: why “The asset care level 2.5 will be applied rather than the specified service level” ? I can’t remember what we said that was all about.
-
Does that say 8.05 km? Really?
Yes and no. Possibly circuit attenuation based. I suspect it is really more of a guess. Perhaps disembowelling a low flying raven, scattering the entrails and looking to see how they then laid was involved. I see to recall that Black Sheep looked at the network records and performed the sums, thus coming up with a physical distance between NSBRD and the Weaving Shed.
So, BatteryContact again.
So it claims.
And we talked about this before: why “The asset care level 2.5 will be applied rather than the specified service level” ? I can’t remember what we said that was all about.
Sorry, I can't remember that discussion and so cannot provide any help or hints.
-
AA was unbelievably fast, just within a couple of hours, another one of our local OR guys attacked it again:
Today 11:44:48 Track PSTN Fault 5-7-168934119702 Notes Field: 10/12/2018 11:43:00
Point Of Intervention notes
Between this point. . . Location: 40 metres before cattle
Work Point: JB23 At this point. . . Plant details. . . Plant affected: JNT50
Plant type: UCJ Multiple Intervention?: N
Point Of Intervention notes ends
(No manually entered closure notes)
QBC Summary Start
I completed the ring ahead but there was no answer (voice message left where available). I continued to progress to the end customer premises. End customer advised there is a broadband issue. I have resolved the fault located at the D-side including aerial cables / lead-in / block terminal. The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable. The fault was fixed by clearing in joint. No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding. Engineer has not visited end customer premises. I performed final FastTest from the customer premise. The test passed on 10/12/2018 11:23:02. QBC Summary End
-
Hopefully all four circuits will now remain operational and stable for the foreseeable future. :)
-
No such luck. Back to line 4 now. Total chaos on Tuesday, umpteen resyncs, so AA who were monitoring the line for me, just immediately got OR straight out and OR did some work on the underground copper yesterday. More chaos of course on the line followed. I had no idea that anything was even happening as AA handled everything. I was so ill yesterday, I was unconscious all day until about 02:00 this morning when the drugs kicked in.
This morning my wife got a call from an OR engineer on the mainland who said he was heading for me. I was totally unawares. As I wasn’t expecting any visit, not having yet realised about the history of problems, I got my wife to ask the engineer which DSL phone number. He couldn’t understand that because not used to there being anything more than just ‘your phone line’ singular. Struggled to work out which line this phone number belonged to. Eventually my wife managed to find a table of phone numbers and mapped from that to line #4. So apparently someone is due to fix an earth side fault near the house in the next few mins.
Superb job AA did for me, just handling everything while I was out of it.
-
The OpenReach loutish guy was very rude to my wife, churlish and ignorant. Eye rolling and I’m just here for phones don’t care about internet, or words to that effect, I forget the exact words my wife recounted exactly. My wife told him we don’t have any phones. Then, concerning my ISP, something like, there was nothing wrong - ‘They probably just made it up’ or similar. The most nasty guy I’ve ever had and unfortunately I wasn’t there so my wife had to put up with this yob’s attitude. I don’t think his employer would be very happy if they had overheard.
-
Why are AA raising phone faults if they only sell you an xDSL service.
An engineer who turns up for a phone job can't just change the job sheet and retrain himself for broadband faults while sitting in his van unfortunately.
The attitude sounds bad from the engineer, but when they say "I'm here for phones, not internet" he's absolutely spot on. He's tasked to fix the issue on his sheet.
Perhaps BlackSheep could explain it a little more but it's a very common complaint. It isn't the fault of the engineer, it's the ISP who books the task.
No need for him to be rude about it. A simple "I'm sorry I'm here for a specific task only" would suffice.
-
Might this be the fault of BTw asking for the wrong thing of OpenReach rather than AAISP?
-
I pay AA line rental. Don’t know if that is significant.
If something is sufficiently low-level and disruptive that it counts as a PSTN fault then that could be what it was?
This was, I am told, unsolicited mouthing off from our man at my wife who had never mentioned internet but he saw a router large switch umpteen modems etc and so volunteered this unsolicited statement of last century attitude.
I have just looked back in the event log in AA’s clueless. AA raised a PSTN fault on Tuesday.
WLR3Test NSY dys00556app06:420989733: Fail FAULT - Earth Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:
AA also gave me our friend’s name.
-
Latest visits re cwcc@a.4 did not fix it at all. Still very unstable and downstream sync rate down to 1.3 Mbps, instead of ~2.8 Mbps d/s at 6dB target SNRM, or 3.1Mbps d/s at 3dB.
So the saga continues.
I’m wondering if I should reinstate ‘enhanced care’ on that line.
-
My feeling is that once you have reported a problem to A&A, you should not need to do anything more. You are paying a premium price for a service from a premium ISP (CP) . . . :-X
-
AA are looking into line 4 again.
If anyone has any advice about this line, I would be grateful. Will post up more raw stats after latest repairs if requested.
—
On an unrelated matter, line 1 is no longer stable at 3dB downstream target SNRM, with between one and three resyncs per day. I have put it up to 6dB, which unfortunately has chopped 254k off the downstream sync rate, was 3.115 Mbps down to 2.861 Mbps sync rate. So 3dB is quite a big deal, gives me an extra 9%, shame I can’t quite sustain it on this, the fastest performing line, any longer as presumably the noise variation must be too great or the target needs to be just a little bit higher, say 4dB or something. I ought to capture somenoise stats over time on this line. Need to get the good Johnson embedded stats webserver installed in that modem.
-
AA are looking into line 4 again.
:(
If anyone has any advice about this line, I would be grateful. Will post up more raw stats after latest repairs if requested.
The problem is that a snapshot of the data does not provide a picture of the ongoing situation. Hence it is very difficult for those with the ability to diagnose and pronounce on a circuit.
-
Agreed. I was thinking more about matching histories.
More news. AA tell me they have switched DLM off on line 1 which was unstable at 3dB. I think from what they said they are switching off DLM on line 4, in case it is insane DLM driving speeds down and down.
I didn’t even know one could switch DLM off?
They have asked me not to do a SNRM reset ‘in case doing so restarts DLM’ or words to that effect. [?]
-
I didn’t even know one could switch DLM off?
Yes, it is possible for ADSL2+ circuits. (My TalkTalk provided service has been so configured for many years. 6 dB target SNRM, interleaved, DLM disabled.)
They have asked me not to do a SNRM reset ‘in case doing so restarts DLM’ or words to that effect. [?]
I'm not sure of the meaning of that statement. Perhaps it was a case of wanting to say something and just used the first "stream of words" that came to mind! ::)
-
The thing is, regarding line 4, in a very recent SNRM 24-hour graph, I saw a 4dB sharp decrease in downstream noise level (upwards-going in the graph), from 4dB to 8dB vertical cliff. So I am getting far more or less noise, depending on your point of view, at times. This has not been seen before on downstream, yet this kind of step transition is very noticeable with the _upstream_on many of the lines, with either a single on/off cycle with a 24 hour period or a higher frequency cycle of several cycles per day.
So it could be that there is some equipment being switched on/off somewhere near NSBFD, in civilisation, at the exchange-end, as there is no human habitation or electrical activity anywhere near here, not even a wall or a tree for three miles upstream from this house along the cable run, and only in the last mile does one find a lot of houses.
Theory: I’m wondering if I have enjoyed my historic 3Mbps downstream sync rates while the noise is low and recently line 4 has started experiencing periods of high noise each day. If this noise extends to higher frequencies it kills the downstream performance. If it is confined to lower tones, it only affects upstream which also is on a higher 6dB margin so more resilient. And I presume there’s no DLM on upstream? But I don’t know. Anyway, if I resynched during the low noise times, then at 4dB less noise, I can get my usual high sync rates, but the 4dB noise increased level is in effect at that point in the day, then I get knocked out. Presumably this confuses DLM because it can’t understand what’s going on, what with the on-off noise pattern.
That’s the best I can come up with so far.
I think it was an excellent idea from AA about turning DLM off. In my ignorance I didn’t even know that that could be done with some BT lines.
I don’t have any similar data for line 1, as I haven’t yet installed a stats monitoring server.
I don’t suppose BT will do anything about an external noise source. But given that the other lines are not getting it, surely it has to be an issue of increased _susceptibility_ in that line, no? Lack of balance perhaps? Would that make sense? Insufficient noise rejection, because of inadequate symmetry between the two sides of/conductors in that pair?
-
I don’t suppose BT will do anything about an external noise source. But given that the other lines are not getting it, surely it has to be an issue of increased _susceptibility_ in that line, no? Lack of balance perhaps? Would that make sense? Insufficient noise rejection, because of inadequate symmetry between the two sides of/conductors in that pair?
Very unlikely in my opinion.
A sharp increase in SNRM of 4 dB, that comes and goes at around 4dB each time is almost certainly an item of electrical equipment running near that line.
As you say this can be anywhere between you and exchange.
Is line 4 the most recent line to be installed?
I recall AA line numbering doesn't match due to a mobile SIM.
If it is the most recent line you need to remember that line likely goes a different route to the other 3, as that line shows as coming from a PCP.
Are AA able to alter their numbering of the lines?
Can you check if this line is the line that passes through the PCP?
-
@j0hn the numbering is out of sequence as you say. No @2 is the new one, with a different D-side.
Line 4 has been in place for many years. Don’t know what the story regarding the route has been. I’m not even sure that that PCP cabinet was there at all earlier, but maybe I am wrong. I’ll ask my wife if she can remember. But since I haven’t been out if the house in years I’m no use.
—
Major update. I just got Janet to swap out modems 4 and 1. Line 4 is now back up to full speed with a replacement modem. So it seems there was also something dodgy about the previous modem 4, yet again. This is not the first time I have had my suspicions, been ok for a while and then become dodgy. I’m going to put unique numbers on all of them.
Can the serial numbers be overwritten by flashing or in config or anything bad like that? I would hope not, but I just thought I had better check.
One thing is that they all seem to share the same supervisor password in my experience. Is that normal experience ? If so, then I must be simply blowing that along with the rest of the config and it is not uniquely defined by the true innate (hard) hardware.
-
One thing is that they all seem to share the same supervisor password in my experience. Is that normal experience ? If so, then I must be simply blowing that along with the rest of the config and it is not uniquely defined by the true innate (hard) hardware.
All ZyXEL VMG1312-B10A have the same supervisor password created at power-on (cold boot) which is the documented "zyad1234". That password is then changed, later in the boot sequence, to a unique eight digit hexadecimal number (which is suspected as being related to the device serial number). [1][2]
I seem to recall you creating your own configuration for the devices and then copying (uploading) that configuration to them all. It was then that you mentioned they all shared the same supervisor password.
[1] ZyXEL VMGnnnn CPEs. Serial Number and the Supervisor Password (https://forum.kitz.co.uk/index.php/topic,22414.0.html)
[2] Building and Executing MIPS executables on Intel using the crosstools (https://forum.kitz.co.uk/index.php/topic,22852.0.html)
-
Thing is, I can get into all my modems with one single supervisor password.
So for some reason I am not using serial number-based passwords?
I could do with looking up the serial number of the modems for stock-keeping actually.
-
I could do with looking up the serial number of the modems for stock-keeping actually.
In pseudo-code --
for each device; do
dumpmdm | grep -i serialnumber
done
-
Sorry for being stupid - dumpmdm needs you to be logged in as supervisor, so I had a false start until I worked that out.
But I can’t seem to grep the damned thing and it’s enormous. I wondered if there were perhaps no LFs in it, so I tried to use sed to insert some at sensible points, yet that didn’t seem to work either.
And I can’t fetch it back to the iPad either due to who knows what problem, tried writing a short program to fetch the output of dumpmdm via ssh, but all I get out of it is a goodbye message from the CLI, ‘bye’ the look of it, a cheery message in ASCII. So I’m having zero luck at the moment with everything. I’m told it’s to do with old code used in their build of SSH. So really I should be querying it with telnet, and guess what, don’t have the tools to do that on the iPad.
Would love to get the Raspberry Pi going some day. Wonder if I could buy an accessible one from somewhere, all set up ready to go.
-
Does the iPad have any means of saving "whatever is happening" to a logfile?
With this computer, I open a CLI terminal and then --
[bcat tmp]$ screen -L -U ssh supervisor@AP
supervisor@ap's password:
> dumpmdm
<many hundreds of lines>
> exit
Connection to AP closed.
[screen is terminating]
[bcat tmp]$ grep -i serialnumber screenlog.0
<SerialNumber>S170Y01234567</SerialNumber>
[bcat tmp]$
Other alternatives are --
- Enter the GUI, navigate Network Map >> Status and read the third line of information.
- Physically turn the device over and read the label on the underside.
-
So really I should be querying it with telnet, and guess what, don’t have the tools to do that on the iPad.
Is there a telnet tool in the "Network-Toolbox" app by Marcus Roskosch (which I think you have)?
-
Yes, there is, in fact. And I have a couple of other telnet-speaking tools.
Unfortunately I can’t use the telnet protocol in Shortcuts _programs_, only SSH, which works very well normally, but with the ZyXEL’s implementation of SSH talking to various other kinds of software, I get weird problems.