clang: error: unknown argument about docsis

[frakman1]

I finally got it to work but had to delete this project and start over after installing net-snmp from source first.
Thank you all for the help.

git clone https://github.com/net-snmp/net-snmp
cd net-snmp
./configure
make
sudo make install

git clone https://github.com/rlaager/docsis
cd docsis
./autogen.sh
./configure
make
sudo make install

$docsis --help
DOCSIS Configuration File creator, version 0.9.9-dev
Copyright (c) 1999,2000,2001 Cornel Ciocirlan, [email protected]
Copyright (c) 2002,2003,2004,2005 Evvolve Media SRL, [email protected]
Copyright (c) 2014 - 2015 Adrian Simionov, [email protected]
...

[rlaager]

I hope you get this figured out, or maybe someone stumbles on this to help you.

Just to set expectations, though, I don't do much of anything with this project any more. I only ever barely used it and just acted as a rescue maintainer to give it a home.

I suggest looking at config.log to see if you can figure out where that is coming from.

[frakman1]

Thank you. I looked at config.log and the first instance of this string is here:

configure:13246: checking for netsnmp_init_mib
configure:13264: gcc -o conftest -g -O2 -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -g -Os -pipe -DBUILD=175.1 -DMACOSX_DEPLOYMENT_TARGET=13.0 --sysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -iframeworkwithsysroot /System/Library/Frameworks/-27e8-11ed-bdc1-96898e02b808/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.Internal.sdk/System/Library/PrivateFrameworks/ -27e8-11ed-bdc1-96898e02b808/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.Internal.sdk/System/Library/Frameworks/ -iwithsysroot /usr/local/libressl/include -L/AppleInternal/Library/BuildRoots/5381bdfb-27e8-11ed-bdc1-96898e02b808/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.Internal.sdk/usr/local/libressl/lib -Udarwin22 -Ddarwin22=darwin22 -I. -I/usr/local/include   conftest.c -lresolv  -lnetsnmp >&5
clang: error: unknown argument: '-27e8-11ed-bdc1-96898e02b808/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.Internal.sdk/System/Library/Frameworks/'

I don't know enough about how this works to troubleshoot any more.

[lightfinal]

Same issue here, did some tracking and seems the CFLAGS in the makefile already contains the cut argument. Checking the configure and this arguments should be an invalid argument from the command "net-snmp-config --cflags", so this seems to be an issue with the netsnmp OSX version.
❯ net-snmp-config --cflags -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -g -Os -pipe -DBUILD=175.1 -DMACOSX_DEPLOYMENT_TARGET=13.2 --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -iframeworkwithsysroot /System/Library/Frameworks/-7d96-11ed-886f-a23c4f261b56/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.2.Internal.sdk/System/Library/PrivateFrameworks/ -7d96-11ed-886f-a23c4f261b56/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.2.Internal.sdk/System/Library/Frameworks/ -iwithsysroot /usr/local/libressl/include -L/AppleInternal/Library/BuildRoots/9e200cfa-7d96-11ed-886f-a23c4f261b56/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.2.Internal.sdk/usr/local/libressl/lib -Udarwin22 -Ddarwin22=darwin22 -I. -I/usr/local/include

[silverwind]

On a M3 Mac, I compiled latest net-snmp from master branch and that seems to have gotten rid of the error. Then I ran into another error while building the tool:

./docsis_symtable.h:1585:90: error: incompatible function pointer types initializing 'decode_func_t' (aka 'void (*)(unsigned char *, struct symbol_entry *, unsigned long)') with an expression of type 'int (unsigned char *, void *, struct symbol_entry *)' [-Wincompatible-function-pointer-types]
{ 1533,    "IpModeControl",                    1,       1532,   (encode_uchar),          (encode_uchar),          0,           2             }, /* TLV 217.1 HOST2.1-I17 15.2.6 */
                                                                                         ^~~~~~~~~~~~~~

The following patch seems to fix it and it built fine after it, but I have no idea whether it's correct.

diff --git a/src/docsis_symtable.h b/src/docsis_symtable.h
index 923054c..bb2b070 100644
--- a/src/docsis_symtable.h
+++ b/src/docsis_symtable.h
@@ -1581,9 +1581,9 @@ symbol_type symtable[NUM_IDENTIFIERS] =  {
 { 237,    "SNMPv3AccessViewType",              4,      233,    (encode_uchar),          (decode_uchar),          1,           2             }, /* TLV 202.54.4 eRouter-I12 Annex B.4.6.4 */

 /* eSTB Settings */
 { 1532,    "EstbSettings",                     217,     0,      (encode_nothing),        (decode_aggregate),      0,           0             }, /* TLV 217 eDOCSIS-I30 5.2.8.1 */
-{ 1533,    "IpModeControl",                    1,       1532,   (encode_uchar),          (encode_uchar),          0,           2             }, /* TLV 217.1 HOST2.1-I17 15.2.6 */
+{ 1533,    "IpModeControl",                    1,       1532,   (encode_uchar),          (decode_uchar),          0,           2             }, /* TLV 217.1 HOST2.1-I17 15.2.6 */
 { 1534,    "Snmpv1v2Settings",                 53,      1532,   (encode_nothing),        (decode_aggregate),      0,           0             }, /* TLV 217.53 HOST2.1-I17 15.2.1 */
 { 1535,    "Snmpv1v2CommunityName",            1,       1534,   (encode_string),         (decode_string),         1,           32            }, /* TLV 217.53.1 HOST2.1-I17 15.2.1.1 */

 /* Generic TLV ... we only use the limits, code and length don't matter ...*/

[rlaager]

That looks sane to me. Thanks!

For the record, I did absolutely zero testing of this. I don't use this tool; I'm just trying to give this project a home.

[silverwind]

Thanks.

When running the freshly compiled arm version I do notice there are some 1-byte differences in the encoding results compared to the x86 version I built a long time ago, but I think they are at least not related to above change as this IpModeControl is nowhere found in the sources. More likely, I guess the encoding differences come from the net-snmp library or somewhere else.