TCP Sockets over Wireless

[JonF]

I am working with C# compact framework and have written some code which
allows communication over the socket layer, however I have encountered
the strange problem that I can only communicate over a physical dock
connection not WiFi. At the moment I have set the IP to be 192.168.0.4
which is the address my laptop running the server which the PocketPC is
trying to connect to.

I'm using the following code:

private string svraddress;
private int svrport;
private Socket connection;

IPEndPoint ip = new IPEndPoint(IPAddress.Parse(svraddress), svrport);
connection = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
connection.Connect(ip);
connection.Send(data);

I'm guessing that this may be some sort of DNS problem with resolving
the local network IP?

Any ideas/pointers appreciated...

 

[chris-s]

Are you happy that the wireless connection is actually functioning,
have you checked the the wireless adapter on the device is actually
connecting to the wireless access point/router or laptop? Does it have
a valid IP address, assigned or fixed ?

If you are using a wireless access point or router, is there any built
in firewall that may be blocking the port you are using?

Chris

 

[Paul G. Tobey [eMVP]]

DNS is *not used* to resolve anything when IP addresses are used.

I'm guessing firewall, as Chris mentioned. Works fine for me.

Paul T.

 

[JonF]

The PocketPC is connected fine, can browse the internet etc... I have
added a firewall rule which explicitly allows TCP traffic between
devices on the required port however that didn't help and had the
annoying side effect of blocking other traffic - in short I can't be
bothered to setup a proper set of firewall rules for a domestic
router...

Although I can still demo the project without the network functionality
it would be very useful...

 

[JonF]

Also one of the strange side effects, if the wireless adaptor is
enabled then the connection cannot be made, while if it is disabled the
connection is fine (while in the cradle obviously).

 

[Paul G. Tobey [eMVP]]

You can't communicate over wireless while the device is in the cradle.
That's the way Windows Mobile 5 devices work. You haven't given us any
specifics about versions, either of the .NET CF or of the device.

Allowing traffic through a given port doesn't have side-effects like that on
any firewall that I've ever seen. What firewall are you using? Where is it
running in the network infrastructure? Again, this works *just fine*, no
problems, no errors, nothing unexpected. Your network or your code on the
PC is doing something wrong. Is the PC code .NET, also?

Paul T.

 

[stu]

What do you have the device address and subnet set to?

Assuming you are connecting the wifi network correctly, you should be
able to see traffic generated by the device with a packet sniffer (like
ethereal). This assumes that you have things set up right on the
network to sniff and you're using a wifi card that can sniff. At
minimum you should be able to see an ARP message from the device to the
world, looking for the MAC address of 192.168.0.4. If you can see
this, you're device is correctly connected to the wifi network. Next
check for a TCP SYN packet going from the device to the desktop;
running the sniffer on 192.168.0.4 is probably your best bet as you'll
see everything that node can see coming from the mobile device.

stu =)

 

[Guest]

While I'm not the original poster, I am having the same problem. However, I
am actually able to establish a connection about once every five or so tries.
When the device is docked, I don't have a problem. I am not too familiar
with tcp/ip, but while running Ethereal, I can see that a [SYN] is
transferred from the device to the server. The server response with [RST,
ACK].

I'm using the signature capture sample, so I know it's not an error with my
coding. Any help would be greatly appriciated.

 

[Paul G. Tobey [eMVP]]

The RST is an indication that the connection attempt, the SYN packet, is
being forcably rejected. That might mean that the server program is *not
running*, *not listening*, or *rejected your specific client IP*.

You should know whether the server program is running, I'd think. If it's
not, start it ;-)

There are two reasons I can think of for it not listening: you specified the
wrong port number, either on the server end (it's listening for connections,
but not on the port number that you think), or it's already connected to a
client and did not specify a suitable backlog parameter value in the
listen() call to allow you to connect while another client was hooked up.
Make sure that htons() was used when passing the port number to bind() in
the server code to address the first error, and make sure that the client is
passing the right port number. The second error would require you to check
the parameters to the listen() call and make sure that backlog is 5 or
something.

If the server rejected your device IP, again, you'd have to see the server
code or watch it execute on the debugger on the desktop to figure out why
and what to do about it.

Paul T.

While I'm not the original poster, I am having the same problem. However,
I
am actually able to establish a connection about once every five or so
tries.
When the device is docked, I don't have a problem. I am not too familiar
with tcp/ip, but while running Ethereal, I can see that a [SYN] is
transferred from the device to the server. The server response with [RST,
ACK].

I'm using the signature capture sample, so I know it's not an error with
my
coding. Any help would be greatly appriciated.

What do you have the device address and subnet set to?

Assuming you are connecting the wifi network correctly, you should be
able to see traffic generated by the device with a packet sniffer (like
ethereal). This assumes that you have things set up right on the
network to sniff and you're using a wifi card that can sniff. At
minimum you should be able to see an ARP message from the device to the
world, looking for the MAC address of 192.168.0.4. If you can see
this, you're device is correctly connected to the wifi network. Next
check for a TCP SYN packet going from the device to the desktop;
running the sniffer on 192.168.0.4 is probably your best bet as you'll
see everything that node can see coming from the mobile device.

stu =)