After spending a day fiddling around with ports and Bonjour to get a USB printer attached to an AirPort Express to print from my XP Desktop, I finally figured it out. It was my XP firewall software; I disabled it, and could at last print. The firewall I was using was the Zone Alarm freebie version; I'm now reliant on the XP built-in firewall along with Spybot, AdAware, and Mozilla, but at least I can print.
I hope this helps someone else -- there's a lot of stuff out there about printer configuration, port fiddling, and using Bonjour, but in the end, it was nothing to do with any of that. It was a simple software issue...
The story goes that, in 10.4, you could set up a LEAP-authenticated wireless network as a preferred network in the Network preferences pane. Some time later (and I'm not sure when, maybe 10.4.1) when you tried to do this, the network would not remember that it was LEAP, and then failed to authenticate.
I recently had the pleasure of finding out about this problem. Fortunately, Apple published a workaround. The short version is to choose "WEP Password" as the security type for the network, then specify your LEAP login in the password field. OS X will interpret this as a LEAP login and use it. Hopefully the behavior is fixed in future releases.
I have several machines that I routinely transfer files between. After a rebuild of a PowerBook, I was unable to upload files successfully (but I could download files without issue.) The error indicated that I did not have permissions to upload. I spent a lot of time looking at owner, group and other settings between the machines, all to no avail...
Then, I realized that in the rebuild of the PowerBook, I had created a "testuser" account first, and then constructed my usual user (we'll call it "user") account. This meant that testuser had a User ID (UID) of 501, and my user account had a UID of 502. This, apparently, was a the root of my problem when transferring files between my PowerBook and all my other machines (all of which had a UID of 501 for my user accounts).
A problem I ran into while trying to connect a simple network of a Mac running OS X 10.4 to a PC with Windows XP via a crossover cable was that if I wanted to share my dial-up internet connection from the Mac to the PC, I had to enable DHCP on both machines. While this is great in concept, I found that the machines would not agree with each other, and assigned different subnet masks and IP address ranges to each other.
This meant I could not share files between the computers while DHCP was enabled. So here is my solution:
Set the IP address and subnet mask on all computers to DHCP, except for the Mac that will be sharing the internet connection. Make sure to note which subnet mask and IP address range is assigned to these computers.
Configure the Mac connecting directly to the internet to use "DHCP with a manual address" in the network preference pane, and give it an address in the same range as the rest of the computers in the network.
Apply the changes -- after a few seconds, the Mac should assign the correct subnet mask. I'm not sure whether it is necessary to restart internet and file sharing or not.
File and internet sharing should now work correctly. The only problem I have encountered is that I cannot browse shared folders on the network in the Finder from the Mac with the internet connection -- I have to know the address of each shared folder and mount each one manually using Go -> Connect to server. So I have just added favourites to all the shared folders on the network to the "connect to server" window. Obviously, this may not be practical if the network is large with a large number of shared folders.
If any of you have your Mac sitting on a network with other PC users, you may know how frustrating it can be to share files through Samba. While the /etc/smb.conf file that Apple provides is useful, setting-up an effective public share requires some tweaking. I could not find the necessary tutorial on how to solve my problems on this site or elsewhere, so I decided to write this hint once I figured out how to get things working they way I wanted them to.
This hint has been tested with OS X 10.4.2 only, so I don't know if this will work or is helpful on other systems, though I imagine it is. It would be worth knowing if the backup config file, /etc/smb.conf.template, is significantly different for different versions of OS X.
For those who don't know, LittleSnitch is a great application that lets you block outgoing network connections. It's very useful to stop apps (such as trojan horses) from "calling home." The problem is I often log into home via ssh, and want to use stuff like curl, for which I do not want to define a specific rule and would rather have LittleSnitch ask me every time.
Say I want to install something remotely using Fink; I can't, because there's no way to tell LittleSnitch to let curl connect to the mirror. So I came up with a little AppleScript UI script to fix this...
I use VNC on an XP box at work to connect to my Mac at home. The speed isn't too bad, but I've found a very simple (and once you know, completely obvious) way to increase the connection speed. I had all manner of fancy images used as desktop backgrounds on my Mac. Last night, I switched the background to a flat colour only, and the increase has been almost astronomical.
Like I said, a very simple and obvious hint.
[robg adds: For those who don't know, VNC is a way to control one computer's GUI from another location. RealVNC is the official home of the software, but they don't offer a Mac server (just PC/Unix servers and clients). Redstone Software, though, makes an OS X VNC server called, simply enough, OSXvnc. There used to be quite a few Mac clients, but the only one I'm aware of with any recent activity is Chicken of the VNC (CotVNC).
You may see another speed boost if you tell your VNC client to only display 256 colors. In CotVNC, you do this via the Connection -> Connection Profiles menu option, then click on the Colors tab. Even if you can't stand 256 colors, try Thousands instead; you should still see an increase in rendering speed.]
Ever wanted to send text snippets from one machine to another via the Terminal? Save this XML code to a file named pbcopy.plist in your user's Library -> LaunchAgents folder (note that you'll probably have to create the LaunchAgents folder).
Next, execute this command in Terminal (or just logout and login):
Now you'll be able send any text over the network right to the clipboard on this machine via nc (netcat) or bash, like this:
$ echo test | nc -w1 220.127.116.11 2224 [or]
$ echo test >/dev/tcp/18.104.22.168/2224
Note that the second example is a bash feature and may be disabled on some systems. In both examples, replace 22.214.171.124 with the IP address of the receiving Mac (the one running the XML code), and make sure your firewall allows access to port 2224.
This is very convenient, but also very insecure. However, if you add the following lines to the pbcopy.plist file, between the dict tags in the Listeners section, then it will listen on only the loopback interface:
Once that's done, you may access the service from a remote machine on 127.0.0.1:2224 if you ssh there with this option in the .ssh/config file:
RemoteForward 2224 127.0.0.1:2224
This one is a default for all my ssh connections, because very often I need to transfer a lot of text output to my local machine from many kinds of unixes. Unfortunately, Terminal's cut-n-paste can't handle this without breaking lines or truncating the text to the size of the scroll buffer.
Another trick -- if you installed SubEthaEdit and its command line tool called see (/usr/bin/see), you may put that program in the .plist (instead of /usr/bin/pbcopy), and then the editor's window will pop-up with the text content that was sent.
[robg adds: I tested this, and it worked quite well ... very well. I was able to accept text from anywhere on the net, as tested by friends in The Netherlands and Montreal. I suggest that if you implement this, you use the ssh restriction, as it does seem somewhat insecure. To remove the agent, use launchctl unload ~/Library..., then delete the file.]
Some places, like universities, require that you be connected to their VPN servers in order to do stuff like check email through a non-webmail client or access certain resources they give you. My school uses the Cisco VPN Client. So I just leave the VPN connection up and running constantly. But sometimes I want to be able to connect to my home machine from on-campus machines. Normally, this would require that I write down my VPN IP address, since there's no existing mechanism for updating a DynDNS hostname with an IP address assigned by Cisco's VPN Client. That is, until now.
Here's a quick sub-hint. If you don't want to deal with the Cisco VPN GUI being open in your Dock all the time, use the command line client. Open your Terminal and type screen and press Enter. This will take you to a new screen session. Press Enter again after reading all about the wonderful screen utility. At the new prompt, type vpnclient connect [profile_name]. Enter your username and password to connect. Once you've established the connection, you detach the screen session by pressing Control-A and then Control-D. The first keeps the session active in the background, and the second detaches the screen into its own background process. You can then quit the Terminal. If you want to check back in with your screen session, type screen -r.
Okay, on with the real hint. I started with the DNS updater utility in this hint, written by Robert Miller, and modified it (view source) to grab the IP outputted by the command line VPN client. Most of the commented-out code was my experimentation with Keychain integration. Unfortunately, unlocking the Keychain requires a graphical context, which this utility does not have when run as a periodic process with cron or launchd. (I will cover setting this up later in the hint.)
I'm running a few services on my Mac at home: Timbuktu, for remote access to my Mac while away from home; accessTunes, for music streaming; ssh shell access; and I'm playing around with the Apache web server now.
Normally, all of these services work fine. I've configured my gateway/router to do all of the appropriate port forwarding. I've also recently set up a dyndns.org account so that I have a domain name for my home system, making access much easier.
However, all of these services used to go to hell when I started up my VPN connection from home into my office network. I could still access these services using other computers on my home network, but from the outside world, nothing would work. This was particularly frustrating if I'd left the VPN running by accident, got to work, wanted to connect home, and couldn't get in -- especially to do the one thing I'd really like to do at that point, which is to shut down the VPN.
I finally figured out what was going on: All of these services were happily listening on their assigned ports for incoming connections on both my LAN IP (through which all WAN access arrives) and on the VPN-assigned IP. But, when these services sent replies, they tried to reply back through the VPN to every client with a non-LAN IP address -- in other words, a request comes in one pipe, but the reply to that request get sent out down a different pipe, and never gets received. What I really want to happen is for all replies to go to the LAN IP except those which are replies to clients with IP addresses associated with other systems on the VPN.