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...
I have figured out how to send email hyperlink files to both Windows and Macs users at work. These files comes off a linux file server; the Windows users are using 2003 Exchange servers, and we have various Mac users. The hyperlink file in the email that you send to Mac users is different than the hyperlink file that you would send to a Windows users. In the end, however, both Windows and Mac users are able to click on a hyperlink to open a file off the server.
DISCLAIMER: Even though this works for me, it doesn't necessary mean that it will work for you. Success depends on the file server, Exchange server, ports and privileges, syntax, etc. This hint provides clues on how to set up hyperlinked file such that you may be able to send them to both Macs and Windows users via email. You will probably have to experiment a little (or a lot) to get this to work for you.
This hint is an evolution of another hint, which I had a hard time getting to work. You can read it for the rest of the detail, but the short story is that it allows you run a full remote X11 desktop session in a window on your Mac.
The longer story is that it probably won't work, because your Mac probably doesn't have the same X11 fonts installed as does the remote server. The older hint actually addresses this, but the explanation is confusing, and it only works if there is no firewall between you and the server. The fix is to forward the TPC port of the X font server over the SSH session, so that your local machine can actually talk to it. Here is what the entire setup looks like:
localhost% ssh -L7100:localhost:7100 -Y user@remotehost
(in another Terminal window)
localhost% xset +fp tcp/localhost:7100
(back in the first window, after it has ssh'd into the remote host)
remotehost% Xnest ":1" -geometry 1280x810 -query localhost
Discussion:
You have to have the ssh session open, with the port forwarding active, before you will be able to add the remote font server to your local font path. And you have to have the remote server's fonts in your font path before it will be possible for the remote desktop session (CDE on Solaris in my case) to start up.
One of the problems I had with the old hint was that it said to do xset +fp tcp/ip.of.remote.host:7100 and I thought he meant "use the tcp/ip address...", when actually the prefix tcp/ is really part of the syntax. The other problem is that it wasn't clear where you were supposed to run the xset command, or for that matter why you'd be tunneling X in SSH at all if there wasn't a firewall in the way.
About once or twice a day, the strength indicator on my AirPort drops right down and eventually disconnects. Needless to say, this is pretty frustrating, but after four months, I have finally discovered the reason. It is because Bluetooth uses the same frequencies as 802.11, which opens up the possibility of packet collision. When this happens, Bluetooth is supposed to hop frequencies, and 802.11 is supposed to add a delay somewhere to compensate.
To fix, simply turn off Bluetooth, turn off AirPort, turn on AirPort, then turn on Bluetooth. This also usually fixes the reverse problem, where there is lag with a Bluetooth keyboard (and possibly mouse, but I've never used one).
I should add this is probably only a problem if Bluetooth is communicating continually. In my case, the problem is my keyboard. If you're just syncing your phone or something of that nature, then this will probably not affect you.
Well, much like may other people, ever since I upgraded to Tiger, I have had issues with the AirPort connection on my good ol' Pismo. No automatic connection whatsoever -- on bootup, restart, or wake from sleep. It was really annoying. My home wireless network (DLink WEP protected) would show up, and I could manually connect, but not without human intervention.
I finally found the complete answer: Keychain and Network Preference settings:
In Network Preferences > AirPort, set the "By default, join:" to "Preferred network."
In AirPort > Options..., set "If no preferred networks are found:" to "Keep looking for recent networks."
In Utilities > Keychain Access, select your Network under Login Keychains. Check the "Show password:" box and make sure it is correct -- mine had a "0x" prefix added to it that I had to remove. Under the "Access Control" tab, select the "Allow all applications to access this item." I may be wrong, but I think this is the key to getting all of the automatic connections to work, well, automatically.
I had been able to get partial success with the first two steps, but until I did the third step, nothing was consistent, especially automatic connection at startup. Hope this helps. I would be interested to see if it works with other people's setups.
We just put in an PowerMac at a retired relative's house running Tiger connected to the internet via DSL. Normally, the PowerMac will only be used as a standalone machine, but it does have an AirPort card. While we're visiting, we want a wireless network so we can use our notebooks to access the internet.
So, today, we tried it. Web surfing worked immediately. Mail, however, would not work. We figured out that the firewall running on the PowerMac was blocking ports Mail needed, but then it took a bit of playing around to make it work. We turned on logging and found blocked ports that might be used by Mail, told the firewall to allow them, and got things working. Since there was already someone using a port scanner on us, we removed some of the ports from the allowed list that we weren't sure we actually needed there, and things still worked.
Our IT people decided that it was a bad idea to access the Internet recently, and our beloved open-access policy was replaced with a block on all ports, with ports 80 and 443 (http and https) now routed via a proxy server. No more getting my Gmail or other POP/IMAP mail, no more MSN, Jabber, ICQ, etc.
Needless to say, I was peeved. I did some digging and came up with this absolutely wonderful little program called Proxytunnel. You see, if your network admins are anything like mine (and most are), they will have allowed you acccess to secure sites via an HTTP proxy. The thing with SSL and proxies is that because everything's encrypted, the proxy can do naught but just pass on your requests to the sites in question, and can't have any say on what protocol is used. So get Proxytunnel, drop it in /usr/local/bin or anywhere else in your path, and then do something like this:
You can now access your Jabber server by setting up iChat to connect to server localhost instead of myjabberserver.com (the 123.123.123.123 IP address is the IP of your proxy server; 8080 is the port. The first 5222 is the port on localhost that proxytunnel will be listening to, the last one is the port of your jabber server. Note that you need to run Proxytunnel as root if you want it to listen on a port below 1024; however, you can make it listen on a different port.
This is a tiny hint that hopefully will save the rest of you some time. I have been using a Motorola cell phone (V300) to connect to the internet via GPRS -- it's actually T-Mobile's Internet Service, which is quite a bargain at $20 per month for unlimited usage.
The thing that is important to remember is that when you configure your cell phone with Internet Connect, it saves the OS X USB modem device string literally from the first port you plugged the phone into. This means if you plug it into the second port later and try to use the phone, it will appear to be working (i.e. the phone appears on System Profiler), but it will refuse to actually make a network connection. The way you can tell is to open Console and look at system.log. You will see references such as pppd[240]: Device '/dev/cu.usbmodem1B11' does not exist.
If you open Terminal and look in the file system, you can see that you have plugged the phone into the wrong port: in my case, I will have a file called /dev/cu.usbmodem3b11 (note the 3 instead of the 1). The way to solve this is to unplug the modem and put it in the original port; then the modem will be at /dev/cu.usbmodem1b11 and all will work again.
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.
