[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: Cygwin & local ports

Chris Riddoch chrisr@digeo.com
Fri, 10 Mar 2006 13:21:56 -0800 (PST)


Bryan Stansell wrote:
> On Thu, Mar 09, 2006 at 11:33:27AM -0700, Chris Riddoch wrote:
>> currently I'm on cygwin, but the *real* setup with more ports will be on
>> Linux.  Proof of concept, y'know.
>>
>> I built conserver with: --with-extmsgs --with-port=7072
>> --with-master=localhost
> 
>> I'm sure there's something obvious here that I'm missing, but I'm not
>> sure what.  I think it's trying to forward the connection somewhere,
>> rather than using the local serial ports.  That might be useful at some
>> point in the future, but for now, all I want to do is talk to a serial port.
>>
>> Suggestions?
> 
> hmmm...well, what's going on is the server is not realizing it should be
> managing these ports (for some reason).  for whatever reason, it must be
> getting confused with the localhost/127.0.0.1 entities...usually it
> recognizes that they are one in the same, but in your case, it appears
> it does not and it keeps redirecting the client to itself.  very
> bizzare, given that you have 'master 127.0.0.1' in the config.

The issue was resolved off-list by a patch from Bryan.  Apparently the
list of available routes on cygwin included "0.0.0.0".  This is the same
token that's used by the conserver code to identify the end of the list
of interfaces, and since it came first, none of the other more
reasonable entries were even seen.  Expect the patch to arrive in the
next version of conserver, but if you need it in the meantime, see
below.  (Sorry it's not an attachment, my company's mailservers seem to
have problems with the idea of sending attachments.)

If you're unfamiliar with patching, copy everything after ---snip---
below into a file, call it cutilpatch, and put it into
conserver-8.1.13/conserver/.  cd into that directory, and run the following:

  patch -p0 < cutilpatch

Then, cd .. up to conserver-8.1.13, configure, make, and make install.

That should take care of this thread.

-- 
     Chris Riddoch
epistemological humility


---snip---
--- cutil.c	2006-01-15 10:10:14.000000000 -0700
+++ cutil.c	2006-03-10 14:13:30.562500000 -0700
@@ -1,3 +1,7 @@
+
+
+
+
 /*
  *  $Id: cutil.c,v 1.125 2006/01/15 17:10:14 bryan Exp $
  *
@@ -2199,6 +2203,7 @@
     int r = 0, m = 0;
     int bufsize = 2048;
     int count = 0;
+    in_addr_t zeroaddr;

     /* if we use -M, just fill the array with that interface */
     if (bindAddr != INADDR_ANY) {
@@ -2274,6 +2279,12 @@
     if (myAddrs == (struct in_addr *)0)
 	OutOfMem();

+#if HAVE_MEMSET
+    memset((void *)&zeroaddr, 0, sizeof(zeroaddr));
+#else
+    bzero((char *)&zeroaddr, sizeof(zeroaddr));
+#endif
+
     for (m = r = 0; r < ifc.ifc_len;) {
 	struct sockaddr *sa;
 	ifr = (struct ifreq *)&ifc.ifc_buf[r];
@@ -2297,6 +2308,15 @@
 		((ifrcopy.ifr_flags & IFF_UP) == 0))
 		continue;
 #endif
+	    if (
+#if HAVE_MEMCMP
+		memcmp(&(sin->sin_addr), &zeroaddr, sizeof(zeroaddr))
+#else
+		bcmp(&(sin->sin_addr), &zeroaddr, sizeof(zeroaddr))
+#endif
+		== 0)
+		continue;
+
 	    CONDDEBUG((1, "ProbeInterfaces(): name=%s addr=%s",
 		       ifr->ifr_name, inet_ntoa(sin->sin_addr)));
 #if HAVE_MEMCPY
@@ -3365,3 +3385,4 @@

     return;
 }
+