OpenBSD Journal

Love the new dhclient changes - and so I was inspired...

Contributed by pitrh on from the walkabout puffy dept.

Bob Beck (beck@) writes in with news of the refreshed dhclient(8):

This is a fan letter for my fellow developer Ken Westerback (krw@). Ken is currently partway through the thankless job of modernizing dhclient - it's already much better, and I think it will be really good for 5.3 an will probably take on new life afterwards with more improvements.

If you're like me, and run around with an OpenBSD laptop, dhclient has been the bane of my existence.
My mac or windows machine just attaches to the networks I want, OpenBSD does not. This displeased me greatly. Every time I moved off of one wavelan, or plugged in a wired network, it would usually get something wrong, most always resolv.conf - it would use the wrong resolv.conf for where my packets were going.. grr. The net result was usually pkill dhclient, restart.. manually set nwid, etc. etc. pain - swearing - wishing someone would fix it.

After some discussion in New Zealand, krw managed to fix it up - basically the dhclient in current only puts in resolv.conf if it is dealing with the current highest priority default route - with this change it's awesome, resolv.conf changes seamlessly as my machine switches from wired to wireless interfaces, I never need to restart dhclient, just leave it running.. sweet.

However now there was one little thing missing, so, this afternoon, (needing a distraction from sticking my fingers in uvm) I managed to cook up something I'll share with you all. It's a teeny little shell script that I run now and it seems to work pretty darn good. It simply watches for a wireless interface to not be "active" and when it sees that, it tries in order, a list of nwid's you keep in a file (potentially with keys..) I also made it run a little activate script after associating and waiting for dhclient to do it's thing so that I could manage to send recorded "click this to agree" http POST responses to automate annoying captive proxy requests.

I'll share at http://foad2.obtuse.com/beck/wifinwid

Read the comments to figure out how to use it..

Anyway, I now roam seamlessly between my preferred wireless nets and my debug syslogs just shows:


Feb 7 19:49:06 rocinante wifinwid: interface iwn0 appears inactive
Feb 7 19:49:06 rocinante wifinwid: trying ifconfig iwn0 nwid bob
Feb 7 19:49:10 rocinante dhclient[25994]: DHCPREQUEST on iwn0 to 255.255.255.255 port 67
Feb 7 19:49:11 rocinante dhclient[25994]: DHCPREQUEST on iwn0 to 255.255.255.255 port 67
Feb 7 19:49:11 rocinante dhclient[25994]: DHCPACK from 192.168.41.3 (00:0d:b9:1a:ae:3d)
Feb 7 19:49:11 rocinante dhclient[25994]: bound to 192.168.41.129 -- renewal in 21600 seconds.
Feb 7 19:49:11 rocinante dhclient[25994]: Unexpected DHCPACK from 192.168.41.3 (00:0d:b9:1a:ae:3d). State #4
Feb 7 19:49:12 rocinante wifinwid: attached to network bob on interface iwn0

Thanks muchly for the dhclient changes that made this practical Ken!


Editor's note: An exclusive Undeadly.org interview with krw@ is in the works, stay tuned for further updates!

update
Yeah, I looked at daniels wiconfig..

... and it wasn't what I wanted. - not to mention that my laptops hav iwn wireless controllers that scan never works on. - hooray for proprietary firmware! I did *not* want to do stuff based on signal strength, I have a user-preferred ordering that I want, just like what I get if I'm using that on osux, or windows and crud.

I also didn't want to deal with running stuff from apmd, because I wanted to just leave dhcp running and let it deal with it, and have it notice when I wander out of range without a suspend. So I just monitors the interface in the background and notices when it isn't "active". then it starts trying. Works better for me. All I do (with -current dhclient) is i have a hostname.iwn0 looks like:
dhcp
nwid bob
!/usr/local/bin/wifinwid iwn0 &
and I basically never touch it, just works, and with my little activate scripts spitting the "yes I agree" post response for two of those networks which have captive proxy bullshit in front of them, I never get annoyed by the silly "click this to agree" or "log in to this completely insecure page with the password you can't change" crap anymore.. it just gets blatted at it when the network gets used.. - and my ssh's reconnect to my tmux sessions and life is good.
YMMV.

(Comments are closed)


