Wi-Fi + password


We are installing a device at a client that uses Wi-Fi. For security reasons, they have given us a username and password so that we can log onto a specific Wi-Fi and therefore the firewall will not block our access.

Using the file in the network folder, we can only define the network name and supply a password. We cannot define a specific username and password.

Any ideas how to go about getting the Wi-Fi working?

I’d check out the Network Manager reference - specifically https://developer.gnome.org/NetworkManager/stable/settings-802-1x.html

Hi @Elenach! I think @chrisallmark’s suggestion is on point. It might help if you asked the network admins what kind of security the network is using, which will help narrow down what NetworkManager configuration fields are relevant for this particular setting.

Thank you…we will try that!

Thank you! I will try it and let you know how it went

If I enter something like the attached, how would I enter it in the connection folder? All one line or does it accept line space.

Hi @Elenach not sure what do you mean by that question, one line of what? Is there a missing attachment?

To be clear, you can create a working NetworkManager connection settings file, and just copy it into the system-connections folder of the resin-boot or flash-boot partition as appropriate. Any working NetworkManager should be good.

In our case we supply a basic example since Wifi settings are relatively straightforward for most users, and that only needs the SSID and password.

In your case I’m guessing it’s a WPA Enterprise setup with username/password? Then maybe something like this would work? (haven’t tested, just reading up on it):







where you would need to replace <NAME> (the id of the connection, can be anything, I think, e.g. client-wifi), <SSID> with the the SSID to connect to, and the <USER>, <PASSWORD> as provided for you.

As I said, this is a guess! If your client’s not using “EAP”, but other kind of user/password authentication (e.g. LEAP or FAST, then you have to modify the settings). The best is to get more info from the client.

The most sure is getting a machine that is using Linux + NetworkManager, connect to the client’s network, and then working from that connection file that is created by NetworkManager in the case.

Thank you. We will give this a try. I’m almost certain it will work. Will keep you posted


To complicate things, certain clients have a Wi-Fi network bit to connect to the Wi-Fi network we have to enter a username, password and also click on their disclaimer to accept their terms and conditions.

After giving it some thought, i think it would be a lot simpler to have some kind of ‘light’ web browser that would allow me to enter their various requirements such as the username and password etc.

This way I cater for all kinds of Wi-Fi access variations.
Any ideas if there is something already in place to cater for this need?


So your client is using a captive portal.

This complicates things.

Depending on the portal you could:

  • write a simple script that does what a browser would do: submit a form with the user and the password (in javascript or python or whatever);
  • if the portal relies on the client being a real browser (to run some javascript for example), you’ll need to use a headless browser and send commands to it so it fills the fields, submits the form and clicks on ‘accept’;
  • or you could run a desktop on your device and open a regular browser to fill the form yourself each time the device starts.

None of these solutions are easy to implement in a reliable way, it would be much simpler if the device didsn’t had to interact with a portal targeted at humans.


So I tried the above solution but it did not work.
I’m keen to agree with you that it might be better to run a Linux device with network manager (I have read a bit about this) but I have never used it before.

I will give it a tey.



So i used the a raspberry pi with raspbian installed to connect to the wifi and obtain the necessary wifi settings. I used a simple wifi, which has a SSID password only. In the wpa.supplicant.conf, the only information it supplied was the SSID, PSK and Key_mgmt and also the details regarding the file that stores the information. For the connection information i have the following:

By coping this information to the connection file on resin does not seem to work. Im guessing i need the other fields as well such as the method, mode etc. Is there a file from the raspbian that has the information I need to use in resin?

Further to the above…please let me know if my understanding is correct.

So at the client, to connect to their Wi-Fi, you need to select the Wi-Fi (SSID). Then it takes you to a web page where you have to put a username and password. Once you enter all that, you are connected to the internet.

If I am not mistaken, the username and password is more like a security check before you connect to the Wi-Fi. So when you enter the correct details, the mac address is registered on the firewall and you are granted access. Am I correct?

So if that is the case, we thought to take the raspberry pi and use a SD with raspberian installed. From the GUI we connected to the clients Wi-Fi by entering all the credentials. We successfully connected to the internet. So in theory the mac address of the raspberry pi is registered.

We then replaced the SD card of the raspberry pi with the SD card linked to resin. We only entered the SSID in the connection folder. Because the MAC address is already approved on the firewall, we thought that this would work. But unfortunately it did not.

Should I have entered other credentials in the connection folder? We tried with the password and without but no luck

Captive portals have many different kinds of behaviours, so that above logic might not be correct. Quite often once a device is disconnected from the network, next time it has to go through the captive portal again. It’s not just the firewall, it’s all kinds of different behaviors that the captive portal’s creators came up with…

In general accessing captive portals protected networks automatically are not an easy problem to solve - since the purpose of a captive portal is to prevent automatic access…

As my colleague pointed out earlier, the best would be e.g. if the customer’s network could whitelist your device, so it doesn’t have to interact with the portal at all.