Firewall/NAT

I just built a monowall, and I'm using a netgear wga311 card in it as an access point for my wireless network.  So far other then the itunes remote problem the wga311 has done a great job with all other wireless connectivity.

Oddly enough I can go into the itunes remote on my ipod and start the process to link it to my itunes and it shows up in itunes and when I put in the code in itunes shown on my ipod it gives the message "ipod now linked to itunes" or whatever that message is similar to that.  However from that point on when I select that install of itunes on my ipod it times out while attempting to connect.

Anyway, I have my WLAN(opt1) bridged with LAN, I have rules allowing all traffic from LAN to WAN on the LAN interface, and a rule on the WAN interface to allow any traffic to the LAN interface.  Additionally last night I updated monowall to 1.31 and enabled the check box that disables spoof protection that allows multicast from the WLAN to LAN.

At this point I'm stumped.  Anyone have any ideas?

Also, if anyone trying to figure this out needs any more information from me about my set up just let me know and I'll try to get it up as soon as possible.

Thanks.

Nevermind.  Its not monowall.  I just put itunes on an xp desktop on the network thats wired through a switch to the firewall, and my ipod is working fine as an itunes remote on it.

It must be an internal firewall problem on the other computer.  Its running windows 7 64.  So yeah, it has nothing to do with monowall.

My apologies.

I think it WAS m0n0wall.  The difference is that you switched from WLAN to a machine on the LAN.  Can't seem to get mDNS/Bonjour to talk across the WLAN/LAN border -- still hunting the forums.  Help anyone?

if you are on 1.3b10 as your sig says, upgrade to 1.31 and in advanced tick the option for ' Disable Spoof Checking on bridge'

f you are on 1.3b10 as your sig says, upgrade to 1.31 and in advanced tick the option for ' Disable Spoof Checking on bridge'

My .sig was out of date, corrected now.  I had tried that option in m0n0wall 1.31 to no avail.

I've done further investigation.  There are a lot of suggestions on the 'Net for solving this problem -- way too many, in fact, they are superstition, luck, what worked for one or two people.

I bought a cheap Netgear WAP and using this in place of m0n0wall as the access point for the iPhone to connect to machines on the wired LAN, the problem still occurred with my first test machine, which is a new minimal install of Win XP Pro (no AV, no firewall) on an Intel D510MO motherboard with its onboard Realtek 8111DL NIC.  I purged and reinstalled iTunes, the NIC driver, etc. all to no avail.

I've tested five machines now on the same LAN/WLAN with the Netgear WAP: two Win 7 machines, three Win XP machines (all SP3, up to date as of today), and I cannot for the life of me connect the iPhone Remote application to two of the Win XP machines.  The other three machines connect fine. 

To prove that m0n0wall is not causing a problem, I should switch back to m0n0wall WAP and reproduce the same fail/success with each machine as with the Netgear WAP.  I haven't done that; if I do I'll post again, but if m0n0wall is a problem, it's not the only one.  It seems to be an Apple software issue of inconsistent installs/repairs of iTunes (and/or Bonjour, etc.).  Here's what I've learned.

The five machines include one Win XP machine, so it's not an XP issue.  That XP machine has a NIC that's not a Realtek 8111DL, which is also the NIC that's in an XP machine that fails, so it's not the XP NIC driver.   On the original XP machine that is failing, I tried a USB-ethernet NIC to no avail.  I put the XP machine that works at the end of the same ethernet cable as the XP machine that was failing and it worked, so it is not my switch or physical network.

One Win 7 laptop that succeeds can connect via WLAN or LAN, doesn't matter.

This problem affects only the ability of the Remote App to connect: iTunes can share libraries successfully between all computers.  Once again, the "fail" behavior is for iTunes to prompt for the passcode to connect the remote device (iPhone 3GS in my case).  It accepts the passcode, shows "verifying remote passcode" in the status line, hangs a few seconds, then reverts without any notice to the main iTunes screen (where instead on success one would get a confirmation screen that the remote is paired).  Meanwhile the iPhone wipes the passcode off the screen and tries to connect to an unnamed library until it times out.  Then you've got an unnamed (blank-named) library in your list, any attempt to connect to which times out.

I investigated network traffic on UDP port 5353 and TCP port 3689 using wireshark (capture filter "udp port 5353 or tcp port 3689") running simultaneously on both a machine that doesn't work and a machine that does, connecting to both machines.  Both wiresharks show the same traffic, again confirming there is not a network connectivity issue.   In a successful connect, the two devices do a kind of handshake on mDNS (UDP 5353) then switch to the TCP port and start jabbering.  In a failed connect, the iTunes host never starts the TCP conversation and the iPhone is left hanging making a few more mDNS requests till it times out. 