Comments
  1. By Peter J. Philipp (pjp) pjp@solarscale.de on http://centroid.eu

    If someone has the right SSID then they can get you to initiate an authentication packet exchange. How secure are those? Is the AP trusted immediately? Is there anything the "attacking" AP can glean in terms of passwords? I don't know myself but I've always been wondering about that... I don't want to put down your script either, but I wonder if it's wise to let a script do automatic authentication attempts when only the SSID (nwid) matches, shouldn't the channel or the strength of the signal be checked too?

    Comments
    1. By Anonymous Coward (anon) on

      > If someone has the right SSID then they can get you to initiate an authentication packet exchange. How secure are those? Is the AP trusted immediately? Is there anything the "attacking" AP can glean in terms of passwords? I don't know myself but I've always been wondering about that... I don't want to put down your script either, but I wonder if it's wise to let a script do automatic authentication attempts when only the SSID (nwid) matches, shouldn't the channel or the strength of the signal be checked too?

      You can add bssid/chan to the lines in the config file. But at some point you've got to realise you're dealing with a situation where somebody who can listen to the radio transmissions is able to duplicate any of the publically broadcast information at which point you need to look at a proper way to authenticate the access point (e.g. EAP-TLS).

      Comments
      1. By Peter J. Philipp (pjp) on http://centroid.eu

        > You can add bssid/chan to the lines in the config file. But at some point you've got to realise you're dealing with a situation where somebody who can listen to the radio transmissions is able to duplicate any of the publically broadcast information at which point you need to look at a proper way to authenticate the access point (e.g. EAP-TLS).


        What I meant rather was if the access point that this script connects to is "rogue" ie. an impersonator. I did a bit of reading since my post and I understand EAP-TLS is a secure tunnel, however if a rogue access point is being used to establish the tunnel then they got all the values (like private key/public key for the TLS), what is tunneled inside that I don't know. I do understand the authenticator nonce is manipulatable to always be the same number as it's picked by the rogue. I just don't know if it would help someone rogue then to easily compute the PSK.

        Location where an access point should be connected to should matter. You don't try to connect to "ualberta" or whatever access point in germany. Perhaps a smart script looks at GPS info to doublecheck it's really on a u of alberta campus, if that can't be done perhaps cross check all other access point beacons in range to determine that this is really the place to pull out password and attempt authentication?

        Thanks for your reply, it really helps me understand this better.

        -peter

        Comments
        1. By Anonymous Coward (anon) on

          > What I meant rather was if the access point that this script connects to is "rogue" ie. an impersonator.

          Understand that.

          > I did a bit of reading since my post and I understand EAP-TLS is a secure tunnel, however if a rogue access point is being used to establish the tunnel then they got all the values (like private key/public key for the TLS), what is tunneled inside that I don't know. I do understand the authenticator nonce is manipulatable to always be the same number as it's picked by the rogue. I just don't know if it would help someone rogue then to easily compute the PSK.

          The authentication in this case can be from both sides; if the AP's certificate isn't signed by a trusted CA the client can refuse to connect.

          > Location where an access point should be connected to should matter. You don't try to connect to "ualberta" or whatever access point in germany. Perhaps a smart script looks at GPS info to doublecheck it's really on a u of alberta campus, if that can't be done perhaps cross check all other access point beacons in range to determine that this is really the place to pull out password and attempt authentication?

          This is a great idea, I like it a lot. Checking beacons might be complicated for many setups, but GPS could be quite straightforwards - it sounds like something that would be very useful to include in mobile phone/tablet OS too and it could be nicely integrated in the UI. Any android devs reading? :)

          Comments
          1. By Bob Beck (beck) on


            While an interesting exercise, for me (and I suspect many people who think about it) WPA stuff and the like is not about security, and I certainly do not depend on it to secure anything I care about. So frankly, I don't really care about "imposters" because I don't really
            care about trying to get around flawed "wireless security" mechaisms.

            Doing what I'm doing I won't hand keys out to imposters any more than
            a windows or mac machine already will. And since they're already out
            there and I certainly can't fix them, the barn door is open and the horse
            has left (except in the case of enterprise WPA supplicant type goo which in theory is secured by TLC certificates to prevent this.... if the client isn't set to "don't care about the certificates, checking is hard") The long and the short of it is, all of these mechanisms either suck in principle, or are complex, bug prone, and challenging to deploy securely given that lusers are lusers.

            SSH and ipsec are your friends.



  2. By Wesley MOUEDINE ASSABY (wesley974) wesley@mouedine.net on www.aise.re

    There's also a pretty script developed by Daniel MELAMETH to configure wireless connection easily :
    http://home.melameth.com/~daniel/pub/wiconfig

    Comments
    1. By Anonymous Coward (thomasw_) on http://www.flickr.com/photos/thomasw_/


      You rock for doing the dhclient development, Ken; and ... Bob, thanks heaps for the nifty script and the fun-to-read update! Between this and my hope for what is coming in the smtpd of the next stable release (i.e., will sendmail be replaced in the default install?), the 5.3 cd release is one for which I am very eager....

  3. By David Coppa (dav.cop) d.coppa@findomestic.com on

    Using ``\$if'' is even better ;)
    dhcp
    nwid bob
    !/usr/local/bin/wifinwid \$if &
    


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]