ANDi Frequently Asked Questions
Error recognizing CRC signal
User could do as first check a database review to be sure that the signal exists and have the CRC flag.
Fire_event function misbehavior
Fire Event/Field requires a correct subscription between ECUs:
The service has an Event Group
The Event/Field in question explicitly belongs to an Event Group
A SOME/IP-SD "Subscribe Event Group ACK" took place for the Event Group
The subscription has not expired (subscription time + TTL < now)
The function "start_capture", the Traffic Viewer and the PCAP Player aren't able to read pcap files
Channels configuration lost
Channels configuration is not saved in the ATP, it's saved in tmp/project_name.
Start capture in scripting environment does nothing
- The on_message_received handler attribution should be done before the start capture call as follows:
# create call back function def callback_function(msg): print(msg) # Set the handler message.on_message_received += callback_function # Start the capture message.start_capture()
Receive and receive_list methods doesn't work
Please check the IP addresses and ports numbers.
How to import external python modules?
import sys
# Specify the directory that contains the python module file
sys.path.append(some_directory_path)
ANDi is not transmitting frames using Vector devices
This behavior happens when making loop-back with Vector hardware between two channels and using only one channel for sending and receiving can messages.
Sender and receiver should use different channels.
ANDi decodes TCP based messages twice
Just remove message.start_capture() and message.stop_capture() from _send_diag_command. There is no need for start_capture() when using connect().
ANDi crashes after script's execution
Please do not use recursive calls that leads to stack overflow exception:
# create recursive method
def myfucntion():
myfucntion()
return
# call the recursive method
myfucntion()
The script's execution leads to memory leak
Packet loss detected
This is coming from an automatic ANDi thread, that monitor the running adapters for packet loss. The packet loss is usually detected by the Npcap driver itself.
- A bit of explanation:
The Npcap driver captures raw packets passing through a network interface. The packets have to be parsed and filtered, and that takes some time, so incoming packets have to be buffered (queued) for processing.
Sometimes there are too many packets, they are saved to a buffer, but they are saved faster than processed, so eventually the buffer runs out of space, so the kernel drops all further packets until there is some free space in the buffer.
- Usual Reasons:
You are sending packets faster than what the adapter/driver could process
Some adapter models/drivers are faulty and cause the problem to happen more often that it should. (example: using the slower USB 2.0 connector for a stress test)
Duplex mismatch
The problem simply could not be avoided, Windows is not a real time OS, and it gives equal chances to all threads to run. This usually does not happen often if the hardware/CPU is fast enough.
Some other software on the server (Firewall or CPU intensive application) is delaying the packets processing.
- This can be avoided when it is caused by a packet length which is higher than MTU. In that case, user needs to configure sender and receiver to support Jumbo Frames as detailed below :
Change the MTU using this command line
netsh interface ipv4 set subinterface "Your Interface Name" mtu=1550 store=persistent
Activate Jumbo Frames in the Device Manager