Please remember to reply to the mailing list, not the original sender: http://gnudip2.sourceforge.net/#mailinglist
+++++++++ As you discovered I got it backwards in my earlier note .. Brian S wrote: > > Given my original example "gdipc -g 3645:749", your explanation below > indicates the gdipc server will send a UDP packet back to port 3645 on the > WAN side of my NAT. Correct? > > >For example given your command "gdipc -g 3645:749", gdipc will send a > >UDP packet to port 3645 at the external address of your NAT box at the > >time of the last update, and listen with a time out on port 749, hoping > >to immediately receive the packet it just sent. So if the external > >address of your NAT box has changed, the packet will not arrive. > > >You must forward UDP packets arriving at port 749 on the external > >interface of your NAT box to 3645 of the machine running gdipc, > >otherwise the packets will never arrive, and you will send unnecessary > >updates to your GnuDIP service. This was backwards. Sorry. The gdipc.pl script will send to port 3645 on the external (WAN) address, and listen on port 749. One comment here, perhaps you should use a port above 1024 to listen on. On *NIX systems only "root" users can listen on ports below 1024. Perhaps your gdipc.pl script is not running with sufficient privileges? > And (on the LAN side), the gdipc client is going to listen on port 749 for > the packet that is supposed to be coming in on port 3645. So, I need to > point UDP packets coming in from the WAN side on port 3645 to port 749 on > the LAN side. Is this correct? (see my drawing below for my > understanding...which I cannot make work) Correct. > If this is the case, then the LAN side should know nothing about port 3645 > traffic and not require any LAN-side filters relating to port 3645 (outbound > or inbound). Right. > So, does this mean the -g parameter "3645:749" is actually the port > translation defined in the firewall? Port 3645 should be mapped to port 749 - right. > If I am barking up the wrong tree, please tell me to drop it. I have found > examples of Netgear filters ( http://www.netgear.org & > http://www.netgear.com/support/rt311/applications/firewall.html ), but I am > still confused as to how these examples can be applied to the gdipc > software. Don' quit!! I cannot promise to look through these sites. I did try one though, and it hung my browser! I had to retype this note! > My hope here is to document an example of using a Netgear RP114 (or RTxxx) > firewall with the GnuDIP software. Great. It is my hope that the archives for this mailing list will be a resource for GnuDIP users. > Do you think I have a chance? ;-) Yes. I have certainly had this working using a Linux gateway as the NAT box, and there is a report of success using a Linksys device on the mailing list: http://marc.theaimsgroup.com/?l=gnudip2-general&m=101372265626784&w=2 I suspect others must have it working too. The technique being used here is meant to be very simple and independant of the details of the NAT box. I see no reason why it should not work with your device. And I would very much like to see a report of success on this mailing list. > 旼컴컴컴컴컴컴컴컴컴컴� > � Remote � > � GDIPC Server � > � � > 읕컴컴컴컴컴컴컴컴컴컴� > � ^ > � � > 旼컴컴컴켸 읕컴컴컴� > � � > 3645 � � > \/ � > 旼컴컴컴컴컴컴컴� 旼컴컴컴컴컴컴컴컴컵 > � WAN � � WAN � > � Input Filter � � Output Filter � > � � � � > 읕컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴컴컴켸 > 749 � ^ > � � > � � > � � > 읕컴컴� 旼컴컴컴컴� > � � > � � > � � > \/ � > 旼컴컴컴컴컴컴컴컴컴� > � Netgear RP114 � > � Firewall/NAT � > � � > 읕컴컴컴컴컴컴컴컴컴� > � ^ > � � > � � > 旼컴컴� 쳐컴컴커 > � � > � � > 749 � � > \/ � > 旼컴컴컴컴컴컴컴� 旼컴컴컴컴컴컴컴컴컵 > � LAN � � LAN � > � Input Filter � � Output Filter � > � � � � > 읕컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴컴컴켸 > � ^ > 749 � � > 읕컴컴� 旼컴컴컴� > � � > � � > \/ � > 旼컴컴컴컴컴컴컴컴컴컴� > � Local � > � GDIPC Client � > � � > 읕컴컴컴컴컴컴컴컴컴컴� Looks right to me. -- Creighton MacDonnell http://macdonnell.ca/ -- GnuDIP Mailing List http://gnudip2.sourceforge.net/#mailinglist
