I use the following AppleScript to share my broadband internet connection with my USB-attached irDA adapter. This allows my Palm to use my network connection so I can sync AvantGo (modem sync) and download emails direct from my POP account on the net.
First you need to share your ethernet connection (don't know about modem dial-up) by pressing Start in the Internet tab of the Sharing control panel. Then edit the script below and insert the following details (all are needed):
Your Mac OS X password (you must be an administrator)
The name of your IrDA device. In a terminal window type ls /dev/tty*. Copy the one that starts tty.IrDA.
The IP address of your primary DNS server (for your internet connection)
The IP address of your Mac
An invented IP address for your remote device (e.g. Palm) that is not being used by anything else. Often just take your Mac IP Address and add 1 to the last number.
I have set up a G4 with OS X to serve as a file server in a mixed environment. For PCs with Win98, XP and NT to access the server, I had quite some config work to do with the Samba setup. Everything was smooth, but some PC users could still not authenticate with the OS X Samba server. While investigating the problem, I discovered some discrepancies with the generic Samba docs and the OS X Samba version with respect to password handling. Effectively, I had three options to change passwords for users on the OS X server:
Directly change the Unix password from a telnet session with asswd
Using the samba tool smbpasswd
Using an external Mac(!) with AppleShare and using the "change password" dialog there.
It turns out that the smbpasswd command had no effect at all, even if a /var -> db -> samba -> smbpasswd was there, it was ignored.
The method via AppleShare changed the Unix password and the Samba password stored as a hash code in /var -> db -> samba -> hash -> Username. It is this hash-file (and not the smbpasswd file) which controls the access to the server. The command smbpasswd however, does not change this hash file, only the AppleShare dialog was successful.
[robg adds: I haven't tested Samba connectivity from anything other than Win2K and WindowsXP boxes, so I can't verify these claims, but thought they might be useful to someone.]
I was looking at some of the previous hints and did not find anything useful as far as printing to a shared printer (CUPS) in Linux. I have an old Pentium that is set up as my Samba / share / printer / etc. Currently, Windows can print to it fine via Samba (check the docs - with newer Samba versions, it requires adding two lines to the smb.conf file). As far as adding the printer to your Mac (OS X 10.2.6), it's really easy (after you figure it out). Start by going to http://localhost:631/ with your favorite browser. Go to the Administration section and click on Add Printer. On the first screen with Name, Location, and Description, most of this is irrelevant. Pick a name, enter some descriptive info, and click Continue.
On the next screen, click the Device pop-up menu and select "Internet printing protocol (http)" and click continue. On the next screen, for the Device URI, enter http://192.168.1.1:631/printers/deskjet. Of course, you'll need to change the IP and name of the printer (mine is deskjet) to match your setup.
Then, make sure you select a driver that matches up with your printer, so you can change some of the printing options. I'm using a DeskJet 3420. Really inexpensive and works great.
I have a need to telnet into my OS X 10.2.8 machine from a Cisco router. I enabled telnet support in inetd.conf, and tests from other OS X and FreeBSD machines worked fine. However, trying to login from the Cisco (IOS 12.3.1) didn't work; as soon as I entered a username, the session hung.
The fix proved to be adding the -k option to the telnetd invocation:
-k This option is only useful if telnetd has been compiled with
both linemode and kludge linemode support. If the -k option
is specified, then if the remote client does not support the
LINEMODE option, then telnetd will operate in character at a
time mode. It will still support kludge linemode, but will
only go into kludge linemode if the remote client requests
it. (This is done by by the client sending DONT
SUPPRESS-GO-AHEAD and DONT ECHO.) The -k option is most
useful when there are remote clients that do not support
kludge linemode, but pass the heuristic (if they respond
with WILL TIMING-MARK in response to a DO TIMING-MARK) for
kludge linemode support.
By the way, the man page for telnetd doesn't appear to be correct - it covers some different options than telnetd accepts or lists if you run telnetd from the command line.
After installing a Windows 2003 Server and trying to mount a share in Mac OS X, everything was fine in Workgroup mode. However, after putting the Windows server 2003 in Domain Controler mode, I started to have get -5000 errors coming from SMB. The Macintosh File Server is installed.
After some searching, I found that after promoting a Windows Server 2003 to a Domain Controller, you must check the Domain Security Policy and de-activate the "Always secured connection" policy. I don't understand why, but after changing that setting, it works fine.
I picked up a new Netgear MR814v2 wireless router this weekend and an Airport Extreme card for the iMac. I set the router up with 128 bit WEP and my PC had no problem, but the iMac refused to connect, no matter how I configured the WEP key. It even failed with WEP disabled entirely.
After fighting it for a few hours I found the fix -- upgrade the router to version 5.0.1, and the Airport card will sync up happily with or without WEP.
I just worked my way through an interesting ordeal involving Windows file sharing and SMB. I was trying to select 'Windows File Sharing' in the Sharing system pref, but it wouldn't activate. I quickly checked Apple's support page on the issue and found I had already tried all the resolves (reconnecting to network, logging out, restart). I read a recent post on this site about checking the console to catch incoming errors. What I found was the following:
Starting SMB server
No such file or directory
So, after a futile Finder search, I used a utility to show hidden files and went hunting for the missing file. What I found where the file was supposed to be was a broken alias to the actual file. I hadn't hunted this deeply into the system before, so I didn't know yet that the actual file was supposed to be here. Well, after doing some research on the internet, I found that this indeed should be here. I'm stumped as to how the actual file was replaced with just an alias.
My first and simplest solution worked just fine: I have OS X installed on my FireWire drive, so I just changed my permissions for the etc folder on the affected volume, moved the clean file from the FireWire drive to the etc folder, and changed the permissions back (note the 'wheel' group). Now everything works fine again, and I even got a confidence boost thrown in.
I run a development Web server on my Powerbook and frequently test content on Windows browsers via Virtual PC.
When I'm not connected to a network (as is often the case for PowerBook users), I don't have an IP address (except 127.0.0.1), so VPC has no address it can use to connect to my local server.
Create an alias of your network IP address to the loopback interface (127.0.0.1). In the Terminal, type:
sudo ifconfig lo0 inet 192.168.0.1 netmask 255.255.255.0 alias
IP addresses have been changed to protect the innocent; replace 192.168.0.1 and 255.255.255.0 with your actual network IP address and subnet mask. VPC (or anything else on your computer) should now be able to connect sans network, but using your network IP address (192.168.0.1 in our example). To remove the alias, type:
NOTE: For any of the above to work properly, you will need to fix a now infamous VPC network bug. If you haven't done so already, enable the Scripts menu in VPC preferences and run the "Set Networking Type" script, and change the network type to Shared Sockets.
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:
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)
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.
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.