Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Localtalk and PPP over Ethernet at once on 10.2.3 Network
In 10.2.3, Appletalk is its own network port (which goes against my understanding of the term port, as it's really just a protocol over the ethernet port). As such, all three (Modem, Ethernet, and Appletalk) can be used simultaneously and Appletalk / Localtalk devices can be used and auto-detected while also accessing IP devices. Prior to 10.2.3, you had to choose either PPPoE or Appletalk in the Network Preferences, but could not access both over ethernet.

An example of how this can be useful: I've got an old TI printer connected to an Asante Ethernet / Localtalk bridge. My Internet connection is a DSL modem. I run the bridge and modem to a basic ethernet hub and out to my machine. Prior to this, I had to disconnect from my DSL modem to reconfigure my network settings using Location Manager and some scripts to connect to the printer (actually, it would randomly connect to both at times, but never reliably and it would reset on reboot). Now I can just print as you'd expect.
  Post a comment  •  Comments (8)  
  • Currently 1.50 / 5
  You rated: 1 / 5 (4 votes cast)
[6,965 views]  View Printable Version
Word file naming issue when copying to Samba shares Network
I ran into a little gotcha when copying some Word documents to a Samba share on my FreeBSD box. I'd copy the documents, the icons would appear in the destination window, then they'd quickly disappear. As it turns out, the first line of each document was the title and included an em-dash, thanks to Word's AutoCorrect feature. When I saved the document, I accepted the default filename, which meant that there was an em-dash in the name instead of a hyphen.

Of course, this isn't immediately obvious in Finder. This caused is what caused the problem when copying a file to a Samba share. The fix is to rename the file and replace the em-dash with a hyphen.

I'm just submitting this one because I spent a bunch of time debugging such an obscure problem. Perhaps it'll save someone else the aggravation.
  Post a comment  •  Comments (1)  
  • Currently 3.33 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (3 votes cast)
[3,193 views]  View Printable Version
Resolve internet issues with shared AirPort networking Network
blish a proper internet connection.

After doing some research and with help from other Mac users, I learned that in Mac OS X there is something missing called MSS-Clamping to fix broken web pages. See this article for more details. Until Apple fixes this with a newer BSD version, the easiest thing to fix this is to set MTU for AirPort on the second Mac (not the Mac with the internet connection!) from 1500 to 1492. If you think you have the same problem you can try:
 sudo ifconfig en1 mtu 1492
If this fixes your problem, you can make the change permanent with a StartupItem I made.
read more (217 words)   Post a comment  •  Comments (5)  
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
[10,789 views]  View Printable Version
Prevent .DS_Store file creation on UNIX shares Network
If you mount unix servers via samba you probably end up with .DS_Store files all over the place. A way I found to keep those from showing up is to 'veto' these files in the Samba config. In the [global] section of smb.conf of the server I am mounting I added:
 veto files = /.DS_Store/
[Editor's note: I haven't tested this one yet...]
  Post a comment  •  Comments (18)  
  • Currently 2.50 / 5
  You rated: 2 / 5 (6 votes cast)
[31,291 views]  View Printable Version
Workaround identd requirement over AirPort Network
identd is a user identification protocol specific in RFP1413 which many applications require, even though it is untrustworthy and useless and easy to get around. That said, many applications will require that a valid response is received in order to work properly. In my case, it was IRC (Internet Relay Chat) servers.

Normally you can enter a Terminal session and use pico with sudo to edit the /etc/inetd.conf to change the line
#ident stream tcp wait root /usr/libexec/tcpd identd -w -t120
auth stream tcp wait root /usr/libexec/tcpd identd -w -t120
However, when you are using an AirPort base station, the process your are responding to won't like the IP address it is getting back. An easy solution is to install Brian Young's nullidentd. Read the rest of the article for the how-to...
read more (84 words)   Post a comment  •  Comments (11)  
  • Currently 3.00 / 5
  You rated: 5 / 5 (4 votes cast)
[7,555 views]  View Printable Version
Remove servers from Connect to Server menu Network
This may be simplistic but it was driving me nuts till I solved it. It seems that all past servers are in the list when you hit Command-K to select a location on your network. Over time, some of the servers change ... new names for work stations, new machines, etc. There is no way to delete the old names from the "Connect to Server..." window.

Solution: Go to the ~/Library -> Recent Servers folder and throw away the servers you want to delete. Next time you use "Connect to Server...," they will be gone.
  Post a comment  •  Comments (1)  
  • Currently 2.25 / 5
  You rated: 2 / 5 (4 votes cast)
[6,247 views]  View Printable Version
Change an orphaned node's IP via the command line Network
After we subnetted our network, my network parent domain was orphaned (e.g. NetInfo busted). I couldn't get to it through the GUI client. So, I used nicl (which was good, wholesome fun). Here is an output of what I did to fix the problem (NetInfo kept the IP even though I changed the IP in the GUI Directory Services and Netinfo Domain Setup):
[files161:/var/db/netinfo] root# nicl -raw network.nidb/
/ > cd machines/Files161
/machines/Files161 > read
name: Files161
serves: ./network Files161/local
/machines/Files161 > append . ip_address
/machines/Files161 > read
name: Files161
serves: ./network Files161/local
/machines/Files161 > delete . ip_address
/machines/Files161 > read
name: Files161
serves: ./network Files161/local
/ > search . 0 3 ip_address
Search found 0 matches
One problem -- the passwords were bad (the admin user and two regular users that I tested could not login) . I'm guessing this is because the crypt uses something based on IP?? Hmm. Anyway, I had to delete all the entries and import a backup copy I made.

[Editor's note: You can probably do Very Bad Things to your machine with this program, so be very careful ... "have you hugged your backup today?"]
  Post a comment  •  Comments (0)  
  • Currently 3.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
[2,757 views]  View Printable Version
More on printing to a Win XP shared printer Network
I have a very nice Epson printer connected to my living room computer running WinXP. I tried every one of the hints posted here designed to let me print to it from my Mac running Jaguar, but no luck. Then I ran across a posting on the internet about how to set up an LPD daemon on XP. Since I use an LPD spool on my Linux server at work, I gave it a shot and it worked perfectly!
read more (235 words)   Post a comment  •  Comments (22)  
  • Currently 2.00 / 5
  You rated: 2 / 5 (9 votes cast)
[137,156 views]  View Printable Version
Solving a shared printer and hostname problem Network
For months I was frustrated that a perfectly working Brother laser printer on our home network could not be used from other machines via Printer Sharing. The printer would show up (thanks to Rendezvous) in other machines' Print Centers, but attempts to print to it from them would fail with messages like "IPP0: Undefined error." The machine to which the printer is attached also hosts a domain, But I had always referred to the machine as "gong" out of habit, and had set
in /etc/hostconfig. As it turns out, this caused a subtle discrepancy in hostname resolution that had never affected normal operation. The solution was to restore HOSTNAME="-AUTOMATIC-" in /etc/hostconfig and let OS X resolve the hostname automatically to The fix almost seems obvious in retrospect, but Brother support, Apple Geniuses and I were all barking up the wrong tree, thinking it had to be a problem with the driver or in the CUPS layer.

The key troubleshooting tool turned out to be the semi-secret built-in CUPS http interface. Enable printer sharing and access http://localhost:631 on various machines on your network. From here, it became apparent that the printer was being seen with different names from different machines. Experiments with nslookup led to the hostname being the culprit.

Short lesson: Change your sharing name all you want, but don't mess with the hostname in /etc/hostconfig unless you really have a good reason to - some aspects of OS X would rather resolve hostnames automaticaly.
  Post a comment  •  Comments (5)  
  • Currently 2.25 / 5
  You rated: 3 / 5 (4 votes cast)
[10,916 views]  View Printable Version
The .local domain and DNS issues Network
I found this the hard way, and since I see others have run into the same problem without listing a definite solution, I thought I'd make this easy to find.

OSX (at least 10.2 and on) will not resolve .local names via DNS. lookupd's DNSAgent simply refuses to issue queries for them. This gives the strange situation where nslookup returns the correct information while ping returns an 'unknown host' error.

This is documented in Apple's Knowledge Base (article 107174), but if you didn't think to browse the Rendezvous docs for DNS problems, you'd probably never find it. Apple's recommendation is to simply change your domain from .local to .home, .office or .lan. I've done that here, but with well-established kerberos and afs servers in the .local domain, it was anything but simple (or pleasant).

The only other workaround I know of is to populate each Mac's /etc/hosts file with all the local IPs and hostnames (e.g., " foo"), and then change lookupd's search order with the following command (shown on two lines, but the backslash should allow a copy and paste to work):
nicl . -create /locations/lookupd/hosts \
LookupOrder Cache FF DNS NI DS
The tradeoff here is that while names in .local now resolve correctly, you've got the fun of keeping your /etc/hosts files in sync. That's probably why you installed a DNS server in the first place.

Finally, I have no idea how this workaround might affect Rendezvous. I do know that disabling Rendezvous completely had no affect on .local name resolutions.
  Post a comment  •  Comments (17)  
  • Currently 3.67 / 5
  You rated: 5 / 5 (3 votes cast)
[42,520 views]  View Printable Version