I am facing a divergence of racing information requested directly by the Uber application and my software. When prompted directly by the Uber application, the address sent to the driver is exactly as entered. When prompted by my software and sent via API Request, the address sent to the driver is with street number range.
I'm sending start_latitude, start_longitude and start_address.
Here's an example:
Start address: Av. Das Camélias, 263 - Nova Suíssa, Belo Horizonte - MG, Brazil
Start_Latitude: -19.932592
Start_Longitude: -43.975979
Address received by the driver:
Av. Das Camélias, 236-260 - Nova Suíssa, Belo Horizonte - MG, Brazil
Any suggestions on how to confirm that the driver receives the exact address?
What really matters is 'start_latitude' and 'start_longitude' - because this is what will tell the driver what is the pickup location. So if you have those two parameters setup in the 'POST /v1.2/requests' the driver will receive exact location. Address details are modified based on best pick up location - and adjusted by Uber Maps so that is why you are getting the street number as a range.
Related
I am a translator visiting my mum in Guangzhou China after a 3-year Covid lockdown. I am working with a VPN connection. My translation software MemoQ has a Google Machine Translation plug in set up through my Google API account. I can't get the translation suggestions like I usually will in Melbourne. Instead, I have received timeout errors in the log file like the following one:
TYPE:
System.Net.WebException
MESSAGE:
The operation has timed out
SOURCE:
System
CALL STACK:
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at MemoQ.GoogleMT.GoogleMTSession.createRequest(String text, String sourceLangCode, String targetLangCode)
at MemoQ.GoogleMT.GoogleMTSession.useTranslationService(String text, String sourceLangCode, String targetLangCode)
at MemoQ.GoogleMT.GoogleMTSession.TranslateString(String text, String sourceLangCode, String targetLangCode)
at MemoQ.GoogleMT.GoogleMTSession.TranslateCorrectSegment(Segment segm, Segment tmSource, Segment tmTarget)
at MemoQ.TranslationEnvironment.MT.MTManager.backgroundLookupOne(Object parameter)
MemoQ support advises it could be a network issue, and suggest I increase my Time Out threshold, either through Google API, or my VPN provider. Any suggestion will be warmly welcome:).
I have tried the Google Machine Translation plugin in MemoQ at different time and different Wifi, and still has the same time out issue.
Hello I have a google docs document where I installed a simple emailing code on as follows:
function sendMail() {
var file = DriveApp.getFileById('XXXXXXXX');
var recipients = "mymail#group1.com" + "mymail#group2.com" + "mymail#group3.com";
MailApp.sendEmail(recipients, 'Daily Notes', 'Please see file Attached.', {
name: file.getName(),
attachments: [file.getAs(MimeType.PDF)]
});
}
The code works fine it sends the email to multiple group emails which I want it to send. It has done this for a month now. But until recently, I keep receiving this Mail Delivery Subsystem after 20 minutes or 1 hour from the original email which is sent out and inside the error message email it says:
"The following addresses had permanent fatal errors"
and it points to only one of the emails I send daily mails to. It also says something like this: (reason: 554 5.4.6 Too many hops). and then this:
554 5.4.6 Too many hops 53 (50 max).
The Good Doc's file has Google's time-driven trigger as you can see in the image below. I wonder if somehow the trigger is running twice in the time interval I gave to it. Could it be why this is happening?
In almost all cases 554 5.4.6 Too many hops 53 (50 max) means loop along email delivery path e.g. server A forwards to server B, server B forwards to server A, server A forwards to sever B, …. It is detected by counting Received: headers in message passing via give SMTP/email server.
Suggested fixing procedure:
Inspect Reveived: headers in email bounce message to locate server(s) responsible for the loop.
contact the relevant postmaster
In many years I have seen just one "real life" case when bounce message/email like that was not caused by email delivery loop.
Similar the question I asked before in enter link description here, I also need a Log pcap for MAP_OPEN_REQ and MAP_OPEN_DELIMITER_REQ messages.
As I found pcap files containing MAP/TCAP/SCCP protocols enter link description here and enter link description here, but there is no log Pcap for MAP_OPEN_REQ there.
How can I get that?
You won't find MAP-OPEN and MAP-DELIMITER in the pcaps because they are not sent over the wire.
These are common services/primitives used between the MAP service-user and the MAP service-provider. See 3GPP 29.002 - "7 General on MAP services" and "7.5 General rules for mapping of services onto TC".
The inbound roamer IMSI is sent as a parameter in the MAP send authentication info request message from the VPLMN MSC/VLR to the HPLMN HLR as component portion of TCAP dialogue. Here TCAP is MAP provider to transfer MAP service user data to destination MAP service user which is the HLR. In order to send mentioned MAP operation and receive its response, you need to implement whole SS7 layers; TCAP, SCCP and M3UA. You can not send only MAP message without adding other SS7 layers to route your message to target HLR entity. I would propose using Sigtran Softstack solutions to address all issues at once.
I'm developing a product that need to integrate with RADIUS server as an authentication method.
When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.
I did some research on how to do it,
My options are:
Send Access-Request message with fictional user name and password to the RADIUS server
Send Status-Server message to the RADIUS server
RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol.
This packet extension enabling clients to query the status of a RADIUS server.
The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC
My questions are:
Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
Are these vendors supporting Status-Server request - Do they implementing this packet type ?
If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?
Thanks a lot,
Yossi Zrahia
Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.
Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:
IP: 1.2.3.4
Port: 1812
Shared Secret: U7tr453cur3
Servercheck: [x] Status-Server
[ ] Access-Request
Ad 3) From RFC2865, section 5.18 (Reply-Message):
"[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."
There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:
"A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."
RFC1893 claims that status codes will come in the format below you can read more here.
But our bounce management system is having a hard time parsing error status code from bounce messages. We are able to get the raw message, but depending on the email server the code will come in different places. Is there any rule on how to parse this type of messages to obtain better results. We are not looking for the 100% solution but at least 80%.
This document defines a new set of status codes to report mail system
conditions. These status codes are intended to be used for media and
language independent status reporting. They are not intended for
system specific diagnostics.
The syntax of the new status codes
is defined as:
status-code = class "." subject "." detail
class = "2"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
White-space characters and comments
are NOT allowed within a status-
code. Each numeric sub-code within
the status-code MUST be expressed
without leading zero digits.
The quote above from the RFC tells one thing but then the text below from a leading tool on bounce management says something different, where I can get a good source of standard status codes:
Return Code Description
0 UNDETERMINED - (ie. Recipient Reply)
10 HARD BOUNCE - (ie. User Unknown)
20 SOFT BOUNCE - General
21 SOFT BOUNCE - Dns Failure
22 SOFT BOUNCE - Mailbox Full
23 SOFT BOUNCE - Message Too Large
30 BOUNCE - NO EMAIL ADDRESS. VERY RARE!
40 GENERAL BOUNCE
50 MAIL BLOCK - General
51 MAIL BLOCK - Known Spammer
52 MAIL BLOCK - Spam Detected
53 MAIL BLOCK - Attachment Detected
54 MAIL BLOCK - Relay Denied
60 AUTO REPLY - (ie. Out Of Office)
70 TRANSIENT BOUNCE
80 SUBSCRIBE Request
90 UNSUBSCRIBE/REMOVE Request
100 CHALLENGE-RESPONSE
I'm not sure that it's a full answer, but this algorithm for detecting bounces might be useful.