A library-sharing conversation is similar (switching UDP to TCP) and once again these work on all my machines.

I'm using iTunes 9.1 (latest as of today), except on one of the failing machines running XP and iTunes 9.0 (I will upgrade to 9.1 but think it won't help).  I've fiddled with iTunes preferences settings a lot.  I don't think they're relevant because I set two machines to the exact same preferences and one still failed while the other succeeded.

I'm at the end of my diagnostic abilities and time for this problem.  I blame iTunes software: on some installations (of XP at least) it is failing to be a proper host to the Remote application.  It doesn't depend on the NIC, and reinstallation/repair does not help.    The definitive (?) proof of this theory will be to boot a failing machine from a hard drive taken from a working machine, and have it work.   One failing machine is a pristine XP installation,  the other failing machine and one of the working ones are old bloated hacked installations.  So there's really nothing to hang on to here, and nothing to blame but Apple  software.  If only iTunes would log what seems like its silent failure after entering a correct passcode.

ok, seems like you are happily working through the problem tree :-)

1.31 introduced the spoof disable option as there was a built-in rule that would block certain traffic types on bridge networks.

A sniffer trace would be most interesting and helpful though.

I blame iTunes software: on some installations (of XP at least) it is failing to be a proper host to the Remote application.

Probably not just XP, but Win 7 also, because original poster's failure was with Win 7 and working installation was XP.   My two successful Win 7 machines are Home Premium (32 bit) and Professional x64.

My iPhone was most-recently synced, or synced in the past, with two of my failing XP machines, but not ever synced with the third XP machine, which succeeds.  Before ever syncing with one of the machines now failing, I got the same failure, but this was early in testing so don't know if I had the m0n0wall anti-spoof option on at that time.  Because the failure is identical each time and always has been, I think these observations about syncing are irrelevant, except for the fact that if you enable iTunes DJ on the machine most-recently synced, I think it will always show up in the Remote app, even without going and pairing.  I did in fact successfully connect to the DJ part on a failing machine at least once; I remember being very disappointed with the (mistaken) conclusion that the DJ voting was the only function of the Remote app, whereas I wanted full control over the library.  Remote definitely does what I want it to -- full control -- it just is picky about what machines it will pair with.  I suppose I could add some information by trying again to see if I can get a DJ connection with any of the machines I've called "failing".  At this point, this kind of information will be useless to me personally except potentially to pass on to some Apple programmer who could fix iTunes.

Looks like I can't post a .pcap file here and a .txt or PDF version wouldn't be very useful.  I'll post elsewhere and link in a new post.

Here is aforementioned wireshark capture: successful connect of iPhone Remote to iTunes, limited to UDP 5353 and TCP 3689.  When the connection "fails," the conversation ends before any TCP traffic starts.http://mattswift.net/itunes-iphone-remote/successful_connect_tcp-3689_udp-5353.pcap  about 75kb, open with Wireshark (or perhaps other software too?) http://wireshark.org. 

The two machines are 192.168.2.122 and 192.168.2.124 the IPs on my LAN assigned by m0n0wall's DHCP (m0n0wall sits between this LAN and the internet, out of this conversation except for initial DHCP), the phone is called "Matts-iPhone" and desktop called "Himantopus"

[name]

five machines include one Win XP machine

Not what I meant.  Let me tabulate, summarize:

