- WLUG - wlug.mailman3.com

OpenWRT on WNDR3800 home router - my install thoughts
by joel d 04 Nov '13

04 Nov '13

Decided to try OpenWRT after Jim Getty's talk and strong recommendation last month for improved security and reduced local buffer bloat. What follows is my experience / thoughts from this process. I would happily bring the hardware to demo at a future meeting if there is interest. Likely wouldn't be a full meeting but a 10-15 minute filler. More likely Q&A than anything else. I decided to go with different router/firewall hardware so I bought a Netgear WNDR3800 which Jim mentioned and is also a favorite of the OpenWRT crowd. Mine was used and $50 shipped from e-bay. This model is one model old and no longer available new. FYI: Netgear website lists it as "out of support". My WNDR3800 was used prior, so I needed to do a hard firmware reset on the bottom of router with a paperclip (didn't know the prior IP used or the admin password). Once reset and rebooted, router worked fine and could login to the "default" Netgear firmware and configuration. Default username & password is printed under the router. Downloaded the recommended OpenWRT firmware for this model. Needs to be full "factory" (instead of partial upgrade) and squashfs is recommended. Netgear WNDR3800 Firmware download link gets you OpenWRT version 10.X version which is not latest OpenWRT. Web browser login to Netgear webpage/firmware and followed "upgrade firmware" link while pointing to OpenWRT download file on local disk. The upgrade/re-flash took around 4 minutes and after a reboot worked fine. Set password and reconfigured router and WIFI with my specifics. Was up and working on OpenWRT v 10.x. Next day realized I had OpenWRT, but not latest stable version. Upgrade firmware link does not go to Internet directly, so first download OpenWRT v 12.4 with "upgrade" and "squashfs" and save to local disk. Second apply this via upgrade button in OpenWRT web link. I could likely have saved a step by grabbing the OpenWRT v12.4 for WNDR3800 with factory and squashfs. I bet this would have worked had I tried it (and saved a step). General thoughts after use for a week: OpenWRT does not have an "update direct to mother ship" feature best I can tell that downloads file and updates it from web interface. Not a show stopper for me. Instead need to know your version of OpenWRT and download an "upgrade" file and apply as two steps. This would only matter if router was used/maintained by a non-geek. Prior problem occurred with similar hardware WNDR3700 with latest Netgear firmware (happened with prior Linksys also). A few embedded WIFI devices in home would disconnect and fail randomly and at least weekly. Thus far these device annoyances have not occured since swap to WNDR3800 and OpenWRT. No idea why, but definitely A win! OpenWRT has transmit power level settings for the WIFI radio transmit. Can decide to bump up the WIFI radio settings if user chooses. Even if you melt/destroy them, a cool option if needed & tested. Firmware update for OpenWRT works from a laptop on WIFI, which in my experience Netgear & Linksys and other vendors do not support flash without a cabled ethernet port. So the OpenWRT update scripts the 1) copy file 2) apply file 3) reboot device. My Next Steps: In another week will likely repurpose the WNDR3700 likely as a WIFI gateway for the "cheap WIFI radio" devices, (mainly TV, roku, DVD, etc.). Not yet sure if I will use OpenWRT for this. Look into the option of external antennas for the WNDR3800. I live out in the country and have few neighbors to notice/know/care. If I can get there... improved & reliable WIFI signal at my mailbox would rock.

3 2

Idiot Service Providers
by Keith Wright 23 Oct '13

23 Oct '13

On recomendation from someone on this list, I signed up for Speakeasy DSL. The helped me set up a primary name server (DNS) and they ran a secondary name server for a few extra dollars per month. This has been working well for about a decade. Speakeasy was sold to MegaPath, who yesterday sent me a message that included this: > Dear MegaPath Customer, > > This email is to advise you that MegaPath is > migrating its legacy Speakeasy ISP, web hosting, > webmail and DNS services to a more advanced platform. > > <Braindead "customer-experience" > happy market-talk deleted> > > Going forward, we will no longer support secondary > DNS services. If your domain is set up in this > manner, please be sure to make the proper changes to > avoid a post-migration service disruption. This all happens next Tuesday. I read this is "We are breaking what has worked for a decade, there is nothing you can do, have fun finding a new ISP in two days." I was wall-punching cursing mad. When I calmed down a bit I began to think, if they don't break anything else, maybe it's not so bad. The system was designed to tolerate failure. _I_ was not designed to tolerate _intentional_ failure, but everything should still work if the secondary name server is broken. Since I have only one IP address on one DSL line, I never really saw the need for a secondary server in the first place. I run a primary server because (A) I like to think of myself as a programmer, and it is self education to figure out how to do it. (B) Sometimes I create subdomains and run test program servers in them. The RFC's require a second name server, and the registrar asks for it, but who's going to care really? If the primary name server goes out, so do all other servers in the domain, since it's all really just one computer. What would you recommend? If anyone else has the same problem, I could be your secondary, and you could be mine. -- Keith

3 4

Barbarians at the gates...
by Tim Keller 21 Oct '13

21 Oct '13

This is a paper about High Frequency Trading, it's an interesting if not entirely terrifying read about what a crazy place the markets have become. http://queue.acm.org/detail.cfm?id=2536492 Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

1 0

Bufferbloat demonstrations w/water and funnels
by Chuck Anderson 14 Oct '13

14 Oct '13

Here is a series of videos of a talk by Dave Täht where he uses water and funnels to demonstrate the concepts of bufferbloat: [1] Bufferbloat #1 - TCP 101 [2] Bufferbloat #2 - Tail drop queueing [3] Bufferbloat #3 - FIFO, RED, Blue, and Fair Queueing [4] Bufferbloat #4 - Wifi, Netalyzr, SFQ, SFQRED, and CoDel [5] Bufferbloat #5 - CoDel and Drop Head Queueing [6] Bufferbloat #6 - More on FQ_Codel [7] Bufferbloat #7 - Q&A [1] http://www.youtube.com/watch?v=KD5TwLQnq_8 [2] http://www.youtube.com/watch?v=PgFcqRMDqlk [3] http://www.youtube.com/watch?v=Y9xJbwb28Zc [4] http://www.youtube.com/watch?v=ol_BcKA9Ohg [5] http://www.youtube.com/watch?v=R8Esi0zjNdE [6] http://www.youtube.com/watch?v=bi-jumVNVGk [7] http://www.youtube.com/watch?v=JFH5fGNzBJU

1 0

Changing your network scheduler in ubuntu 13.04...
by Tim Keller 14 Oct '13

14 Oct '13

Just so people know... this is how to change the scheduler on Ubuntu 13.04. tc qdisc replace dev eth0 root fq_codel limit 100 target 5ms interval 30ms ecn Obviously replace "eth0" with your appropriate network device... Enjoy, Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

1 0

Reminder: WLUG Meeting Wed 10/9 7PM Jim Gettys on Internet buffer bloat
by Chuck Anderson 07 Oct '13

07 Oct '13

Hi folks, The next Worcester Linux Users' Group (WLUG) meeting will be held this Wednesday. This month we will have Jim Gettys from Bell Labs talk about Internet buffer bloat. This is the talk that has been rescheduled from April. Note that there has been a room change to a larger room right down the hall from our regular location. Wednesday, October 9, 7:00 - 9:00 PM WPI Campus Center, Hagglund Room 301 The Campus Center is building #7 on the campus map [1], and the Hagglund Room is room 301 on the Campus Center building floorplan [2]. [1] http://www.wpi.edu/about/visitors/campusmap.html [2] http://www.wpi.edu/Admin/CC/Floorplans/37678.htm "Internet buffer bloat, by Jim Gettys (Bell Labs) VOIP and teleconferencing often perform much more poorly on today's Internet than the Internet of a decade ago, despite great gains in bandwidth. Lots of fiber, cheap memory, smart hardware, variability of wireless goodput, changes in web browser behaviour, changes in TCP implementations, and a focus on benchmarking Internet performance solely by bandwidth, and engineer's natural reluctance to drop packets have conspired to encourage papering over problems by adding buffers; each of which may introduce latency when filled. The mistaken quest to never drop packets has destroyed interactivity under load, and often results in actual higher packet loss, as TCP's congestion avoidance algorithms have been defeated by these buffers. The lessons of the "RED manifesto" of 1997 have been forgotten or never learned by a new generation of engineers." Wednesday, October 9, 7:00 - 9:00 PM WPI Campus Center, Hagglund Room 301 Afterwards, we will go out for pizza. See you there, Chuck President, Worcester Linux Users' Group http://www.wlug.org/

1 0

Announce: WLUG Meeting Wed 10/9 7PM Jim Gettys on Internet buffer bloat
by joel d 03 Oct '13

03 Oct '13

I plan to attend Wednesday's meeting also (90% likely at this point). Joel

1 0

Announce: WLUG Meeting Wed 10/9 7PM Jim Gettys on Internet buffer bloat
by Chuck Anderson 03 Oct '13

03 Oct '13

Hi folks, The next Worcester Linux Users' Group (WLUG) meeting will be held at its regularly scheduled time: the 2nd Wednesday of the month, which is Wednesday, October 9, at 7PM. The location will be the WPI Campus Center, Mid-Centry Room 331. This month we will have Jim Gettys from Bell Labs talk about Internet buffer bloat. This is the talk that has been rescheduled from April. "Internet buffer bloat, by Jim Gettys (Bell Labs) VOIP and teleconferencing often perform much more poorly on today's Internet than the Internet of a decade ago, despite great gains in bandwidth. Lots of fiber, cheap memory, smart hardware, variability of wireless goodput, changes in web browser behaviour, changes in TCP implementations, and a focus on benchmarking Internet performance solely by bandwidth, and engineer's natural reluctance to drop packets have conspired to encourage papering over problems by adding buffers; each of which may introduce latency when filled. The mistaken quest to never drop packets has destroyed interactivity under load, and often results in actual higher packet loss, as TCP's congestion avoidance algorithms have been defeated by these buffers. The lessons of the "RED manifesto" of 1997 have been forgotten or never learned by a new generation of engineers." Wednesday, October 9, 7:00 - 9:00 PM WPI Campus Center, Mid-Centry Room 331 Afterwards, we will go out for pizza. See you there, Chuck President, Worcester Linux Users' Group http://www.wlug.org/

10 10

Keysigning Party -- what to do AFTER
by Chuck Anderson 19 Sep '13

19 Sep '13

So you've attended a keysigning party and diligently checked people's key fingerprints & IDs. Now what should you do? Here is an overview of the process you should follow: 1. Sign: Look at the checklist you made at the Keysigning Party. For each user where you checked off that you verified their key information & ID, you need to import their key, verify the imported key's fingerprint matches the printout/notes that you verified at the party, sign their key(s), and send them back to them, preferrably signed+encrypted to their key. 2. Import: As you receive your signed key(s) from other people, import them to your keyring and then upload them to a keyserver. 3. Refresh: Periodically refresh your keyring from a keyserver so you get local copies of other people's keys with any additional signatures that were added since you last refreshed. Detailed instructions for each step: 1. Sign: Configure GPG to always ask for the certification level. Before signing keys, it is a good idea to set your GnuPG configuration to always ask you what certification level to assign to each key you sign. This indicates to others how carefully you verified the person's identity before you signed their key. If you don't do this, GnuPG will default to 0 which means you make no particular claim as to how careful you were. Edit $HOME/.gnupg/gpg.conf and add the following to the end: ask-cert-level You can also optionally change the default (in case you don't want to be asked every time): default-cert-level 2 1a. Sign: The CAFF Method. The easiest way to do this is to use CAFF (CA Fire & Forget) from the pgp-tools package on Fedora, or the signing-party package on Debian/Ubuntu. After installing the pgp-tools or signing-party package, you need to configure CAFF. In order to create your initial .caffrc, just run "caff" once. caff Then edit the .caffrc file in your home directory. The minimum settings you should set are: $CONFIG{'owner'} = 'YOUR FULL NAME'; $CONFIG{'email'} = 'YOUREMAIL@FOO'; $CONFIG{'bcc'} = 'YOUREMAIL@FOO'; $CONFIG{'keyid'} = [ qw{YOUR-KEY-ID YOUR-OTHER-KEY-ID-IF-YOU-HAVE-ANY} ]; $CONFIG{'local-user'} = [ qw{YOUR-KEY-ID YOUR-OTHER-KEY-ID-IF-YOU-HAVE-ANY} ]; $CONFIG{'also-encrypt-to'} = [ qw{YOUR-KEY-ID YOUR-OTHER-KEY-ID-IF-YOU-HAVE-ANY} ]; $CONFIG{'default-cert-level'} = '2'; # as above, but for CAFF specifically Note that the KEY-IDs CAFF wants are 8-byte ones rather than the usual 4-byte. Just use the last 16 digits of the fingerprint. You can also customize the email message body that CAFF will send out with each signed key. Then you just run CAFF like this: caff 0xKEY-ID1 0xKEY-ID2 0xKEY-ID3 ... ... etc to sign all those KEY-IDs. You can run it once for each person/key, or list every person's KEY-ID on a single run. CAFF will prompt you to sign people's keys one by one (which you should only do after you verify the fingerprint against your paper copy from the Keysigning Party), then it will email the signatures for each uid (email address) separately to that email address, signed+encrypted to that user. That proves that the user who can receive email at that email address, and who can decrypt the message, is the only user who can get the signature for that user/uid/email, and that is the only way they can get the signature for that uid/email (as long as you don't send your signed copy of their key to a keyserver or anywhere else--leave that to the recipient). 1b. Sign: The Manual Method. It is tricky to do the above manually without CAFF, but if you don't want to run CAFF or can't for some reason, you can sign the key and then export the signed key with gpg --export. Ideally, you should then encrypt that and send it to at least one of the email addresses listed in the uid(s) if not all of them. This is not as good as the CAFF method, because it only proves that at least ONE of the uids/email addresses is controlled by the user who has that key, and the person who controls that ONE email address can get your signature on ALL of the uids/email addresses. These commands should work for the manual method. First verify that the fingerprint matches your printout or notes from the Keysigning Party: gpg --fingerprint 0xRECIPIENT-KEY-ID Now sign the key: gpg --sign-key 0xRECIPIENT-KEY-ID Now export their key, signed+encrypted to both them and you. Store the result, ascii armoured, into a file: gpg --export 0xRECIPIENT-KEY-ID | gpg --encrypt --sign --armour --recipient 0xRECIPIENT-KEY-ID --recipient 0xYOUR-KEY-ID - > 0xRECIPIENT-KEY-ID-signed-key.asc You can verify that this came out right before emailing (since you signed/encrypted it ALSO to your own KEY-ID above) with the following: cat 0xRECIPIENT-KEY-ID-signed-key.asc | gpg -d | gpg --list-packets And you can import it to a test keyring to see the signatures like this: cat 0xRECIPIENT-KEY-ID-signed-key.asc | gpg --decrypt | gpg --import --keyring=testring.gpg --no-default-keyring gpg --list-sigs --fingerprint --keyring=testring.gpg --no-default-keyring Now that you've verified it is all correct, just attach the .asc file to an email and send it to the user's email address(es). 2. Import signed keys other people send you and then upload them. When you receive emails from other people with your signed key(s) (hopefully signed+encrypted in the email) you should import them as follows. If the sender used the CAFF Method, the entire email will be signed+encrypted and you can import the key like this: cat encrypted-email.asc | gpg --decrypt | gpg --import If the sender used the Manual Method, you will have a signed+encrypted attachment that you can import like so: cat 0xYOUR-KEY-ID-signed-key.asc | gpg --decrypt | gpg --import Now you should send your key back to a keyserver with the new signature(s) you just added: gpg --keyserver=subkeys.pgp.net --send-key 0xYOUR-KEY-ID 3. Refresh: Periodically refresh your keyring from a keyserver. In order to reap the benefits of the Web of Trust, you need to download other people's public keys so you can take advantage of the signatures on those keys to verify other people further out in the Web. As people upload their keys with additional signatures on them, your local copies become out of date so you need to refresh them to gain the additional signatures, any revocations, etc. To refresh a single key, just download that key from a keyserver: gpg --keyserver=subkeys.pgp.net --recv-key 0xKEY-ID To refresh your entire keyring (do this sparingly as it does place quite a load on the keyserver): gpg --keyserver=subkeys.pgp.net --refresh-keys That's it!

1 0

Follow up from key signing
by Eric Martin 19 Sep '13

19 Sep '13

Hi WLUG and BLU, I have signed all of the keys I have access to. If you haven't received an email from me, it's because either a) I can't get your key, or b) the email with your signed key was lost. Please email me directly if you're expecting a signed key from me. A few people expressed interest in the suite of tools I'm using to make signing easier, and also some visualization tools I'm playing with. They're all based on Debian's pgp-tools which can be called keysigning-party on your distribution. Hands down, the most useful tool is CA Fire and Forget or caff. It's in most distributions, and if it's not in your distro (or you're on a Mac) it's pretty easy to build. Just checkout it out from svn://svn.debian.org/svn/pgp-tools/trunk, and do a make all && make install clean Now that you have caff installed on your machine, it's time for some tweaks. Go ahead and run caff by typing caff at the command prompt. This will setup the folders and files you need that we'll be tweaking. 1) I *highly* suggest making a symlink from ~/.gnupg/gpg.conf -> ~/.caff/gnupghome/ via ln -s ~/.gnupg/gpg.conf ~/.caff/gnupghome This will have caff use your preferences in gpg.conf and it makes it easier to configure / use the way you want to. 2) edit ~/.gnupg/gpg.conf and set your default key, default keyserver (most of them sync with each other so it's not a big deal, but I prefer pool.sks-keyservers.net since it handles subkeys very well.) Also to note, keys can prefer certain servers so don't worry if gpg is asking a few different servers where things are. Also, if you haven't already, set your preferences for algorithms, hashes, and compression. *NOTE* this only applies to making new keys. You should still set the proper preferences on your key via gpg --edit-key <KEYID>. Lastly, I like to add ask-cert-level so gpg (and therefore caff) ask me what certification level to give to each signature 3) edit your ~/.caffrc file to customize your name, email address, and email template / procedure for signing keys. Caff looks for 16 digit keyids, not 8 so punch in the last 16 of your fingerprint for you key. Also, I like to bcc myself on the emails in case a message gets bounced so I can resend it easily via Thunderbird 4) Once those are edited and saved, you're all set! Grab your trusted list, and feed caff one or more keyids to handle via caff <KEYID> <KEYID> <KEYID...> Don't forget to verify the fingerprint caff / gpg show you with your trusted list. I'm attaching my gpg.conf and .caffrc files for those of you who are interested. I should probably put this up as a wiki / blog post at some point in time to I can go back and update / clarify it. Also, check out: sig2dot (included in pgp-tools / keysigning-party) which is a visualizer for the Web of Trust http://pgp.cs.uu.nl/ for PGP trust paths Cheers!

1 0