Menu
▾
▴
[Sblim-issues] [ sblim-Bugs-1945390 ] Request for SLP service URL hostname override
|
From: SourceForge.net <no...@so...> - 2008-07-31 10:40:28
|
Bugs item #1945390, was opened at 2008-04-17 21:06 Message generated for change (Comment added) made by tyreld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1945390&group_id=128809 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: sfcb Group: New Feature >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Nicholas Bofferding (bofferdn) Assigned to: Tyrel Datwyler (tyreld) Summary: Request for SLP service URL hostname override Initial Comment: [Problem] SFCB is configured to fork during initialization and automatically register the WBEM SLP template properties with a local SLP service. Our particular embedded environment might configure a default hostname 'XYZ' (related to the serial # of the machine) and a network interface with an IPv4 address on a private subnet, say 10.0.0.2. In this default configuration, the hostname does not resolve to the 10.0.0.2 IP address. In this case, the SLP response will return a service URL attribute such as: (template-url-syntax=https://XYZ:5989) Unfortunately, a client could not use that URL to connect to the machine, since the hostname does not resolve to a valid IP address. It turns out we have a separate firmware component which registers (via SLP) a service URL for a web server. In this case, the firmware selects the IP address (there could be several to choose from, especially if IPv6 is considered) of a particular network interface instead of the machine's host name. The SLP attribute for that looks like https://<eth0 ip>:<port> We're looking for a similar way to provide a custom value that SFCB can use to replace the hostname part of the template-url-syntax property. One possible solution .. if configured with the appropriate option, SFCB could dynamically load a user supplied library. The user supplied library would run custom code to determine the IP address to use in the service URL. SFCB would then substitute the hostname part of the service URL with the IP address. ---------------------------------------------------------------------- >Comment By: Tyrel Datwyler (tyreld) Date: 2008-07-31 03:40 Message: Logged In: YES user_id=640104 Originator: NO Fixed SLP registration crash with setupControl() and sunsetControl() calls around getControlChars() calls. (Nick, thanks for the detailed report and reference to the 2015639 bug.) Increased buffer size in default override library to allow for NULL string terminator. New patch and override library attached. ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-07-31 03:34 Message: Logged In: YES user_id=640104 Originator: NO File Added: sfcSlpHostname.c ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-07-31 03:32 Message: Logged In: YES user_id=640104 Originator: NO File Added: slp-hostname-lib-v2.patch ---------------------------------------------------------------------- Comment By: Nicholas Bofferding (bofferdn) Date: 2008-07-25 13:38 Message: Logged In: YES user_id=2065930 Originator: YES I wanted to clarify my setup a little more (include more patches + compile options): Software includes v1.2.5 SFCB + patches for SBLIM tracker 1946202 + SBLIM tracker 1946188 + SBLIM tracker 1945374 + SBLIM tracker 1945390 (substituting my own override library) in conjunction with the patch from SBLIM tracker 2015639 under the following conditions: a) SFCC_CLIENT environment variable set to "SfcbLocal" before starting SFCB, to force SFCB to use the localconnect interface for SLP registration b) SLP server running c) SFCB compiled with the --enable-slp-hostname-lib "--enable-ssl" and "--enable-slp". Latest SFCC package. ---------------------------------------------------------------------- Comment By: Nicholas Bofferding (bofferdn) Date: 2008-07-25 12:28 Message: Logged In: YES user_id=2065930 Originator: YES I ran this patch (substituting my own override library) in conjunction with the patch from tracker 2015639 under the following conditions: a) SFCC_CLIENT environment variable set to "SfcbLocal" before starting SFCB, to force SFCB to use the localconnect interface for SLP registration b) SLP server running c) SFCB compiled with the --enable-slp-hostname-lib Under these conditions, the SFCB registers the SLP attributes with the SLP server correctly the first time through. On the 2nd pass (10 min. later by default, can be sped up via the config file), the SLP registration process crashes. Here's the back trace: #0 0x0ff64910 in getControlChars (id=0xfecc370 "slpHostnamelib", val=0x7f860374) at control.c:209 #1 0x0fec9794 in getSLPData (cfg= {commScheme = 0x100198f0 "https", cimhost = 0x10019900 "localhost", port = 0x10019910 "5989", cimuser = 0x10019920 "", cimpassword = 0x10019930 "", trustStore = 0x10015760 "", certFile = 0x0, keyFile = 0x10015748 ""}) at cimslpCMPI.c:149 #2 0x0fec8d74 in forkSLPAgent (cfg= {commScheme = 0x100198f0 "https", cimhost = 0x10019900 "localhost", port = 0x10019910 "5989", cimuser = 0x10019920 "", cimpassword = 0x10019930 "", trustStore = 0x10015760 "", certFile = 0x0, keyFile = 0x10015748 ""}, slpLifeTime=600, sleepTime=585) at cimslp.c:106 #3 0x0fec90b0 in slpAgent () at cimslp.c:160 #4 0x10002f84 in startSLPAgent () at sfcBroker.c:482 #5 0x1003aa0 in main (argc=2, argv=0x7f860a44) at sfcBroker.c:757 This looks very similar to failure observed in tracker 2015639. I looked at the "ct" variable (the global from control.c of SFCB files that was causing problems with 2015639) at the time of failure, and it was NULL. So, it looks like 'ct' is not initialized at the time of the fail. Some background; the 2015639 patch fixed the case where SFCB calls "getControlChars" from within the "localConnect" function inside the cimClientSfcbLocal.c file. The localConnect function calls setupControl() to allocate memory, then "getControlChars", then sunsetControl() to deallocate memory. This part now works since the sunsetControl() is correcting setting "ct" to NULL. I believe the following is happening: a) In cimslp.c , slpAgent() function calls "setupControl" to allocate some memory, calls forkSLPAgent(). At this point, ct is set to some != NULL value. b) forkSLPAgent() calls getSLPData() (location: cimslpCMPI.c) in a loop forever c) getSLPData(), within the code under the "#ifdef SLP_HOSTNAME_LIB" section, calls "getControlChars()". This works the first time since "ct" has a value. d) Continue following the stack trace as per tracker 2015639. This will call "setupControl()" and sunsetControl(). When sunsetControl() returns, "ct" will be NULL. e) Continue processing to finish initial SLP registration. After the registration period elapses, repeat step c) -> e). Step c) will fail and lead to a crash because the "getControlChars()" will try to dereference "ct", which is now NULL. To fix, I'm guessing you could simply call "setupControl" and "sunsetControl" around the call to "getControlChars()" in the getSLPData() function. Probably would need to call setupControl with the "configfile" as an argument (see example in slpAgent() function in cimslp.c. ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-07-23 12:13 Message: Logged In: YES user_id=640104 Originator: NO File Added: sfcSlpHostname.c ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-07-23 12:07 Message: Logged In: YES user_id=640104 Originator: NO I think I posted the wrong file. The hostname assignment is wrong. It clearly should have been: *hostname = sn; instead of: hostname = &sn; I'll fix the attached file. ---------------------------------------------------------------------- Comment By: Nicholas Bofferding (bofferdn) Date: 2008-07-15 16:58 Message: Logged In: YES user_id=2065930 Originator: YES I verified the patch behaves as expected when loading a custom library which provides an override to the default hostname. However, when I instead use the default override library (libsfcSlpHostname.so*), the SLP attribute process crashes while collecting the override hostname. It looks like the _sfcGetSlpHostname function doesn't return the hostname correctly. Basically the function allocates local char* (sn) on the stack and tries to assign its address to hostname. But, at this point hostname is acting locally. Thus function returns success but the caller does not get back a valid pointer. +extern int _sfcGetSlpHostname(char **hostname) +{ + char *sn; + sn = (char *) malloc(strlen("mycimom.com") * sizeof(char)); + sn = strncpy(sn, "mycimom.com", strlen("mycimom.com")); + printf("-#- Request for custom SLP service hostname: (hostname = %s)\n", sn); + hostname = &sn; + + /* Return value of 1 for successs and 0 for failure. */ + return 1; +} I ended up doing something more like the following for the override function, which stopped the crashes: extern int _sfcGetSlpHostname(char **hostname) { l_rc = 0; char* l_pOverride = strdup("mycimom.com"); if(l_pOverride != NULL) { *i_pHostname = l_pOverride; l_rc = 1; } return l_rc; } ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-06-08 22:36 Message: Logged In: YES user_id=640104 Originator: NO File Added: sfcSlpHostname.c ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-06-08 22:35 Message: Logged In: YES user_id=640104 Originator: NO File Added: slp-hostname-lib.patch ---------------------------------------------------------------------- Comment By: Tyrel Datwyler (tyreld) Date: 2008-06-08 22:22 Message: Logged In: YES user_id=640104 Originator: NO Attached patch supporting requested feature. Attached simple library with hardcoded hostname. Added following configure option: --enable-slp-hostname-lib Added following config file option:value pair: slpHostnameLib : sfcSlpHostname SFCB expects the following function to be present in the hostname library: int _sfcGetSlpHostname(char **hostname) The function is responsible for allocating the memory for hostname and SFCB is responsible for freeing it. Return values of 1 for success and 0 for failure. A failed call will default back to the system hostname. ---------------------------------------------------------------------- Comment By: Nicholas Bofferding (bofferdn) Date: 2008-04-22 13:47 Message: Logged In: YES user_id=2065930 Originator: YES We crisped up the request in a meeting today. The following is requested: SFCB provides a new compile option whose name is TBD by SFCB team. If the new compile option is not set, then at every SLP polling interval, SFCB gathers the hostname and inserts it into the service URL as it does today. Otherwise, if the new compile option -is set-, then at every SLP polling interval, SFCB instead dynamically loads a custom library (there may need to be a TBD configuration file option to indicate which library to load) and calls an interface within that library that returns a custom string (to override the hostname; either the calling function will have to allocate a default memory buffer to contain the string, or the special library will have to malloc the string memory and the caller will have to free it later). SFCB then inserts that custom string into the service URL in place of the hostname before registering the SLP attributes w/ the SLP server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1945390&group_id=128809 |