RoadRunner’s DNS wildcard at 24.28.199.152 breaks Samba
Today I tried to mount an smbfs share on my local network that has always worked before. I was greeted with the following error:
timeout connecting to 24.28.199.152:445
timeout connecting to 24.28.199.152:139
Error connecting to 24.28.199.152 (Operation already in progress)
5624: Connection to windowsbox failed
SMB connection failed
What? Why is Samba trying to connect to a machine outside of my LAN? And why that particular machine? My imagination conjures black hats and various compromise scenarios.
It turns out my ISP, Road Runner, has started using a DNS wildcard, which Road Runner is variously calling their “web address error redirect service”, or “non-existing domain landing service”, or “NXD”. This “service” is implemented automatically without the customer’s input, and it takes the input URL as a search term to return the same irrelevent, misleading, and downright useless search results you’ve come to know from domain parking. The searches are powered by Yahoo, and Road Runner takes a cut of the profits. You can opt out, apparently. The wildcard server is at 24.28.199.152, so that’s why that IP shows up.
But why was Samba doing DNS searches off my LAN, across the Internet? Well, I’ve now learned that’s default behavior for the whole Samba suite, including mount.smbfs and smbclient. Take a look at the “name resolve order” option in the smb.conf man page. The default setting prioritizes DNS requests over LAN broadcasts as a means of name resolution. I think that means that every time I’ve ever done an smbfs mount, I’ve sent a DNS request to Road Runner, saying “where is my windowsbox?” And in the past, Road Runner always said, “we don’t know”, so the smbfs mount command next tried broadcasting on the LAN, and then always found the target machine during that final step. I never noticed before, because Road Runner only recently started saying “hey, maybe your windowsbox is right over here at 24.28.199.152”, thus misdirecting Samba and breaking my network.
Well, let’s fix it. It’s easy. We’ll just add a line to /etc/samba/smb.conf and change the default behavior. We want to cut out DNS searches completely, and leave other behaviors untouched. Here’s the line:
name resolve order = wins lmhosts bcast
If you’re having similar problems, I’d recommend both fixing Samba, so the network stops leaking, and opting out of RoadRunner’s NXD junk.
speeding up tor
The Noreply Wiki has a very useful guide on how to make Tor faster. I’m working with revision 37, currently the most recent revision of the guide.
I started with Procedure 1, and altered about:config like so:
network.http.keep-alive.timeout:600 (300ms default is OK usually, but 600 is better.)
network.http.max-persistent-connections-per-proxy:16 (Default is 4)
network.http.pipelining:true (Default- false. Some old HTTP/1.0 servers can't handle it.)
network.http.pipelining.maxrequests:8 (No default)
network.http.proxy.keep-alive:true (Default- true, but double check)
network.http.proxy.pipelining:true (Default- false)
I’m going to skip all the suggestions about Fasterfox, because I don’t trust it to behave properly and not leak around the proxy, and I need to work with a lot of dynamic content anyway, which Fasterfox obviously can’t prefetch. I’m on Linux so I’m going to skip everything else in Procedure 2.
Procedure 3 is where this gets interesting, and where we actually start to make Tor faster, as opposed to making torified applications faster. The suggestions here really make a lot of difference in speed. I haven’t done any technical measurements, but I can see the difference very clearly when I’m browsing. However, though I haven’t tested, I suspect that I may potentially be sacrificing some anonymity for the increased speed. The authors of the guide note this is a possibility.
So I’m going to make two torrc configuration files, and I’ll use one when I need the best security I can get, and the other when I want speed and can afford to potentially be vulnerable to profiling attacks. For example, when I’m only concerned about the destination website knowing my IP, I can opt for speed. When I’m concerned about Big Brother, I can opt for security. This is simple to accomplish. I’m going to use Vidalia to switch between the two when I need to.
Vidalia’s torrc is at $HOME/.vidalia/torrc and I made a copy of it, in the same directory, called torrc-speed. The old torrc is going to remain unaltered; its defaults are secure. In the new torrc-speed, I added these lines:
# Try for at most NUM seconds when building circuits. If the circuit isn't
# open in that time, give up on it. (Default: 1 minute.)
CircuitBuildTimeout 5
# Send a padding cell every N seconds to keep firewalls from closing our
# connections while Tor is not in use.
KeepalivePeriod 60
# Force Tor to consider whether to build a new circuit every NUM seconds.
NewCircuitPeriod 15
# How many entry guards should we keep at a time?
NumEntryGuards 8
CircuitBuildTimeout, KeepalivePeriod, and NewCircuitPeriod are part of Procedure 3. I also added NumEntryGuards and increased it to 8 (the default is 3) because I want to give my speedy Tor the chance to pick faster entry guards if the low CircuitBuildTimeout means that some entry guards cannot be used. I don’t know whether this is actually necessary, nor whether it potentially decreases anonymity, but I don’t much care in this configuration. Save the file.
Then I went to Vidalia’s “Settings” screen and unchecked “Start Tor when Vidalia starts”. Then I went to the Advanced tab and pointed Vidalia at the new torrc-speed file. Then started Tor and tested it out. Yes, noticeably faster.
So now when Vidalia starts, it doesn’t start Tor yet, giving me the chance to go to the Settings > Advanced tab and change configuration files, to either the security or the speed configuration, before actually starting Tor.
vidalia on linux
Fedora 7:
Previously I had Tor running as a service, without Vidalia. That setup worked fine, but I also wanted a Tor controller, in order to easily change exit nodes. Since my Fedora 7 has GNOME already and not KDE, there’s no obvious solution. I could find a way to use TorK, or find a way to use Vidalia. I’m already accustomed to Vidalia, so that’s my choice.
Vidalia isn’t in the Fedora repositories, though, and it isn’t in freshrpms, an alternative Fedora repository. I didn’t want to dig anywhere else. I downloaded the Vidalia rpm directly from the Vidalia project page, and used their instructions. It says Vidalia requires nas, qt4, and qt4-x11. Why it needs nas I cannot guess, but that was already installed on my system. I used yumex to install qt4 and qt4-x11. Then I tried “rpm -Uvh vidalia-0.0.8-3.i386.rpm” but it didn’t work. I’m still a Fedora noob. I guess I have to install as root. That worked.
I wanted Vidalia to control the already-running Tor process that starts as a server, but I could not get that to work. When I thought I had it set up correctly with HashedControlPassword, Vidalia would just start up and kill the Tor process, and then complain “Vidalia was unable to register for Tor events. Control socket is not connected.” I don’t know. I gave up with this route and decided to just let Vidalia start its own Tor process. This meant I had to run “chkconfig tor off” to disable the service from starting.
Now I just start Vidalia when I want to run Tor. Privoxy is still a service.
Remember that Vidalia makes its own torrc file for the Tor instances it starts, so if you had settings you wanted to save, you have to copy them over. Look in $HOME/.vidalia for the file.
tor and privoxy
Get Tor and Privoxy running in Fedora 7:
I downloaded the most recent tor and privoxy, using pirut. Configured /etc/privoxy/config and made the following changes:
#logfile logfile #commented out this line
#jarfile jarfile #commented out this line
#debug 1 # show each GET/POST/CONNECT request #commented out this line
forward-socks4a / 127.0.0.1:9050 . #added this line
forward 192.168.*.*/ . #added this line
forward 10.*.*.*/ . #added this line
forward 127.*.*.*/ . #added this line
enable-remote-toggle 0 #changed this to 0 as suggested here
enable-remote-http-toggle 0 #changed this to 0
enable-edit-actions 0 #changed this to 0
Tor and privoxy are now installed, tor can be considered configured by default, and privoxy is now configured. But they aren’t going to run at startup. To make that happen, you have to run:
chkconfig --add tor
chkconfig tor on
chkconfig --add privoxy
chkconfig privoxy on
Actually I’m not sure that the “--add” commands are necessary. I’m kind of clumsy with this stuff. But I do know it all works after this; tor and privoxy will start on boot. I did make one change to /etc/tor/torrc to uncomment the line “Log notice file /var/log/tor/notices.log” which gives me the basic operational messages I’m used to seeing. After making that change it is necessary to execute “service tor restart”.
Later I may try to get Vidalia installed, but it’s not in the Fedora depos, so I’m not going to mess with it right now.
Incognito: a Tor LiveCD
I want to quickly give a plug for Incognito, a very handy anonymity tool. It’s a Live CD, which means you burn it to disc with a standard CD burning tool, then boot your computer with the CD in the drive, and this separate operating system starts up; take out the disc and reboot, and your normal operating system (such as Windows or Ubuntu) is running again.
The most notable feature of Incognito is that by default, all your network traffic is routed through Tor. This basically means that to prying eyes, snoopers, and eavesdroppers, your IP address is concealed.
For those users already familiar with Tor, the appeal of Incognito is to have a bootable anonymity toolkit available to you wherever you go, at any computer. It works very well, and as of right now, it is being actively maintained by the friendly Pat Double. Go check it out.
configuring laptop touchpad
I have a VGN-T250P laptop with some GNU/Linux distributions that I’m multibooting for a while until I decide which one to keep. First thing after install is to get the touchpad functioning properly so that I can work.
In Ubuntu 7.04 (Feisty Fawn), I used gnome-app-install (Add/Remove Applications) to install gsynaptics (Touchpad). It shows up in System > Preferences. It won’t work yet though; it throws an error: “GSynaptics couldn’t initialize.
You have to set ‘SHMConfig’ ‘true’ in xorg.conf or XF86Config to use GSynaptics”. This is remedied by editing /etc/X11/xorg.conf and adding the line:
Option “SHMConfig” “true”
under the section labeled “Synaptics”. You have to restart the X server then, which can usually be done easily by hitting Ctrl-Alt-Backspace twice. It’s a bit of an annoying irony that you have to manually edit the xorg.conf file to start a program that lets you avoid manually editing the xorg.conf file.
After GNOME’s touchpad configurator was running, the first thing I did was turn off tapping. Horizonal scrolling was off so I turned it on. This is the baseline of usability for me. Next is to deal with Firefox.
Firefox has a bothersome default behavior that many touchpad users complain about. Horizonal scrolling, which can be easily initiated with a casual finger swipe, causes the browser to jump forward and backward through the current page’s history, as though you were clicking on the arrow buttons. From reading the forums I found while troubleshooting, it seems many people misinterpret this and go looking for mouse gestures to turn off.
The solution is to go into about:config and change mousewheel.horizscroll.withnokey.action to either 1 or 0. Gentoo-wiki.com says that 1 enables normal horizontal scrolling, and I’m assuming that 0 disables any functionality. 1 works for me. Most every page I see in google says you also need to toggle mousewheel.horizscroll.withnokey.sysnumlines to true, but I cannot figure out why and it does not seem to make a difference on my system. Mozdev.org implies it’s irrelevant, saying “Scroll by a number of lines equal to system default?”
All the most annoying touchpad behavior is fixed now, but the cursor is still too slow. It does not move far enough across the screen for a quick finger swipe. Unfortunately, this is not as easily remedied as it should be. System > Preferences > Mouse does not seem to have any effect on the cursor speed in Ubuntu, although this method works fine in Fedora 7. The problem seems to be described by bug #118593.
It can be solved using synclient. Check the man page for syntax. I got the results I wanted with these settings: MinSpeed=0.3, MaxSpeed=1, AccelFactor=0.02 (different people’s hardware will need different settings). MaxSpeed must exceed MinSpeed or you get no acceleration. I found the most important setting was AccelFactor. Mine was originally set to approximately 0.006, and though adjusting MaxSpeed didn’t do much, AccelFactor made a big difference.
The changes from synclient are temporary and last only through the current Xorg session. You have to go into /etc/X11/xorg.conf and add the settings that worked for you, to make them permanent.
For Fedora 7, the above instructions can be followed (it’s only superficially different, if at all), except it’s not necessary to bother with synclient. GNOME’s regular mouse config app will work.
kkvv 