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.
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
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.
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.