I'm using Embarcadero RAD Studio XE3 with its TIdSNMP Indy SNMP component to prepare and send SNMP trap notifications to an Enterprise Server. I set up to 12 varbinds depending on the trap type, and Wireshark is seeing and properly dissecting the traps on the target host. It appears that my end is working fine.
The Manager side of this system does not seem to recognize these traps and can't decode them according to the implementation team. They have pointed to the SNMP version item in the trap itself, which is 'v2u'. Because this version is deprecated, they would like to see version 'v2c', and they assert that all their other traps are this version.
The question is, do I have any options as far as what version of trap to send? I see TIdSNMP::Trap has a Version member; is it as simple as setting this to 3?
This is the code I'm using:
void SendTrap(int atcsfield)
{
/* TIdSnmp *snmp = new TIdSNMP(0); */
snmp->Trap->Clear();
snmp->Trap->Version = 2;
snmp->Trap->Community=String(cfg.snmp.community);
snmp->Trap->TimeTicks = GetTickCount() - InitialTickCount;
snmp->Trap->Enterprise=String(cfg.snmp.oid);
snmp->Trap->GenTrap=6;
snmp->Trap->SpecTrap=1;
for(int i=0;i<MAX_VARBINDS;i++)
{
if(svb[i].Length())
{
varb.sprintf("%s.1.%d",BaseOID.c_str(),i);
snmp->Trap->MIBAdd(varb,svb[i], ASN1_OCTSTR);
}
}
for(int i=0;i<MAX_VARBINDS;i++)
{
if(ivb[i]!=-1)
{
varb.sprintf("%s.1.%d",BaseOID.c_str(),i);
snmp->Trap->MIBAdd(varb, ivb[i], ASN1_INT);
}
}
snmp->Host = ManagerIpList->Strings[j];
snmp->SendTrap();
}
At this time, TIdSNMP only supports SNMPv1. Setting Trap->Version to 2 does not send a v2/v3 formatted trap, as the layout of the trap PDU is different between v1 and v2/v3.
Support for newer SNMP versions is on Indy's todo list:
Update TIdSNMP to support newer SNMP versions
https://code.google.com/p/indyproject/issues/detail?id=139
http://indy.codeplex.com/workitem/19076
Related
Trying to use MS Speech API v11 with a Japanese engine (MS Haruka) in Delphi 10.3.
I have a sample app with a form and a button. The click handler goes:
uses SpeechLib11_TLB; // Imported from "Microsoft Speech Object Library" v.B.0
procedure TForm1.Button1Click(Sender: TObject);
var
v: ISpeechVoice;
begin
v := CoSpVoice.Create();
//5.4 only but won't hurt
v.Voice := v.GetVoices('language=411', '').Item(0);
v.Speak('時間', SVSFDefault);
end;
That causes an error, "Catastrophic failure" (HRESULT 0x8000FFFF, E_UNEXPECTED). The code that I think should be equivalent works in a C++ project:
#include <windows.h>
#import "libid:d3c4a7f2-7d27-4332-b41f-593d71e16db1" rename_namespace("SAPI") //v11
//#import "libid:C866CA3A-32F7-11D2-9602-00C04F8EE628" rename_namespace("SAPI") //v5.4
int wmain()
{
CoInitializeEx(0, COINIT_APARTMENTTHREADED);
{
SAPI::ISpeechVoicePtr v;
v.CreateInstance(__uuidof(SAPI::SpVoice));
//Needed for 5.4 only, but won't hurt
SAPI::ISpeechObjectTokensPtr voices(v->GetVoices(L"language=411", L""));
v->Voice = voices->Item(0);
v->Speak(L"時間", SAPI::SVSFDefault);
}
CoUninitialize();
return 0;
}
That works and speaks. So the SAPI per se is not broken on the machine. The platform is Win32 in both projects, not Win64. The Japanese voice is the default one (no need to set it explicitly).
Same result with SAPI 5.4 proper (not OneCore), although the Japanese voice is not the default one and I had to add a couple of lines to set it as the default.
Further debugging reveals that on the Delphi side, as much as calling the v.Voice property getter immediately after the first line causes the same error, E_UNEXPECTED. Meanwhile, the Voice setter works if you pass it a valid voice token object from GetVoices(). It looks as if the voice object initializes itself to its defaults correctly in C++, but somehow skips that in the Delphi project.
Requesting v.Voice right after construction works though in Delphi with SAPI 5.4. Calling Speak() still throws a E_UNEXPECTED.
What could be the difference in process/threadwide execution context between C++ and Delphi? It's not the thread locale. The COM thread model is apartment in both.
The same Delphi code works with an English phrase and an English voice (MS Helen). So whatever init failure there might be, it's probably specific to Haruka.
The SAPI 11 runtime is available here. The language data for TTS are here.
Another data point. I've rewritten the SAPI logic in Delphi to use SAPI 5.4 OneCore instead (not SAPI 5.4 proper). Unlike 5.4 and 11, it doesn't expose an IDispatch-based interface, and it's somewhat clumsier specifically in Delphi, but Japanese TTS works. The question, as initially posed, is still unanswered, but at least there's a workaround. I'll write up an answer, but I won't accept it.
However, it's not the custom vs. dual distinction that's to blame. I've changed the logic to use custom interfaces instead of automation ones with SAPI 5.4 proper (the typelib defines both), still got E_UNEXPECTED from Speak(). There's no error info.
Here's another beautiful data point: SAPI 5.4 TTS with automation based API works and talks as expected in a Delphi console app. So it's not even Delphi specific, it's somehow VCL specific. What is it with Delphi GUI? Needless to say, I immediately retested the C++ snippet in a C++ GUI application, with a form and a button. The C++ one talks.
Not an answer, but a workaround.
Windows 10 comes with two flavors of 32-bit SAPI. There's SAPI 5.4 proper (in system32\speech), and also SAPI 5.4 OneCore (in system32\speech_onecore). The latter, even though it's superficially the same, exposes a different typelib - there's no automation support, all interfaces are custom instead of dual. What's more important, when you download the Japanese TTS voice in the Windows 10 Settings app, you end up with 3 voices under OneCore (Sayaka, somehow, missing) and only one, Haruka, under 5.4 proper.
Delphi can consume custom interfaces in a typelib, but the methods look somewhat clumsier. Also, the enumeration of voices in the automation API is cleaner. Anyway, here goes.
uses SpeechLib54Core_TLB; // This time it's OneCore
procedure TForm1.Button1Click(Sender: TObject);
var
v: ISpVoice;
cat: ISpObjectTokenCategory;
toks: IEnumSpObjectTokens;
tok: ISpObjectToken;
sno: LongWord;
hr: HResult;
n: Cardinal;
begin
v := CoSpVoice.Create();
hr := v.GetVoice(tok);
tok.GetCategory(cat);
cat.EnumTokens('language=411', '', toks); //411 means Japanese
toks.GetCount(n);
if n = 0 then
exit; // No Japanese voices installed
toks.Item(0, tok); //Take the first one - typically Ayumi
v.SetVoice(tok);
v.Speak('時間', 0, sno);
end;
Note that passing a Japanese string literal to a COM method works without an explicit cast to a wide string.
I have a .dll written in C++/Builder of 2007, that uses GSOAP for it's connections to a webservice, It seems to require the location of a .PEM file and it's password (This file is created form a .pfx file delivered by the service organization to authenticate and encrypt). Besides gsoap, it uses openSSL version 0.9.8
Now I need to update SSL to TLS1.2, and this is not covered with openSSL 0.9.8, and updating to version 1.0.2 (the latest I could use) is impossible, because I get a bunch of errors in the OpenSSL code on compilation.
Translation to Delphi 2007 did not really help - since Indy lacks required facilities as well (SOAP1.2 is not supported, it seems) .
However, moving to Ddelphi2018 is on my TODO list so I moved the code for this process to a standalone program (for now) to Delphi. All seems well except for one thing:
in gsoap file stdsoap2.h, there is:
struct SOAP_STD_API soap
…
unsigned short ssl_flags;
const char *keyfile;
const char *password;
…
and the C++ code uses this
struct soap soap;
memset(&soap, 0, sizeof(soap));
...
soap.keyfile = Parms->pCERTIFICAAT; // is .pem bestand, including path
soap.password = "(Certww)"; // hardcoded in deze code....
...
However, In Delphi/Indy I don't see any way to add this data; searc in the internet does give examples of username and password, but seartching on keyfile doesn't show any hits...
What does this do in gsoap, and how to the same in Delphi (2018) / Indy10 ?
Indeed - 10.2 Tokyo..
We found the solution in re-importing the WSDL's into Delphi and use code we already had for accessing certificates.
How to query and get results from remote database using DataSnap technology in C++ Builder 10.1 Berlin ?
I want to build a simple solution having two VCL Forms Applications, like client(1) and server(2), running on two different windows os computers, connected on same local network.
But I cannot accomplish this simple task and this is what I tried to do:
On the server application (2), I use:
TSQLConnection *SQLConnection1;
TSQLQuery *SQLQuery1;
and I will load a SQLite database version 3:
if (SQLConnection1->Params->IndexOf("Database") == -1)
{
SQLConnection1->Params->Add("Database="+Form->DataBaseFile );
}
else
{
SQLConnection1->Params->Values["Database"] = Form->DataBaseFile;
}
try
{
SQLConnection1->Connected = true;
}
catch (EDatabaseError& E)
{
ShowMessage("Exception raised with message" + E.Message);
}
and execute sql query:
try
{
SQLQuery1->SQL->Text = "query from client app(1)";
SQLQuery1->Active = false;
SQLQuery1->ExecSQL();
}
catch (Exception& E)
{
ShowMessage( "SQLite exception raised with message:\n\n" + E.Message);
SQLConnection1->Connected = false;
}
and I need to return SQLQuery1 results back to client app(1)
On the client application I think I should do something like below, but I'm not sure, I don't know how to do this correctly:
TSQLServerMethod *SQLServerMethod1;
SQLServerMethod->SQLConnection = SQLConnection1;
try{
SQLServerMethod.ServerMethodName = "TDSUtilityMethods.echoOutStr";
SQLServerMethod->Params[0]->AsString = "123";
SQLServerMethod->ExecuteMethod();
memoOutput->Text = SQLServerMethod->Params[1]->AsString;
}
finally{
SQLServerMethod->Close();
}
So the purpose is to make a server application(2) which host and execute sql queries from client app(1) which sends the sql query and waits for results. The application(1) which send sql query is a wrapper of chromium client. I tried to achieve all this solution using TIdHTTPServer on sever app(2) and WebSockets from chromium client app(1), and posted a releated question here but implementing WebSocket protocol(encoding/decoding packets) is a bit hard for an amateur developer. And then I found that a easier solution could be using DataSnap technology. I have read about Developing DataSnap Applications, but still not able to build this simple solution, on embarcadero website are described each component, but because I'm amateur developer, I found it confusing and hard to complete a simple task which seems possible and easier to build using DataSnap technology than WebSockets. But now I found hard to implement DataSnap technology, because there is a lot of new things which are confusing without examples.
Please if you know how to do this in C++ Builder 10.1 Berlin, show here a short sample of that.
Environment: Windows 10 Professional 64-Bit.
I want to build / install a go-project (twitterbeat as you can see).
C:\apps\Go_workspace\src\github.com\buehler\twitterbeat>go build
# github.com/buehler/twitterbeat/beater
beater\twitterbeat.go:62: b.Events undefined (type *beat.Beat has no field or method Events)
Here you can see line 62 of the file:
func (bt *Twitterbeat) Setup(b *beat.Beat) error {
logp.Info("Setup waitduration and api keys")
bt.events = b.Events
var err error
bt.period, err = time.ParseDuration(*bt.beatConfig.Period)
if err != nil {
return err
}
anaconda.SetConsumerKey(*bt.beatConfig.Twitter.ConsumerKey)
anaconda.SetConsumerSecret(*bt.beatConfig.Twitter.ConsumerSecret)
bt.api = anaconda.NewTwitterApi(*bt.beatConfig.Twitter.AccessKey, *bt.beatConfig.Twitter.AccessSecret)
return nil
}
I don't think that the code is wrong, because I donwloaded it directly from Github.
Because I am not on a linux / unix system (and I had problems with the proxy), i couldn't run "glide". Instead I donwloaded all dependencies by myself.
What can I do to build twitterbeat?
When you download the dependencies by hand, you need to make sure that they are the same version as in the glide.yaml file. The current version of beat.Beat in github.com/elastic/libbeat/beat/beat.go is newer than the one in the glide.yaml and doesn't have an Events field any more.
It's not your problem,but a fault of the library you are using.
As the code shows,it used github.com/elastic/beats/libbeat/beat,then we jump to the source of beat,the Beat struct is:
type Beat struct {
Name string // Beat name.
Version string // Beat version number. Defaults to the libbeat version when an implementation does not set a version.
UUID uuid.UUID // ID assigned to a Beat instance.
BT Beater // Beater implementation.
RawConfig *common.Config // Raw config that can be unpacked to get Beat specific config data.
Config BeatConfig // Common Beat configuration data.
Publisher *publisher.Publisher // Publisher
filters *filter.FilterList // Filters
}
It doesn't have Events field anymore!
You can use the old version of the library github.com/elastic/beats/libbeat/beat,or you can push a issue to the owner of github.com/buehler/twitterbeat to inform him to fix this bug.
I have the following declaration for DNSServiceRegister:
function DNSServiceRegister
(
var sdRef: TDNSServiceRef;
const flags: TDNSServiceFlags;
const interfaceIndex: uint32_t;
const name: PUTF8String; //* may be NULL */
const regType: PUTF8String;
const domain: PUTF8String; //* may be NULL */
const host: PUTF8String; //* may be NULL */
const port: uint16_t;
const txtLen: uint16_t;
const txtRecord: Pointer; //* may be NULL */
const callBack: TDNSServiceRegisterReply; //* may be NULL */
const context: Pointer //* may be NULL */
): TDNSServiceErrorType; stdcall; external DNSSD_DLL;
In my Bonjour framework I have the following response to an announced service being made active (i.e. to actually start announcing itself, via Bonjour):
procedure TAnnouncedService.Activate;
var
flags: Cardinal;
name: UTF8String;
svc: UTF8String;
pn: PUTF8String;
ps: PUTF8String;
begin
fPreAnnouncedServiceName := ServiceName;
inherited;
if AutoRename then
flags := 0
else
flags := kDNSServiceFlagsNoAutoRename; { - do not auto-rename }
if (ServiceName <> '') then
begin
name := ServiceName;
pn := PUTF8String(name);
end
else
pn := NIL;
svc := ServiceType;
ps := PUTF8String(svc);
CheckAPIResult(DNSServiceRegister(fHandle,
flags,
0 { interfaceID - register on all interfaces },
pn,
ps,
NIL { domain - register in all available },
NIL { hostname - use default },
ReverseBytes(Port),
0 { txtLen },
NIL { txtRecord },
DNSServiceRegisterReply,
self));
TBonjourEventHandler.Create(fHandle);
end;
This is more verbose than I think it strictly needs to be, certainly it was working perfectly well in Delphi 7 in a much less verbose form. I have expanded a lot of operations into explicit steps to facilitate debugging, e.g. to be able to identify any implicit transforms of string payloads that may be occuring "under the hood" in Delphi 2009.
Even in this untidy expanded form this code compiles and works perfectly well in Delphi 7, but if I compile and run with Delphi 2009 I get no announcement of my service.
For example, if I run this code as part of a Delphi 7 application to register a _daap._tcp service (an iTunes shared library) I see it pop-up in a running instance of iTunes. If I recompile the exact same application without modification in Delphi 2009 and run it, I do not see my service appearing in iTunes.
I get the same behaviour when monitoring with the dns-sd command line utility. That is, service code compiled with Delphi 7 behaves as I expect, compiled in Delphi 2009 - nothing.
I am not getting any errors from the Bonjour API - the DNSServiceRegisterReply callback is being called with an ErrorCode of 0 (zero), i.e. success, and if I supply a NIL name parameter with AutoRename specified in the flags then my service is allocated the correct default name. But still the service does not show up in iTunes.
I am at a loss as to what is going on.
As you might be able to tell from the expansion of the code, I have been chasing potential errors being introduced by the Unicode implementation in Delphi 2009, but this seems to be leading me nowhere.
The code was originally developed against version 1.0.3 of the Bonjour API/SDK. I've since updated to 1.0.6 in case that was somehow involved, without any success. afaict 1.0.6 merely added a new function for obtaining "properties", which currently supports only a "DaemonVersion" property for obtaining the Bonjour version - this is working perfectly.
NOTE: I'm aware that the code as it stands is not technically UTF8-safe in Delphi 7 - I have eliminated explicit conversions as far as possible so as to keep things as simple as possible for the automatic conversions that Delphi 2009 applies. My aim now is to get this working in Delphi 2009 then work backward from that solution to hopefully find a compatible approach for earlier versions of Delphi.
NOTE ALSO: I originally also had problems with browsing for advertised services, i.e. identifying an actual iTunes shared library on the network. Those issues were caused by the Unicode handling in Delphi 2009 and have been resolved. My Delphi 2009 code is just as capable of identifying an actual iTunes shared library and querying it's TXT records. It's only this service registration that isn't working.
I must be missing something stupid and obvious.
Does anyone have any ideas?!
UPDATE
Having returned to this problem I have now discovered the following:
If I have a pre-D2009 and a D2009+ IDE open (e.g D2006 and D2010) with the same project loaded into both IDE's concurrently:
Build and run under 2006: It works - my service announcement is picked up by iTunes
Switch to D2010 and run (without building): It does a minimal compile, runs and works.
Do a full build in D2010: It stops working
Switch back to D2006 and run (without building): It doesn't work
Do a full build in D2006: It works again
Does this give anyone any other ideas?
The answer to this is mind boggling. On the one hand I made a completely stupid, very simple mistake, but on the other hand it should never - as far as I can see - have worked in ANY version of Delphi!
The problem was nothing what-so-ever to do with the Unicode/non-unicodeness of any strings, but was actually due to a type mismatch in the PORT parameter.
I was passing in the result of ReverseBytes(Port) - that parameter expected a uint16_t, i.e. a Word value. My Port property was however declared (lazily) as an Integer!!
Once I fixed this and had Port declared as a Word, it now works on both D2007- and D2009+ versions of Delphi.
Very weird.
I can only think that some other edge-case behaviour of the compiler that might have somehow affected this was changed when Unicode support was introduced.
Based on the information that we have available here, the situation is this:
When calling the DLL with your code in Delphi 2007, it gives one result.
When calling the same DLL with your code in Delphi 2009, it gives another result.
The suspicion is, that it is related to the Delphi 2009 compiler.
Logically, the difference must therefore be, that Delphi 2009 sends different values as parameters. In order to make the debugging truly Delphi-independent, you therefore need to create a dummy DLL, which reports the values it gets. Other Delphi-dependent methods may be applied, like looking at the disassembly of the function-call into the DLL, and debugging it so that we know exactly what values are passed, and how, to the DLL, in both compilers.
I can't find the declaration instruction for the vars "ServiceName" and "ServiceType" in your code sample.
Assuming a String type (thus a unicode string), I guess (yes... no D2009 available to test this) lazy typecasting could be an issue:
name := ServiceName;
Why not use the following?
name := PAnsiChar(AnsiString(ServiceName))
Anyhow... just my 2 cts.
BTW:
I always use the pre defined "EmptyStr", "EmptyWideStr" ... so the test would look like:
if (ServiceName <> EmptyStr) then
which should be safe and avoid the confusion of types.
On the other side, Delphi may interpret the '' as an ANSIChar like the following declaration do:
const
MyParagraphChar = '§';
Not sure... I'm confused - should go home now ;)
If the DLL is not written using Delphi 2009, you may want to use something else than PUTF8String. The Delphi 2009 Utf8String type is different from Delphi 2007's UTF8String type.
If the DLL was written using C/C++, I strongly suggest to use PAnsiChar() instead of PUtf8String.