Sorry about the truss output, Here is the return for point 1:
# ./upsd -4 -DDD Network UPS Tools upsd 2.1.0 listen_add: added 127.0.0.1:3493 listen_add: added 192.168.1.8:3493 setuptcp: try to bind to 127.0.0.1 port 3493 setuptcp: protocol mismatch [0] not listening on 127.0.0.1 port 3493 Point 2, made the changes and here is the result: # ./upsd -DDD Network UPS Tools upsd 2.1.0 listen_add: added 127.0.0.1:3493 listen_add: added 192.168.1.8:3493 setuptcp: try to bind to 127.0.0.1 port 3493 setuptcp: protocol mismatch [0] listening on 127.0.0.1 port 3493 setuptcp: try to bind to 192.168.1.8 port 3493 setuptcp: protocol mismatch [0] listening on 192.168.1.8 port 3493 Connected to UPS [z2ups]: z2ups Pinging UPS [z2ups] UPS [z2ups]: dump is done Got PONG from UPS [z2ups] Pinging UPS [z2ups] Got PONG from UPS [z2ups] Pinging UPS [z2ups] Got PONG from UPS [z2ups] Pinging UPS [z2ups] Got PONG from UPS [z2ups] Pinging UPS [z2ups] Got PONG from UPS [z2ups] Regards --zoly -----Original Message----- From: Arjen de Korte [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 2:07 PM To: Zoltan Farkas Cc: Peter Selinger; [email protected] Subject: Re: [Nut-upsuser] upsd does not strt up Peter Selinger wrote: >>> Forget about truss and just post the output of './upsd -DDD'. > Could you do that, please? -- Peter Never mind that, it's already clear to me what is wrong. After stripping the junk that truss added, it leaves the following output: > Network UPS Tools upsd 2.1.0 listen_add: added 127.0.0.1:3493 > listen_add: added 192.168.1.8:3493 So far, no problems. Apparently you configured 'upsd.conf' to listen to 127.0.0.1:3493 and 192.168.1.8:3493. That's probably fine, assuming these addresses exist and no other daemons are listening there. > setuptcp: try to bind to 127.0.0.1 port 3493 setuptcp: protocol > mismatch [0] not listening on 127.0.0.1 port 3493 Ouch! This is unexpected. Apparently, getaddrinfo() returned one addrinfo element, which is what we expected since we explicitly asked for a TCP listening socket: > hints.ai_flags = AI_PASSIVE; > hints.ai_family = opt_af; > hints.ai_socktype = SOCK_STREAM; > hints.ai_protocol = IPPROTO_TCP; But for whatever reason, it returns an addrinfo element for a IPPROTO_IP protocol. That might be OK, but is not what we expected. POSIX is not really clear about this: > If ai_family is not AF_UNSPEC and ai_protocol is not zero, then > addresses are returned for use only with the specified address family > and protocol; the value of ai_protocol shall be interpreted as in a > call to the socket() function with the corresponding values of > ai_family and ai_protocol. I would be *very* grateful if you could find the time to checkout the following two scenarios: 1) Startup the server through upsd -4 -DDD This will set the hints.ai_family to AF_INET and instructs getaddrinfo() that the returned addrinfo element will be used for an IPv4 listening socket). Now it should return an IPPROTO_TCP [6] addrinfo element. See if this improves the outcome. 2) Comment out the 'continue' statements on lines 277 and 282 of the file server/upsd.c and recompile the thing. Now start the server again through upsd -DDD This will effectively ignore a sockettype and protocol mismatch and basically trust that whatever getaddrinfo() is returning is correct. Since we pretty much rule out any other addrinfo elements through the hints we gave to it, this is not necessarily a bad thing to do. Please be kind to us mere mortals and don't use truss anymore, unless we explicitly ask for it. It adds no useful information to us and really is a pain to weed out the good bits. Best regards, Arjen _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
