The Proxy Problem

Posted by Scott on Sep 29th, 2011

The following originally appeared on the Yocto Project’s blog:

The Yocto Project’s developers have been working hard to improve the usability of our software, especially its “out of the box” user experience. One area that has admittedly been a thorn in our side is when users need to access the internet via a network proxy server*. I thought I’d take a few moments to explain the situation, why we don’t have a “silver bullet” solution yet, and how to work around it.

If your personal or corporate network doesn’t require you to use a network proxy to access the Internet, consider yourself lucky. Proxies complicate network communications, requiring special protocols (such as SOCKS) to pass your development computer’s packets out to the Internet and back. And while the “do one thing and do it well” design philosophy of Linux/Unix programs has allowed these utilities to weather the test of time extremely well, there is no universally adopted method of modifying the networking behavior of these programs when it comes to using proxies. Here are but a few methods Linux programs can be made to use a proxy server:

  • Some utilities check for a special environment variable (HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, etc)
  • Many desktop applications (e.g, GNOME apps) look for a proxy settings key in their global desktop registry
  • Others (like Subversion, or Mozilla Firefox) have their own config files or internal configuration dialogs where you have to specify proxy settings
  • Finally, some programs don’t contain any code for working with network proxies at all! In this case, you can sometimes get away with running the program under a separate, wrapper program which intercepts its network communications and automatically routes them through your proxy (tsocks is one of these wrapper programs)

I’m reminded of the saying: “Standards are like toothbrushes – everyone has one, but no one wants to use anyone else’s.” Truth be told, there is really no single solution to the proxy problem.

Another issue that poses problems for Yocto Project developers is that many of the proxy configurations for various tools (such as Subversion) are stored in the user’s own home directory. And modifying configuration files in your home directory is not something that will endear us to many users.

So what do you need to do to work with the Yocto Project behind a network proxy? Rather than filling this blog post with configuration tips, I’ll refer you to our wiki page, Working Behind a Network Proxy, where we make every effort to keep up to date with configuration tweaks needed for network proxy users.

If anyone can devise a way of reliably automating this process into a support script we could ship with the Yocto Project, we would be very open to including it. Just keep in mind that the script’s actions cannot clobber other config customizations a user may have, and would need to be fully reversible, to work for users who need to move in and out of proxied network environments.

* Note: a network proxy is different from a “firewall” – Yocto builds should work fine when run from behind a typical firewall router. Sometimes the terms “proxy” and “firewall” are used interchangeably, but they are quite different concepts.

DHCP Strangeness

Posted by Scott on Feb 2nd, 2007

I’m working with Debian Sarge (stable) on an embedded Linux device at work, and recently wasted a lot of time tracking down problems with DHCP. Specifically, the client was changing IP addresses intermittently during a DHCP lease renewal – not cool. So I put the device behind another Linux system running its own DHCP server, and found the following clue in the logs:


dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: ICMP Echo reply while lease 192.168.1.215 valid.
dhcpd: Abandoning IP address 192.168.1.215: pinged before offer
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 9 leases to leases file.
dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPOFFER on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPREQUEST for 192.168.1.210 (192.168.1.1) from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPACK on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1

Interesting… Some research (and help from the folks on the GNHLUG discussion list) uncovered that the client was sending a DHCPDISCOVER while still using the old address. When a DHCP lease is being renewed, the client is supposed to send a DHCPREQUEST, not DHCPDISCOVER.

So why on earth was it doing this in the first place? My only explanation is that the dhcp-client package that Debian Sarge comes with (v2) isn’t following the specification correctly. I have no idea how old that package is, but I do know that nearly all of the modern Linux distros I’ve used for years come with dhcp3-client. Fortunately, the Debian stable repositories include dhcp3-client – it’s just not the default client!

The lesson from all of this?: don’t assume that just because a package is in Debian’s default stable install you can take its correct operation for granted.

Blog Badges



[FSF Associate Member]

Archives