GUADEC’16 report

I got a chance to attend GUADEC’16 which happened in Karlsruhe, Germany from 11 – 17 August. I stayed for the whole duration including Workshop Day, core days and the later BOF days which were very learning. I’m grateful to my mentor David Woodhouse who guided me all the time. I thank GNOME community for giving me the chance to speak at intern lightning talk and i tried my best to present my project in front of those great people. I hope to get a chance someday again to speak up. We have finished our GSoC project so i am free now to wander around to find some more places and tasks in GNOME’s huge shelter. My experience of attending GUADEC was awesome, despite being a less speaker i was very comfortable to talk and interact to people in the community. I made some new friends in the community and i came to know a lot more about it. I loved attending social events after the long day of great and motivating talks. I am thankful to the GUADEC organizers, i didn’t feel any problem for a second staying 6,000 kms away from home.

Now looking at the pics make me feels like missing those chaos and fun, which i do not want to miss in future. I look forward to see all of you again.

Here are some photos:

I again want to thank GNOME for sponsoring me to attend the conference. I hope to be useful and be an extra hand for the community in coming days.

Thanks 🙂



GSoC’16 Work Product

I spent my 2016’s summer doing a GSoC Project titled as ‘Proxies in NetworkManager’. I worked with NetworkManager team and also contributed to PacRunner which forms a very important part of this project.

I feel privileged to be mentored by David Woodhouse for the project. The project is more closely described here.

In short, the goal of this project was to bring proxies to be properly used and not to be skipped because of several issues the previous design had.

Milestones have been achieved in steps which are briefly pointed in:

Related Blogs:

Project required work in three packages and they are NetworkManager, PacRunner  and nm-applet.

PacRunner part was an independent and important one. The commit links of patches which i submitted and were accepted:

Patches that were submitted at the time of writing this blog:

Then i moved to NetworkManager daemon and submitted patches for proxy support:

The confirmation mail of patches being accepted:

When everything was working alright i stepped ahead and submitted patches for providing proxy feature via GUI (nm-connection-editor):

Patches are also stored in Google Drive Folder.


04-10-2016: Patches merged in NM master:

05-10-2016: Patches merged in PACRunner master:


Enjoy Proxying.

My last post explained proxy usage via GUI, but many times we are comfortable with command line. NetworkManager team provides us both of the ways to control NetworkManager daemon as nm-connection-editor (GUI) and nmcli (CLI) ,there is even a cursor based client : nmtui.  nmcli is usually the primary way to control NM, So providing a feature without nmcli support is an incomplete task. I have modified nmcli to allow users edit proxy setting via command line.

First see the list of connection:

[atulhjp@localhost ~]$ nmcli connection

Then initialize the proxy setting:

[atulhjp@localhost ~]$ nmcli connection modify <con-name> proxy.method none/auto/manual

Then add properties according to method (if ‘auto’) :

[atulhjp@localhost ~]$ nmcli connection modify <con-name> proxy.pac-url

If we try to add properties not valid for that method, nmcli will through a message like this:

[atulhjp@localhost ~]$ nmcli connection modify veth0+ proxy.http-proxy
Error: Failed to modify connection ‘veth0+’: proxy.http-proxy: this property is not allowed for method=auto/none

Message clearly says the ‘http-proxy’ is not for method=none or auto. We need to change method to ‘manual’. So, users don’t need to remember the properties for a method as nmcli won’t set it for unrelated properties and method.  🙂

If someone sets this:

[atulhjp@localhost ~]$ nmcli connection modify <con-name> proxy.method none

No Proxy will be used for that connection, WPAD obtained value is lost and if we set ‘auto’ WPAD obtained value is used unless someone overrides it by,

[atulhjp@localhost ~]$ nmcli connection modify <con-name> proxy.method auto

[atulhjp@localhost ~]$ nmcli connection modify <con-name> proxy.pac-url <overriding Url>

Proxy Feature will be available in NM in upcoming major release 1.4 .


GUI comes in For Proxies

My last post was an overview of how this project is designed to offer proxy features through NetworkManager. NM is the server part (which configures PacRunner) and PacRunner is there inside to act as an engine for doing all stuff (Interpreting, downloading PAC File etc) Applications can call FindProxyForURL() DBus method on PacRunner DBus interface org.pacrunner.Client .

NM is using org.pacrunner.Manager interface i.e CreateProxyConfiguration() and DestroyProxyConfiguration()  methods for configuring PacRunner with multiple configuration (one for each active connection!) . So our VPN has a separate proxy configuration and it won’t mess up with the LAN proxies. Clients just need to call the FindProxyForURL(url, host) in return they will be getting a copy of proxy server address to use for that URL.

The whole project sums up to give a GUI page per connection for proxies , GUI comes as a new tab in nm-connection-editor which many of us may be aware if they use GUI instead of nmcli. I’d also love to write bits for adding new proxy specific nmcli commands once i’m done with finding my code for above things inside NM.

GUI Modes:

I. None : User doesn’t want to use proxy for this connection (DIRECT internet)

I. Auto : Entries for Pac Url and Pac Script. If none of these is filled the one obtained from DHCP Server is given to PacRunner. If user want to override DHCP obtained WPAD value they just need to fill Pac Url and/or Pac Script entries.


III. Manual : Manual mode let users specify different proxy servers for different protocols and an entry for hosts for which they don’t want a proxy to reach i.e Direct internet connection.



Stepping towards Proxies.

Hello GNOME,

I’m doing a GSoC project this summer which in a single line is  to “handle proxies in our system”. Some of us may not have encountered this headache ever . The problem starts arising from the time we start thinking of multiple connections with proxies enabled . Firefox or any browser can’t be helpful in this case ( it doesn’t know which proxy to choose for an inserted URL). Env vars like http_proxy, https_proxy ? No!.  We can’t use a LAN thing with a VPN, so there’s no scope for a generic proxy ( Proxies are meant to be separate for each connection like all other network resources ) . So what we needed ?

  • Obtain Proxies for multiple connections .
  • Should “Just work” (behind silently).
  • Proxies shouldn’t be limited to browsers, available to all clients.

“Just Work” philosophy comes from NetworkManager which i understand is “minimize user input as much as you can” . WPAD via DHCP is the most efficient and safest way to maintain/obtain proxies for/from our networks . So, this project is basically performing WPAD from core of NetworkManager and store the details to a storehouse(say), Pacrunner in this case. Clients should be asking Pacrunner “what is the proxy for this URL?” , and Pacrunner will answer using the details stored by NM. Exchanges here take place via DBus.


To be in par with “Just Work” philosophy auto mode (DHCP->WPAD) will be default until someone opts for “manual”. So, there’s the plan to provide a simple window  for manually setting up proxies, if users want to override WPAD obtained value . I haven’t the UI design yet, we never worried for it . It will be simple with Entry fields (assume it to look as we have for firefox) but that would be available for each connection . We’ll simply need to $nm-connection-editor <return> , click on “edit” of whichever connection we like to edit , a tab named “Proxy” will be there .

I’m lucky to work with David Woodhouse as my mentor , a very-2 supporting person . Pacrunner part was independent and we have finished that, code is in master . NM part has been divided into two steps. We are almost done with writing the first part. I hope to see our code in NM as soon as i can do .