name	OS	success?
iko	XP Pro SP3+ (new minimal on D510MO)	no (tried 2 NICs)
himantopus	Win 7 Pro x64	yes
luna	XP Pro SP3+	yes (and on iko's cable)
flatts	XP Pro SP3+	no
kaf	Win 7 Home Premium x32	yes (wireless and wired)

iTunes 9.1.0.79 except kaf is 9.0.x.  Library-sharing works among ALL above hosts.  Windows firewall off always, no AV or anything similar installed on iko, the rest have something maybe, but it's not interfering.  This is all with the Netgear WAP.  M0n0wall 1.31 with bridge spoof rule disabled could not connect to iko; will post again if I revert to m0n0 and try again to see if any difference from netgear.  iPhone 3GS with latest firmware and version of Remote app.  Connecting WPA (to m0n0) WPA2 to Netgear, no (other) connectivity problems with iPhone. 

at packet 368 you see the iphone make a http GET request

http://192.168.2.124:3689/databases/37/browse/artists?session-id=1979745789&include-sort-headers=1&filter=('com.apple.itunes.mediakind:1','com.apple.itunes.mediakind:32')+'daap.songartist!:'

and the PC responds with a RST

every new daap connection from the iphone gets responded to with a RST from that point on

I might be able to try out an iphone next week if I can get my hands on one and see if m0n0wall is part of the problem, but other than this thread, I don't see why it would be

http://discussions.apple.com/thread.jspa?threadID=2159903&tstart=-1

that sniffed conversation did not go through m0n0wall.  It was also a successful connection; I'll post a failure too when I can.  On a failure, you never see any TCP (daap) show up at all.

On the posted sniff, the route between iphone and desktop was via a Netgear WAP (WGR614 used just as bridging WAP not router), then an ethernet switch (HP Procurve J9209).  Or maybe himantopus was still connected to the WAP's ethernet port left over from configuring it? wouldn't matter because regardless m0n0wall was sitting outside the conversation between the switch and the internet, and was involved only secondarily before the conversation as DHCP server for the two hosts, and as DNS server.

I had initially tried connecting the iPhone via the WLAN on the m0n0wall machine.  After failure, I suspected m0n0wall and switched to the Netgear, but the same problem occurred.  Technically, both the Netgear and m0n0wall could be introducing the same or effectively the same problem, but given the pattern of the problem that seems to be specific to particular iTunes installations (i.e., not to OS, NIC, or bridging WAP) I suspect there's nothing wrong with m0n0wall 1.31 with the anti-spoof option disabled.  I'll post more if I disconfirm any of the above conjecture.  Before I return that Netgear WAP, I'll try again back using m0n0wall.  If I get the same fail/success with each of the five hosts as I did with the Netgear, I'll feel very confident returning the Netgear.

I might be able to try out an iphone next week if I can get my hands on one and see if m0n0wall is part of the problem, but other than this thread, I don't see why it would be

there are plenty of threads out there describing this exact problem with Remote App/iTunes, on Windows and Macs.  Many of those who didn't clearly have something obvious wrong with their setup resolved the problem by doing one magic act of hand-waving or another (reboot the router, re-install Bonjour, blah blah).  In the thread you quote, probably the new disable-anti-spoof option in m0n0wall 1.31 is essential, so that poster resolved by downgrading to m0no 1.2, which isn't an option for Alix 2 boxes, and wouldn't have helped anyway, since switching to the Netgear WAP didn't help.

I investigated network traffic on UDP port 5353 and TCP port 3689 using wireshark (capture filter "udp port 5353 or tcp port 3689") running simultaneously on both a machine that doesn't work and a machine that does, connecting to both machines.  Both wiresharks show the same traffic, again confirming there is not a network connectivity issue.   In a successful connect, the two devices do a kind of handshake on mDNS (UDP 5353) then switch to the TCP port and start jabbering.  In a failed connect, the iTunes host never starts the TCP conversation and the iPhone is left hanging making a few more mDNS requests till it times out. 

It looks like the initial discovery is done by MDNS queries for _touch-able._tcp.local as a SRV record and Himantopus replies with some TXT record information and SRV information, saying port 3689 and target himantopus.local and then TCP and DAAP start for the http communication.

If you have a capture of a failure, hopefully this will show MDNS not resolving or working correctly and maybe dns for target names is not right etc.

http://mattswift.net/itunes-iphone-remote/failed-connect_tcp-3689_udp-5353.pcap

I returned the Netgear WAP and am back using m0n0wall 1.31 with anti-spoof disabled, etc. as described before.  I've tested Iko Himantopus Flatts with same results of fail/succeed.  I'll test Luna Kaf too for completeness.

Both sniffs were run on the machine running iTunes.  This fail is to Iko at 192.168.2.31.  I had name resolution turned on for this sniff unlike the previous, but my iPhone was at the same IP 192.168.2.122 Looks like iTunes simply does not respond.   I haven't perused the packets from the iPhone to make sure they're comparable to the successful connect, but I can't see why they would be: the iPhone does a broadcast, the opportunity to connect from iTunes flashes on every iTunes running on the LAN.  If you try one iTunes it works, try another it doesn't, so it's really got to be on the iTunes side, or else I've discovered an incredible macroscopic iPhone-iTunes quantum entanglement over ether. net. 

Firewalls on iTunes machines are off, and I did confirm Iko can generate mDNS traffic that gets caught by wireshark (fire up iTunes and it jabbers away at least when there's a library-sharing client on the LAN).   So iTunes on Iko is just failing to respond, whereas iTunes on Himantopus does respond.  The user sees the same thing at iTunes up through the point of entering the final digit of the 4-digit code appearing on the iPhone into the iTunes window.  On success, a "success" panel appears almost immediately; on failure (as described before) you get the msg about verifying remote code for a few seconds, then get dumped back into the main iTunes panel while the iPhone client hangs till it times out.

It certainly looks like mdns/zeroconf/bonjour is not discovering itunes to start DAAP.

you could try reinstall bonjour or use a browser like bonjour browser or zeroconf explorer to see if it discovers itunes etc.