In my environment I see too many messages coming from the vr_ad. typical "disturbing" example:
Three consecutive messages, all informing of one access – reading from address 0x5
[14] C_BUS: (info - Fetch) Fetch EX_CBUS_MAP vr_ad_map-#1, address: 0x00000005
[14] C_BUS: (info - Fetch) Fetch XCORE vr_ad_reg_file-#2, address: 0x00000005
[14] C_BUS: (info - Fetch) Fetch EX_PROXY_REG vr_ad_reg-#7 in XCORE vr_ad_reg_file-#2, addr 0x00000005, data 0x00000008
Why are there so many messages?
And how can I remove these messages?
Seems that you work with verbosity MEDIUM or even higher. To reduce amount of messages, you can change verbosity to LOW (and then you will see only the last message - the one from the vr_ad_reg, and not from its containers), or even to NONE - and then you will get only critical messages.
To change verbosity - you can use either the set message command, or message_manager api. (the messages configuration is per instance - so you can have different vr_ad messages verbosity for each sub-environment)
For example -
specman>set message sys.env.sub_env1 -tag=VR_AD_MSG HIGH
or
extend my_env {
post_generate() is also {
message_manager.set_screen_messages(me,
VR_AD_MSG,
FULL);
};
};
Another thing you might want to do is filtering message based on "direction" - different setting for update, fetch, and compare_and_update.
For example - to avoid getting messages that come after write (vr_ad update() ), but see messages coming from compare_and_update() -
vr_ad remove update messages
vr_ad add compare messages
Related
I have REST service running on a server using Python flask. I have REST client which is built using java. I need to send two binary message in single Http REST request. The reason these are two because they both different protobuff message type but are inter-related to each other and should go in single HTTP request. How can we accomplish that at send and receive side.
The simplest option here may be to simply declare a wrapper message type:
message FooRequest {
// remove "required" if using proto3 syntax
required Request1MessageType part1 = 1;
required Request2MessageType part2 = 2;
}
and send a single FooRequest composed of the two inner messages. This is not always possible, however, in which case you'll have to implement your own framing mechanism inside the binary payload. A simple but pragmatic option might be to measure the size of the first message (in bytes) - i.e. len, and send:
[len, 4 bytes little endian][message 1, len bytes][message 2]
and decode it again at the other end - i.e. take the first 4 bytes and use that to calculate the ranges of the two inner messages. In anticipation of requiring more messages in the future, it might make sense to include a length prefix against every message (i.e. also include a length prefix for message 2) - but strictly speaking it would be redundant in the current case.
enter image description hereCan someone please help me to solve the init abort happening from our server side.
Verification tag is always coming as 0 from the transmitter end. But receiver is giving some random value of verification tag.
Please help.
enter image description here
In general, it might happen that endpoint is not able to establish association and send ABORT chunk as response on INIT. This might happen in various situation (such as misconfiguration, when you haven't created endpoint on server side for that association; or lack of resources).
INIT chunk is a bit special (packet that carries it always has verification tag set to zero in common header). INIT chunk also has so called initiate tag - it is basically a verification tag that sender of the INIT chunk expect to see in all the packet it will receive in the scope of this association.
When ABORT is sent as a response on INIT chunk, it will be sent with verification tag set to the initiate tag from INIT. That is exactly what you can see in you wireshark log.
What seems to be strange in you log file is that the sender of ABORT chunk does not follow RFC 4960 in respect to using t-bit.
RFC 4960, chapter 8.4, bullet 3 says:
If, for whatever
reason, the INIT cannot be processed normally and an ABORT has to
be sent in response, the Verification Tag of the packet
containing the ABORT chunk MUST be the Initiate Tag of the
received INIT chunk, and the T bit of the ABORT chunk has to be
set to 0, indicating that the Verification Tag is NOT reflected.
In your case the sender of ABORT chunk is using initiate tag as verification tag (as defined in RFC), but it also sets t-bit to 1 - it is a violation of RFC. Since t-bit is set incorrectly in the packet that carries ABORT chunk, it stop the sender of INIT from handing it correctly. Basically the sender of INIT chunk cannot handle that ABORT.
The sender of ABORT could have also include cause code in ABORT chunk to provide more details about reason of ABORT. However for whatever reasons it hasn't been done and the actual reason of ABORT will remain mystery.
In conclusion:
It is hard to say why the ABORT has been sent based on information
provided. If you can - contact you vendor and suggest to include
cause code in the ABORT chunk as it defined in RFC in order to make
debugging easier.
I would guess that something has not been initialized/configured on you server side, that is why the association is not setup up. I
would start with checking sockets/endpoint configuration on server
side.
The server side of your association (receiver of INIT/sender of ABORT) violates RFC 4960 and set t-bit incorrectly. Because of that
the sender of INIT chunk cannot handle ABORT correctly. I would
suggest to submit a bug report for your server side
implementation/vendor in order get it fixed.
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
I am building a mailout capability and it is working OK as far as it goes. However, I want to distinguish between various potential (high level) outcomes in order to determine what happens to each message after the current send attempt.
This must be a common requirement so I seem to be missing something pretty obvious, but I can't find anything that addresses it, either here or via Google or on PHPMailer site or .. . Possibly because there are so many questions about specific errors that I just can't find anything useful in all the other results.
At very high level:
Attempt send, and assess resulting error/result. Identify whether this message has been sent, must be retried later, or failed permanently.
- success -> update message status as 'SENT: OK'
- sent, but some issues (e.g. one recipient failed, others processed OK)-> 'SENT: some error'
- failed, due to temporary problem (e.g. connection problem, attachment open) -> 'TRY LATER'
- failed, due to message-specific problem that we should NOT try to resend-> 'FAILED: some error'
As I was unable to find an existing resource with e.g. a table of errors, I spent some time working through the phpmailerException code to try to build one myself, but it's not simple because a) they don't appear to have been designed in terms of this kind of grouping logic, b) it is not easy to uniquely identify a particular error: PHPMailer provides human-friendly messages, which are different in different languages, rather than an identifiable code - given that my solution will need to work across different language installations that's a problem!
Obviously SMTP itself provides a range of errorcodes which I could potentially use for this purpose, but how do I access these via PHPMailer? (This would work for me as I only use SMTP at this point - however, this would NOT work if other message transport like sendmail was used, so I would prefer a PHPMailer solution)
If you want individual result codes for individual address, you really need to send each message separately. If you do get errors on some recipients, they will be listed in the ErrorInfo property - look in the smtpSend function to see how the error string is assembled. I agree that it's not especially easy to parse that info out. The error messages in PHPMailer are generally more for the developer than the end user, so the translations are not that significant. You can get slightly more information about errors if you enable exceptions rather than relying only on return values.
I was hoping someone can shed some light on how the Quickfixn engine handles outgoing FIX messages... I have an outgoing connection set up, and I'm getting heartbeats. When I generate an outgoing message however, it gets rejected because it says that tag 58 is invalid for this message type... (35=AE) ... Normally, if this was an inbound connection, I could just modify the Data Dictionary and everything would be fine... but seeing as how this is an outgoing connection, plus I have my
UseDataDictionary property set to 'N' ... what does the quickfix engine use to validate the outgoing message? Can something be changed to allow the engine to pass the message ? Or is the only resolution not to include this tag in my outgoing message?
Any help on this matter would be greatly appreciated.
Edit-
The message is getting rejected by the quickfix engine. The message that I'm constructing and the respective reject message are:
8=FIX.4.4 9=400 35=AE 34=38 49=XXX 52=20130528-23:11:04.040 56=YYY 31=1.3022 32=1000000.00 39=0 55=EUR/USD 58=ABCD 60=20130528-22:34:52.000 64=20130531 75=20130529 570=N 571=ABCD 5495=0 5971=1302200.00 552=1 54=2 37=ABCD 453=3 448=LP1-DBAB 447=D 452=17 448=XXX 447=D 452=1 448=XXX 447=D 452=19 15=EUR 120=USD 10=082
8=FIX.4.4 9=130 35=3 34=38 49=YYY 52=20130528-23:11:04.283 56=XXX 45=38 58=Tag not defined for this message type 371=58 372=AE 373=2 10=033
I've seen incoming messages get rejected by the quickfix engine because the data dictionary didn't have the correct specs for the message... I thought this might be the same thing but the outgoing connection doesn't seem to use the data dictionary.
Your FIX library does not reject a message. The message is sent to the counter-party instead, which then rejects your message as invalid upon receiving and validating it. And the reason for that is because tag 58, if present, must be a part of “NoSides repeating group (tag 552), which in your case it is not, making the message ill-formed. What you have to do is send a "logically" correct message. I recommend you refer to the appropriate FIX protocol specification for a reference on how to construct a correct message.
Vlad's answer is correct, but I want to alert you to one other danger in your question.
I have my UseDataDictionary property set to 'N'
I am 90% sure you don't want to do this. Whatever you think you're gaining by using =N is probably based on a misunderstanding of something.
Without a DD, you can't read messages with repeating groups, because the engine won't know what fields go in what group.
In practice, every venue uses repeating groups. Therefore, you'll need to set UseDataDictionary=Y and you need to specify an xml file with DataDictionary=<file>.
The only reason we allow =N in QF/n is to be consistent with QF/C++ and QF/j.