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 22.214.171.124 2224 [or]
$ echo test >/dev/tcp/126.96.36.199/2224
Note that the second example is a bash feature and may be disabled on some systems. In both examples, replace 188.8.131.52 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.
Under Tiger, this previous hint, to create a custom ipfw setup to write log entries to the /var/log/ipfw.log file, doesn't work -- it seems that program blocks inside syslog.conf are ignored.
However, the solution is to modify (just a little bit) the script you use to launch ipfw at startup (if you are using a custom firewall configuration, you know what and where that is). The modifications are to set the verbose parameter to 2, and to launch the ipfwloggerd daemon.
This is the code that accomplish the goal (some details may vary, depending on your setup):
I bought a Belkin ADSL modem and 802.11g router which came bundled with a USB wireless dongle. I wanted to use it with my iBook, which would take an original AirPort card, but why waste what I already have? After much searching and trying many possible solutions and modifiying countless plist files, I stumbled across a forum with a link to a driver download page for a list of wireless cards, and includes a driver for OS X 10.4 -- scroll down to the Mac section and find the USB driver for 10.4. This link (492KB) should download the current driver, dated August 28, 2005. There are drivers for 10.3 there as well.
I installed it and it worked the first time -- although I did need to switch off Tx Burst mode in the Advanced settings, and turn off IP6 in the Network System Preference. Enjoy!
I use PPPoE on an ADSL connection which is limited only by the modem sync speed (ie: no data rate capping by the ISP, on the downstream at least), and I wanted to optimise the MTU to get the best throughput. The consensus seems to be that the optimal MTU is 1454, based on the fact that 1492 the maximum possible, and 1454 is the highest value less than this which doesn't end up with any padding bytes in the last ATM cell. An ATM cell is the basic transfer unit over a DSL link, and they are all fixed length, padded out to this length if the packet doesn't end on a cell boundary.
I tried configuring the 1454 value using a couple of techniques mentioned on macosxhints, but they didn't seem to have much effect, at least not on the downstream packets. A little network tracing showed that Mac OS X PPPoE was still negotiating an MTU of 1492 with my ISP. So I did a little digging around and came up with the following solution...