I have access to Macs on two Windows networks that I visit regularly. All are running MacOS X, and all are able to work well with the networks in question - from the Mac end, that is. I have never been able to authenticate to any of the Mac from any of the Windows computers, despite following all the rules, until very recently.

The solution, and as far as I can make out this is undocumented, involves the following:

1. Make certain the Macs are part of the Windows domain (use Directory Access (in /Applications -> Utilities) to change from WORKGROUP to match the Windows domain name)
2. This is the key step. Rename the account to which you are logging in to DOMAINUsername (you'll probably need Root access to do this). For example, if your username is John Doe and the Domain Name is Foo, rename the Mac account to FOOJohn Doe. The short login name stays unchanged, but that's OK.
3. Log into the Mac from a Windows machine using the short name and password you have always used for the Mac account.

I haven't seen this trick mentioned anywhere else, but the standard approach of simply checking the "Allow User to log in from Windows" in the User Preferences pane has never worked for me on either of the Windows networks I visit. I'd love to hear of a better solution, since the limitation of this approach being that it allows access only to the resources in the account in question, not other general-access folders on the hard disk. But hey, it works.

[robg adds: I access my Mac from my work XP box regularly, and I didn't have use step #2; I did have to set the domain to match, but once that was done, I can login as my standard user with full admin privileges to see the whole hard drive ... can anyone shed any light on why this doesn't seem to work in all cases?]

The short version: If you are given a hex key (password) for accessing a WiFi network (generally a long string of numbers and letters), just add 0x (zero x) in front of the hex key and insert it into the 'password' field. The longer version: I spent most of the day yesterday trying to get my iBook on our company WiFi. When I was asked for the password by the Airport Setup Wizard (or Internet Connect) to access the network (that was found right away), my engineers gave me a long string of numbers and letters (hex key). This is how it apeared in the Windows setup.

Now, usually you can convert hex to ASCII text (with an app like MacASCII Display X) and get the password in plain text. But knowing that AirPort will convert ASCII passwords to hex automatically, if you give it hex from the start, it won't work.

Anyway, seeing that the hex key that was given to me was equivalent to obscure text characters, I was told that if you add a 0x (zero x) in front of the hex string, it should work ... and it did indeed. In the AirPort password field, I simply added 0x in front of the hex string key, and it worked perfectly.

After testing port scanners on OS 10.2.6 using the built in firewall (IPFW), and then trying Brickhouse, I did some further investigation into the details of IPFW.

I hope that my rules below, which enable the stateful behavior of the firewall are more secure than the default or Brickhouse default rules. You can, of course, use Brickhouse to implement these rules:

allow ip from any to any via lo0
deny ip from any to 127.0.0.0/8
deny ip from 127.0.0.0/8 to any
check-state
allow ip from any to 255.255.255.255
allow udp from any 67-68 to any 67-68
allow icmp from any to any in icmptype 3
allow ip from any to any keep-state out
deny ip from any to any

[robg adds: To add these rules using ipfw in the Terminal, you'd use ipfw add allow ip...etc -- see man ipfw for more information. Note that I have not tested these settings. Comments on their validity, anyone?]

If you are getting -47 errors when connecting to a Windows machine using an SMB URL, try relaunching the Finder and your shares should appear on your desktop. My suspicion is that the error occurs when the share is mounted, but not visible in the Finder. If the Finder is relaunched, the share appears on the desktop.

I can get up to two connections to a Windows 2000 SMB share. If I disconnect those two connections from Windows, and then try to connect again from the Mac, I will get a -36 error message. If I relaunch the Finder, though, then both shares will appear on the desktop.

This morning I was trying to help a friend set up the FTP server in OS X 10.2. In particular, we were trying to get ftpchroot (see this hint) working, which restricts FTP users to their home directory. As noted in the referenced hint, it's relatively easy to set up, but after creating the proper file, any attempt to FTP was met with this:

% ftp 192.168.10.10
Connected to 192.168.10.10.
220 192.168.10.10 FTP server (lukemftpd 1.1) ready.
Name (192.168.10.10:robg): robg
331 Password required for robg.
Password:
550 Can't change root.
ftp: Login failed.

A little Google searching found this page, which explains the cause of the problem:

Internally, the bug is caused by changing the effective userid of the ftpd process to the user logging in before invoking the chroot command. Unfortunately, the chroot command can only be done by the root user, which is the user into which ftpd is first launched. It would be interesting to see the details of the original bug to see if it was creating a security issue or just an inconvenience.

The solution, also detailed on the same page, is to replace lukemftpd, Apple's chosen FTP server program, with an earlier bug-free version. Instructions are provided to build from source (you'll need an Apple Open Source ID to get the files), or you can use the author's precompiled binary.

Others will comment, of course, that you can avoid all these problems in the first place by just switching to proftpd, which about which I've heard good things (though I don't do much with FTP, so I haven't installed it myself). If one were to do this, however, I don't know of a method of changing the Sharing preferences panel such that it launches proftpd instead of Apple's built-in FTP server.

I have a D-Link 614+ and the 800AP access point setup in my apartment, with a G4 tower at the 614+, and a 12" PowerBook wirelessly connected. I was having problems connecting to file sharing if I was connected to the access point, but not if I was connected to the 614+ itself; there were no other problems.

I figured out that even though i had the tower connected via Ethernet to the 614+, it was being given two IP addresses: one for Ethernet, and one for AirPort. This didn't impact any other operations, but for some reason, it just wouldn't work conecting through the access point. I turned off AirPort in the tower, and the problem was solved. I'm sure this affects a very small number of people, but it was very frustrating and I didn't find any info about it on the web.

If you are using the Cisco VPN client 3.7.x with the GUI, you might have noticed that when it is installed, your network won't return from sleep. After having to reboot every time this happened, I got frustrated. Apparantly this problem is fixed in version 4.x of the client, but you can't get it from Cisco unless you have a Cisco support contract, and our network security guys don't want to upgrade to 4.x just yet. So aside from black hat methods, I am stuck with 3.7.2.

If you lose your network after waking from sleep, here is an easier way to get it back than a reboot. Run these two commands in Terminal (or your favorite terminal application):

sudo ifconfig en0 down
sudo ifconfig en0 mtu 1500 up

Most Macs with one network card should have their card at en0. If your card is not at en0, substitute which interface you want to reset. I am assuming that if you have multiple ethernet interfaces, you can figure out which one is which.

Also, the MTU setting *could* be different for you. 1500 is the default, but who knows what your ISP or network guys or yourself might have set. So if you are concerned you can just type ifconfig en0, which will spit out your current network configuration. Somewhere in there, usually near the end of the first line, you will see your MTU setting, and you can adjust the above commands to set it back to that same value.

I am sure that you could wrap all this into an AppleScript application or something. For some reason, turning the interface off and back on again from within System Preferences doesn't do the trick.

If you need to get out onto the Internet via a connected Windows XP/2003 machine and don't have your WiFi Access Point or a Blutooth Access Point for your Apple Powerbook G4, here's a cheap alternative. I had a spare Epox BT-DG02 Bluetooth dongle laying around that I configured to accept PPP over RFComm (Bluetooth), and let me surf away. Read the rest of the hint for the setup instructions...

[robg adds: I haven't tested this one...]

Windows NT, 2000, and XP have built in LPD printing, but Windows 95, 98, and ME don't. However, using the free LPD-Win utility available online, you can still print from a Mac to a printer connected to a Windows machine. This tutorial explains how to set it all up.

I work for a tech consultancy that likes to stay on the bleeding edge, and we recently upgraded to Windows Server 2003 and Exchange 2003, wreaking havoc with my ability to connect to Windows network shares (via Finder or the command line) and to Exchange via Entourage's new quasi-native Exchange implementation.

The fix for file sharing turned out to be that Windows Server 2003 now digitally signs all SMB packets to prevent "man in the middle" attacks that intercept and modify packets. This feature breaks compatibility with all Samba versions prior to 3.0 (still in beta), which includes Apple's Windows file sharing (currently based on Samba 2.2.3a). So to allow Mac, Linux and other clients to connect to shares on a 2003 box, you (or your Windows server admin) will have to disable digital signing of SMB packets in the appropriate local or group permissions area depending on your server setup. After that, the old Finder -> Go -> Connect to Server... works like a charm. Whenever Samba 3.0 becomes stable enough for Apple to use it, you may want to turn packet-signing back on again.)

Getting Entourage syncing with Exchange 2003 (still in pre-release) was trickier because IMAP4 and WebDAV aren't enabled by default in 2003. Again, you or your Windows admin will have to enable these depending on local and group permissions. target=_blank>This document on Microsoft's Mac web site gives some configuration tips. It's still not the missing Outlook X (no task lists, no viewing other people's contacts, only mail folders work as public folders since they have to be shared out by IMAP), but mail folders, calendar, appointments and contacts all sync up automatically with Exchange, which is 98% of what I need.

Also, although I've heard of problems connecting to Samba servers in a Server 2003 environment, I've had no trouble using a Windows machine to connect to either my Mac or our Linux servers via SMB -- although these are all standalone servers which aren't configured to do external LDAP/Active Directory authentication or to act as master browsers or domain controllers.