I want to get the Rx power level measurement from my ONT Nokia G-010G-Q because if I have a problem, I think the ISP will try to blame me for not using their router. I try to connect to this ONT using ethernet cable and static IP. My laptop sends ARP and gets ARP reply from a MAC which belongs to Nokia. So I think the ONT is really sending that ARP reply. But my laptop does not register this MAC in its ARP table, and does not send any packet to the ONT e.g. ping, TCP according to Wirkeshark and pktmon. Any ideas?

Question

Accepted Answer

Direct answer to the question - Your ONT is almost certainly answering ARP at Layer 2 but blocking or isolating all Layer‑3 management traffic on the user Ethernet port. That’s why you see an ARP reply from a Nokia MAC yet your host never installs an ARP entry or proceeds with ICMPTCP. - On the Nokia G‑010G‑Q, the management plane is normally reachable only to the ISP over the fiber via OMCI and their management system. End‑user Ethernet access to Rx optical power is typically disabled. - To document Rx power, the practical options are: ask your ISP for the current ONT receive power from their OLTmanagement system, or measure it with an inline PON optical power meter. Local access via Ethernet is unlikely to work. Key points - Seeing ARP replies ≠ L3 reachability; management is usually locked down. - VLAN802.1Xservice profiles can make the ARP you see “non‑onlink” to your host, so the OS will discard it. - The most defensible Rx‑power record is the OLT view what your ISP uses, or an external meter reading. Detailed problem analysis What you observe is consistent with how carrier‑managed GPON ONTs behave: 1 ONT management model - G‑010G‑Q is a bridge ONT. Provisioning, status including optical RxTx power, and alarms are managed by the ISP via OMCI from the OLT and their management platform e.g., Nokia 5520 AMS. The copper Ethernet port is a subscriber service port, not a management port. - Many builds leave any local webSSHTelnet services disabled or bound to restricted VLANsMAC filters. Some firmware still responds to L2 probes ARPLLDP but drops all L3 from the subscriber side. 2 Why your ARP reply doesn’t become a neighbor entry Even though Wireshark shows an ARP reply, the OS may correctly decide it is not usable and refuse to install it. Common causes: - Off‑subnet SPAroute check: If your host sent ARP because of a temporaryincorrect route, it will still reject a reply whose sender protocol address SPA is not on‑link for that interface. - VLAN mismatch: The ARP reply is tagged 802.1Q with a management or service VLAN. Your NICOS, lacking a configured sub‑interface for that VLAN, will show the frame in capture but will not associate it with any on‑link IP network, so no neighbor entry is created. - Field mismatchnonstandard reply: If SPA ≠ the IP you ARP’d for TPA in your request, or TPA in the reply ≠ your host IP, WindowsLinux will drop it. - Port authorization: If the ONT applies 802.1XMAC filtering to only trust the ISP router’s EAP identityMAC, it may leak minimal L2 but block L3. 3 What to verify in your capture - Confirm SPATPA: In the ARP reply, SPA must equal the IP you asked about; TPA must be your host’s IP. - Check for 802.1Q tags: If you see “VLAN ID: x”, the ONT’s reply is not on your untagged interface. - Confirm Ethernet typelength and that the reply is unicast to your MAC not broadcastgratuitous. - Verify your routing table: The destination IP must be “on‑link” via that NIC host route 32 or matching subnet. Otherwise the OS will never use ARP for it after the first misconfigured probe. 4 Even if ARP succeeds… …most G‑010G‑Q units will still drop ICMPTCP from the user port to any management IP. That is intentional. Current information and trends - Contemporary GPONXGS‑PON deployments keep ONT management strictly ISP‑side. The OLT continuously polls ONT optics and alarms over OMCI; that’s the authoritative Rx value your provider sees. - Some ONTs for businessMDU or SFP‑style ONUs expose optics stats to the CPE, but the G‑010G‑Q in residential service is commonly locked down. - ISPs increasingly pair ONTs with managed gateways and may enforce VLANs andor 802.1X between ONT and router, further restricting client access. Supporting explanations and details - ARP and on‑link logic: Hosts only ARP for destinations they believe are directly reachable on that interface. Replies that don’t satisfy on‑link and field‑matching rules are silently dropped to prevent spoofing. - VLAN visibility vs. usability: Many NICs deliver tagged frames to the capture stack while the OS networking stack discards them unless a VLAN sub‑interface is configured. This explains “I can see the ARP reply in Wireshark but the ARP cache is empty.” Ethical and legal aspects - Opening the ONT, attaching to UARTserial pads, or attempting to bypass ISP controls may violate your service agreement and local regulations, and risks bricking the unit. - Injecting an inline meter requires disconnecting fiber; do so carefully to avoid service disruption and fiber eye‑safety hazards. Practical guidelines To conclusively troubleshoot your ARP symptom - Validate IP and routes - Set a clean, on‑link configuration and host route: - Example: If you believe the ONT uses 192.168.100.1, set your NIC to 192.168.100.224. - Add a forced on‑link route: Windows: “route add 192.168.100.1 mask 255.255.255.255 IF -p” or “netsh interface ipv4 add route 192.168.100.132 interface= store=persistent”. - Clear ARP cache and retry. - Inspect the ARP frames - In Wireshark, confirm SPATPA fields and whether a VLAN tag is present. - If VLAN is present - Configure a VLAN sub‑interface with that VID. - Linux: ip link add link eth0 name eth0. type vlan id ; ip addr add 192.168.100.224 dev eth0.; ip link set eth0. up. - Windows: use your NIC’s VLAN utilityAdvanced properties to create a VLAN interface with the same VID. - Static ARP diagnostic only - Manually add a static neighbor arp -s or ip neigh add using the Nokia MAC from the capture, then ping. If frames still don’t leave your host, it’s a routing or policy block; if they leave but there’s no reply, the ONT is filtering L3. How to get the Rx power level best‑effort to least invasive - Ask the ISP for the current downstream “ONT receive optical power dBm” as seen at the OLT, plus LOSLOF alarms. Note the datetime. This is the value they will rely on when dispatching. - If your ISP provides a customer portalapp, check for ONT optical stats there. - Use a PON optical power meter SCAPC inline between the wall fiber and ONT. Choose a PON‑rated meter with pass‑through that displays 1490‑nm downstream power in dBm. Record the value and conditions time, weather, splitters used. - If you must use the ISP router temporarily, some models display ONT optics under diagnostics when paired to that ONT; take screenshots. - Typical GPON receive ranges rule‑of‑thumb: around −15 to −28 dBm is normalworking; below about −29 to −30 dBm is marginal to failing. The exact thresholds depend on the OLTONT optics class and operator policy. What not to expect - SNMP or a local web page on G‑010G‑Q via the subscriber Ethernet port; those services are usually disabled or restricted by policy. Possible disclaimers or additional notes - Default management IPs for this model vary by operator and are often unreachable from the user port even if they exist internally. - Some environments require the ISP gateway’s 802.1X identity or a specific service VLAN; without it, the ONT port remains in an unauthorizedfiltered state. Suggestions for further research - If you have a managed switch, place it between ONT and PC, mirror the ONT port, and capture to confirm VLAN IDs and any 802.1XEAPOL exchanges. - Check your NIC vendor utilities for per‑VLAN interface creation on Windows; otherwise test from a Linux live boot for easier VLAN handling. - If you plan to purchase a power meter, look for PON‑specific models that report dBm at 1490 nm with SCAPC connectors and pass‑through design. Brief summary - Your capture proves L2 reachability, but the ONT’s L3 management is intentionally inaccessible from the user port andor is on a VLANauthorized path your host doesn’t have. That’s why ARP replies don’t become usable neighbor entries and no pingTCP follow. - For Rx optical power, the most supportable path is: obtain the reading from your ISP’s OLTmanagement system andor measure with an inline PON power meter. Any attempt to query the G‑010G‑Q directly over Ethernet is unlikely to yield results due to ISP lock‑down.

Nokia G-010G-Q ONT ARP Reply but No L3 Access, Rx Power Measurement Blocked

User question

Artificial Intelligence Response

Direct answer to the question

Detailed problem analysis

Current information and trends

Supporting explanations and details

Ethical and legal aspects

Practical guidelines

Possible disclaimers or additional notes

Suggestions for further research

Brief summary

Ask additional question