Affected versions:

• Firefox Nightly 71.0a1 from taskcluster with the fix from bug 1583170 included.

Affected Platforms:

• MacOS 10.14

Prerequisites:

• You are connected to a Lan network.

Steps to reproduce:

1. Open Firefox and go to about:networking#networkid.
2. Enable and connect to a WiFi network.
3. Disconnect from Lan.
4. Connect back to Lan and disconnect from WiFi.

Expected result:

1. A network ID is displayed as you're connected to a Lan network.
2. The previous network ID is shown.

Actual result:

1. No network ID is available.
2. The network ID remains stuck to the one that was displayed on the WiFi connection.

Update:

• for step 4 it either remains stuck or does not display the network ID

I think the network id remains the same because that both Lan and Wifi connect to the same gateway.
The routing table of my laptop which connects to both Lan and Wifi is:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.238.24.1        UGSc          113        0     en9
default            10.238.24.1        UGScI           2        0     en0
10.238.24/21       link#8             UCS             3        0     en9      !
10.238.24/21       link#11            UCSI            2        0     en0      !
10.238.24.1/32     link#8             UCS             4        0     en9      !
10.238.24.1        0:59:dc:a2:ee:51   UHLWIir        27        6     en9   1194
10.238.24.1        0:59:dc:a2:ee:51   UHLWIr          0        0     en0   1195
10.238.24.1/32     link#11            UCSI            2        0     en0      !
10.238.28.171/32   link#8             UCS             0        0     en9      !
10.238.28.222/32   link#11            UCS             0        0     en0      !
10.238.30.17       b0:19:c6:b4:70:5d  UHLWI           0        1     en9   1197
10.238.30.17       b0:19:c6:b4:70:5d  UHLWI           0        1     en0   1197
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1  4821145     lo0
169.254            link#8             UCS             1        0     en9      !
169.254            link#11            UCSI            0        0     en0      !
224.0.0/4          link#8             UmCS            2        0     en9      !
224.0.0/4          link#11            UmCSI           2        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en9
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0       80     en9
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0        4     en0
255.255.255.255/32 link#8             UCS             0        0     en9      !
255.255.255.255/32 link#11            UCSI            0        0     en0      !

On MacOS, the network id is calculated based on the MAC address of the default gateway, so if both Lan and Wifi network are connected to the same gateway (like the table above), the network id remains the same.

:bsurd, could you try to run the command netstat -nr when connecting to Lan and Wifi to see what the output is?
Thanks.

Yes, it would seem that the same gateway is used, but it still makes no sense to have no network ID when being connected to Lan without switching between networks.

It seems that network id is not calculated at startup, so network id is not shown on about:networking.
Could you try this build again and see if the problem is fixed?

Thanks.

Checked with the build from Comment 3 doing the following steps:

1. Start FF with a lan connection > about:networking#networkid > Network ID is available
2. Enable WiFi > Disconnect from Lan > Network ID remains the same
3. Connect back to Lan > Network ID remains the same
4. Disconnect from WiFi > Network ID is no longer available

So the build fixes part of the problem.

If restarting the browser or computer the ID field is populated again. If putting the computer to sleep and resuming without closing FF the network ID field does not populate.

I've added some logs and try to calculate network id again if it's empty in this build.

:bsurd, could you test again with MOZ_LOG=nsNotifyAddr:5 enabled? I'd like to see why network id is empty.
Thanks.

(In reply to Kershaw Chang [:kershaw] (OOO til 14.10) from comment #5)

I've added some logs and try to calculate network id again if it's empty in this build.

:bsurd, could you test again with MOZ_LOG=nsNotifyAddr:5 enabled? I'd like to see why network id is empty.
Thanks.

Thanks for Bogdan's logs. The reason that we can't get the network id is that we can't get the MAC address from arp table. From the log, I saw that the arp table is empty or no mapping to gateway's IP address.
The following log also shows that when IP address is changed, the network id calculated at 2019-10-01 14:27:22.616306 was failed and it succeeded at 2019-10-01 14:27:24.552780.

2019-10-01 14:27:22.613663 UTC - [Parent 1465: Main Thread]: D/nsNotifyAddr nsNetworkLinkService::IPConfigChanged
2019-10-01 14:27:22.613688 UTC - [Parent 1465: Main Thread]: D/nsNotifyAddr SendEvent: network is 'changed'
2019-10-01 14:27:22.615597 UTC - [Parent 1465: StreamTrans #2]: D/nsNotifyAddr routingTable succeded
2019-10-01 14:27:22.616259 UTC - [Parent 1465: StreamTrans #2]: D/nsNotifyAddr ipv4NetworkId failed
2019-10-01 14:27:22.616301 UTC - [Parent 1465: StreamTrans #2]: D/nsNotifyAddr ipv6NetworkId failed
2019-10-01 14:27:22.616306 UTC - [Parent 1465: StreamTrans #2]: D/nsNotifyAddr No network id
2019-10-01 14:27:24.552780 UTC - [Parent 1465: Main Thread]: D/nsNotifyAddr network id is empty...calculate again
2019-10-01 14:27:24.552941 UTC - [Parent 1465: StreamTrans #1]: D/nsNotifyAddr routingTable succeded
2019-10-01 14:27:24.552972 UTC - [Parent 1465: StreamTrans #1]: D/nsNotifyAddr networkid: MAC c2:ea:e4:90:29:da
2019-10-01 14:27:24.553013 UTC - [Parent 1465: StreamTrans #1]: D/nsNotifyAddr ipv6NetworkId failed
2019-10-01 14:27:24.553020 UTC - [Parent 1465: StreamTrans #1]: D/nsNotifyAddr networkid: id eLlILBUMjBCH1cQZC6AyyAfnu2k=

I guess that MacOS might need some time to create the arp table after IP changed. We might want to calculate network if with some delay after IP changed.

https://hg.mozilla.org/mozilla-central/rev/c90d49953a53

This has been verified and is working as intended.