Enterprise / Campus Network Setup Issues (Symptoms & Diagnosis)

I’ve checked through the forums and was unable to find this specific problem anywhere else. This topic is similar, but these users already were able to observe photon network access before their device went into flashing cyan.

I’ve been banging my head against getting my new photons onto the campus network where I work. I am unable to “claim” the photon through the mobile application - but only on our campus network. I’ve taken a photon home, and it worked on my home network right away, so it’s not problem with the photons themselves.

While on our campus WiFi, I am successful in connecting the photon through the Android app and can apply the Wifi configuration, then the Photon disconnects as expected and then goes from flashing green to flashing cyan - but never solid cyan. The Android Application indicates that it’s connected to the cloud for a brief period, but does not verify ownership and then exits with an error.

I got a batch of 10 photons, and we’ve tried 5 of them in our lab, with a few different configurations of access points, network configurations and different WiFi settings to try to fix the problem. We’ve also reflashed two of the photons through DFU mode to see if they just had bad firmware, but with no improvement.

After rigorous wireshark captures, I thought it was an issue with the DHCP handshake because the last (broadcast) packet I saw on the network before the photon went silent was a DHCPACK from the router. I was blaming the DHCP server at that point, but then realized that the device probably had switched to unicast mode now that it has an IP address, thus I would need to sniff the traffic directly.

I enabled a SPAN session on our Cisco switch and started up wireshark again. Dumping the traffic, I saw the following:

So even though our lab’s DHCP server was providing a DNS Server for it to use for DNS queries, the photon was still firing out traffic to Google’s DNS Server (8.8.8.8).

For home networks, this is usually not an issue - most residential ISPs allow DNS requests to alternate servers, but this is not the case on our campus. For security reasons, our network team blocks many network services on campus and only allows DNS requests to their own servers. Thus, the outbound request to 8.8.8.8 is dropped as soon as it leaves our lab.

I’m not much of a firmware guy, so I am unsure if this setting is configured by the Android application when it sets up the device or if its baked into the firmware itself. In any case, forcing DNS traffic to an external server may be a silly idea if Google ever decides to remove their 8.8.8.8 DNS service (though I don’t see why they would).

Can anyone shine any light into why the photons don’t use the DNS server IP address provided in the DHCP handshake?

2 Likes

Can you make the .pcap file available for me to look at ? Feel free to message me directly, if you’re not comfortable posting a link to the pcap publicly.

I see the photons on my test network adopt the DNS server(s) that the DHCP server names.

There is an internet test [system/src/system_cloud.cpp:Internet_Test()] that will try to open a tcp connection to 8.8.8.8:53, but that’s a hardcoded test (that in your case will almost surely fail), and not an actual DNS request.

1 Like