Ok, the rules for getting the Wireless synchronisation work like this.
Your PC talks to the Zaurus on its IP address and starts up the Sync process by talking to the Zaurus on the configured IP address.
The Zaurus then ignores the IP address of the incoming sync request. Instead it takes the current network configured for the USB network, applies the subnet mask to it and talks back to the first node on that network which it expects to be the PC.
For example in my configuration I have set my USB IP addres on my Zaurus to be 10.200.0.2 then edited /etc/hotplug/usbdnet.conf and set the NETMASK line to 255.255.0.0. This makes my Zaurus hunt for the IP address 10.200.0.1.
If you choose a similar tactic then I think your Wireless sync will work fine.
<UPDATE>
Just reread your question... initiating sync at the Z is a no go. The SL sync application (on Windows) doesn't listen for the 4245 TCP connection all the time and this is what the Z calls out on. I suspect this only happens if you plug in the Z cable.
</UPDATE>
For the curious, my requirement is a little more tricky. I use VMWare for all my Windows stuff and the 10.200.0.1 network is actually bound to interface eth0:1 (secondary IP binding off my primary interface). The VMWare session is using NAT but the Linux host can also route to the network containing the VMWare session. The VMWare Windows session is actually on 10.254.10.1.
I make this work using the following script...
syncsetup.sh
#!/bin/sh
ifconfig eth0:1 10.200.0.1 netmask 255.255.0.0
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -t nat -F
iptables -t nat -A POSTROUTING -s 10.200.0.2 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth0 -d 10.200.0.1 --dport 4244 -j DNAT
--to 10.254.10.1:4244
iptables -t nat -A PREROUTING -p tcp -i eth0 -d 10.200.0.1 --dport 4245 -j DNAT
--to 10.254.10.1:4245
The first iptables line allows the Z to browse through the host if needed.
The PREROUTING conditions route the reverse connection tcp channel on ports 4244 and 4245 from the 'assumed' address of 10.200.0.1 to the actual address of the Windows session.
This works like a dream.
The only explanation as to why Sharp implemented things like this that I can think of is that they didn't want to overburden people with extra config steps on the Z. You may think this shouldn't be an issue since the Z should just respond to the incoming connection and reply on that IP address, however, this would not let you originate the synchronisation from the Z (since the Z hasn't got an initial connection going to determine its partner from).
Finally for the completely curious as to why I bother with the second IP on the host network.. here's the complete deal..
At the office I use a laptop and cart an external disk containing all my VMWare images backwards and forwards betweem home and the Office. The Laptop WIFI address is 10.200.0.1. When I plug the disk into my home PC I can fire up the same VMWare sessions but don't want to reconfigure my Z with a different address for the Sync partner (since it's actually referencing the Linux host and not the Windows session). For this reason the script on my home system adds a secondary address to the primary NIC.
Hope that helps someone,
- Andy
