Jump to content

  • Log In with Google      Sign In   
  • Create Account


Novark

Member Since 06 May 2008
Offline Last Active Apr 05 2013 05:01 PM

Posts I've Made

In Topic: Peer-to-Peer (UDP) Issue

23 March 2013 - 07:28 PM

I figured it out!

 

It was my modem's settings.  I had to forward the port I was using on my modem.  It has it's own NAT which was enabled.  For anyone who might be curious, my modem model is:  SMCD3GN.  The username / password were posted on a little sticker attached to the modem.

 

I've been struggling with this problem on and off for ages, and it never occurred to me that it was my modem that needed to be configured properly, and not my router.

 

Works like a charm now!  laugh.png


In Topic: Peer-to-Peer (UDP) Issue

23 March 2013 - 05:45 PM

Check to see if you ip from ipconfig/ifconfig and from a website such as whatismyipaddress.com gives the same ip.

You could be under an ISP NAT.

 

I was always kind of hoping that this wouldn't be the case.  I ran ipconfig and my public IP wasn't listed anywhere.  I get the typical 192.168.XX.XX.  This is all while bypassing my router and plugging directly into the modem.

 

If this is the case, and my ISP is providing NAT services, is there anything I can do?  Also, is there a way that I can verify that this is absolutely the case, and not something else?

 

Update:  Pretty sure the issue is with my modem.  It has it's own NAT that I need to work around.  I'm in the process of trying to find the default username / password that my ISP uses for this modem right now.  I'll keep this post updated.


In Topic: Peer-to-Peer (UDP) Issue

22 March 2013 - 09:23 PM

The "listening" part should bind to address 0.0.0.0 with a specific port (remember to use htons()). This will bind to all public interfaces. You can use "netstat -l" to see all bound services from the command line (both on Unix and Windows.)

Then you should make sure you allow the application to listen to public networks in the Windows Firewall settings, and it should work.

You can try running Ethereal on both your buddy's machine and your own machine when trying to connect, to see what kinds of packets are on the network in both places.

 

I define my listener as follows:

 

Public listenerEndpoint As New IPEndPoint(System.Net.IPAddress.Any, 54329)
Public rxClient As New UdpClient(listenerEndpoint) 'This client will listen on port 54329

 

I ran a netstat -a -p UDP command and found the following line:

 

Proto          Local Address       Foreign Address       State
  .                  .                    .
  .                  .                    .
 UDP           0.0.0.0:54329             *:*

 

It would appear as though everything is normal.  I made an Inbound Rule in my firewall for my application and made sure that it's profiles are enabled for Domain, Public and Private connections.  I also made Inbound and Outbound rules for Port 54329 which is the port that I'm listening on.

 

I tested it with my friend once again, and got the exact same results - I still don't receive anything.  I can still receive messages locally if I send them to 127.0.0.1:54329 which tells me that the code for the listener is at least working as intended...   I looked in Wireshark (on my end) and it still says that the port is unreachable when I send messages to my public IP address on port 54329.


In Topic: Peer-to-Peer (UDP) Issue

22 March 2013 - 01:20 AM

Some things to check:

1. Check that you are listening at the IP of your network card and not on 127.0.0.1

2. Activate the firewall and check if the packets of your college get blocked.

3. Take a packet sniffer and check if you can receive the packets with it.

 

#1)  Could you elaborate on this point a bit?  I create a UDPClient reciever that listens on port XYZ.  I didn't specify a host address (although I could without any difficulty...perhaps I'll give this a shot - maybe it's defaulting to listen on 127.0.0.1 or something)

 

Update #1:  I looked into this a bit more, and found the following documentation:  http://msdn.microsoft.com/en-us/library/35e07es2.aspx

 

This constructor creates an underlying Socket and binds it to the port number from which you intend to communicate. Use this constructor if you are only interested in setting the local port number. The underlying service provider will assign the local IP address. If you pass 0 to the constructor, the underlying service provider will assign a port number. If this constructor is used, the UdpClient instance is set with an address family of IPv4 that cannot be changed or overwritten by a connect method call with an IPv6 target.

 

Maybe this is the problem!  I'll update this again with my findings after I test it.

 

Update #2:  I tested it again, specifying a listening host address set to my public IP, but still no luck.  I performed this test while directly connecting to my modem to avoid any problems that my router might introduce.  I also checked the traffic with Wireshark and noticed that the packets were being sent correctly, with the correct address and port, however, I was being informed by the ICMP that the destination was unreachable (port unreachable).

 

#2)  I'm on a home network right now, so there shouldn't be any problem with certain packets getting blocked

 

#3)  I have Wireshark, but I'm a bit inexperienced with it.  I'll look into it though.


In Topic: Peer-to-peer connection issues (TCP/IP)

10 May 2012 - 03:07 AM

I'm pretty sure it is related to your firewall, or perhaps the firewall of your ISP. Also, your Friend B probably has the same (or a similar) problem.

Get yourself access to a UNIX shell somewhere outside of your local network. Then try to "telnet your-public-ip your-port" and see if it connects, or doesn't connect. If it doesn't connect, it's a firewall/port-forwarding problem.


I think I can rule out the possibility that my ISP is at fault, since I have never had problems with them before, and my "Friend A" also has the same ISP and I'm able to connect to him just fine.

Please forgive my ignorance on the subject, but what exactly would be the difference between using a -telnet command versus getting my "Friend A" to try to connect to me? Is it simply to eliminate the possibility that there's something on my friend's side of things that could be wonky, or is there another benefit to using a UNIX shell to test?

PARTNERS