User:Pavlix

Mail: psimerda AT redhat DOT com, pavlix AT pavlix DOT net

Jabber: pavlix AT pavlix DOT net

IRC Freenode: pavlix (#nm and a couple of other channels)

Phone: +420 775 996 256

Timezone: Europe/Prague (CET), sometimes available through later hours

About

After learning a bit of programming, I was attracted by the networking world. I got from petty Pascal/C++ projects through web development using ugly PHP and later Python, to a freelancing work with most of the projects in server administration, network equipment configuration and a bit of programming. Most people in the business know me from my conference talks and articles.

One of my conference talk brought me an offer from Red Hat, which I joined in May 2012 to work on NetworkManager. I was already a Fedora user and package maintainer at that time. Since August 2012 I'm no longer working as a regular NetworkManager developer (staying an upstream contributor, though). Even before that I tried to put my hands on a number of other projects via bug reports, tests and code. I'm also interested in various network-related standards and especially bugs and bad assumptions in IETF documents.

Wiki resources

• Networking – A starting point for information related to networking.
• Tools/NetworkManager – NetworkManager information page.

Contributions are welcome.

Packages

Maintainer

• aiccu (IPv6 tunneling client)
• connman
• racoon2
• radvd (taken over from Petr Písař)
• strongswan

Co-maintainer

• bind
• bind10
• NetworkManager-ssh
• rsync
• squid

Upstream contributions

• NetworkManager
  • Building on any distribution
  • Virtual device support (bridging/bonding, with others)
  • Valgrind and code coverage support for tests
  • Separate platform interaction module (nm-platform, with Dan Winship)
    • Refactored NetworkManager's bridging/bonding/vlan configuration
    • Refactored NetworkManager's IPv4/IPv6 configuration
  • Userspace IPv6 autoconfiguration (nm-rdisc/libndp, with Jiří Pírko)
    • Getting IPv6 autoconf features on par with IPv4
    • Avoiding loads of kernel IPv6 bugs and design flaws
  • Runtime (non-persistent) configuration support (with Dan Winship and Dan Williams)
  • A lot of bug triaging

Bug tracking/reporting

• avahi
• glibc
• kernel
• libnl

Daily usage

Distributions

• Gentoo
• Fedora/CentOS
• Debian
• OpenWRT

Desktop

• Gnome 3 – Seeking something more mature and stable
• Gnome Terminal
• Evolution (for IMAP/SMTP mail) – Seeking something more mature and stable
• Empathy/Telepathy (for jabber and IRC) – Seeking something more mature and stable
• Evince
• Firefox

Development

• vim
• gcc
• make, autotools
• gdb
• valgrind

Presentation

• LaTeX/Beamer

Linux networking

I'm currently working on the following (may be outdated):

• New platform interaction framework
• NetworkManager upstream QA, bug triaging (component general) and bits of documentation
• Virtual device support (bridging, bonding, etc)
• Fixes and improvements for getaddrinfo() in glibc
• Configuration formats
• Building NetworkManager on any distribution without unnecessary hassle
• IPv4 and IPv6 automatic configuration improvements (NDP and DHCP)
• Various NetworkManager fixups and cleanups (like anyone else in the team)
• Various linux networking improvements

When working with linux networking, the following projects cause me headache:

• NetworkManager itself: I need to test NM in a virtual environment with bridges. These are not supported in the current release. I hope to make the next release mature enough to support its own development.
• Kernel: The kernel IPv6 networking layer is somewhat unmanagable. The rtnetlink interface doesn't provide enough funcionality to support IPv6 networking.
• GLIBC: The getaddrinfo() function doesn't work properly and is not supported in nsswitch.conf. It breaks whenever my development machine happens to be on an IPv4-only network.
• nss-mdns (Avahi nsswitch plugin): Can't implement link-local name resolution because of the above problem in GLIBC.
• IETF networking standards: For some reasons many IPv6-related standards have serious design flaws that prevent them from working properly.