I am trying to set up a simulation of an Ethernet net work in CANoe. This network has two nodes ("input" and "result"). The input node should receive a data stream from the "outside", e.g. another program on my computer. The idea was sending simple data (e.g. 101010 as bits) via TCP/UDP to the input node. This node then transfers these bits to the result node, which simply outputs the received data. So much for the basic setup.
What I am not able to accomplish is the connection from the outside into the CANoe simulation aka the input node. After hours of reading the CANoe help I am still not sure if that is even possible. So has anyone tried something similiar like this or has an idea how to approach this?
I hope it is clear what I want to achieve. I am relatively new to CANoe, so maybe my complete approach is wrong? Some input or alternative ideas would be appreciated.
It is definitely possible. CANoe allows usage of CANoe TCP/IP Stack to isolate Ethernet Communication from ECUs from Windows/OS ethernet communication. To use operating system stack :
In CANoe> Simulation Setup> TCP/IP Stack :
Select the Ethernet network used, set TCP/IP Stack Configuration for the particular network should be selected as "No TCP/IP Stack, use network of operating system"
This way CANoe will have access to windows system network adapters.
Related
I have an "HP NC365T 4-port Ethernet Server Adapter" which is a PCI Express adapter. I also have a Kepler-class GPU with DMA (Direct Memory Access).
I would like to be able to directly transfer data from a socket on the adapter to the GPU, i.e. I don’t want the data to be transferred first to the CPU and then from the CPU to the GPU.
How can this be done? Do I need to use the capabilities of the adapter driver or the driver would not be involved? Ideally I am looking for some sample code to achieve the above.
Unless you have access to the driver source code (or a GPUDirect-compliant driver and stack is already available from the network card vendor), it's not possible to achieve this.
If you have access to the driver source code, the starting point would be to begin with the documentation provided here.
A full tutorial is outside of the scope of an answer I can provide here.
I ask myself that for some days now, and couldn't find a clear answer.
Imagine a network with several rooms, each room with it's own (Layer 2) Switch.
Those are then connected in star topology to another switch which is then connected to the router.
All Clients get IPs from the same range, all clients are in the same subnet and in the same VLAN.
Do you know a way how to determine, which client is connected to which switch, without involving the switch. E.g only with technologies and mechanisms taking place on the client.
The goal would be to be able to draw automated maps of the client distribution in the network, but, as I said, without involving the switch (for example access it's API or somethign like that).
Regards
Me
I am afraid that you are right: In general, in a "normal" Network (which means: In a Network with just Standard Switches and Routers), there is no way to do so.
Only if the Switches were managed, you could write a script which polls the arp-tables from the Switches, but of course this doesn't work with unmanaged Switches.
I realised that there is no way to do this.
The problem is, that a normal network switch, which works on Layer 2 of the OSI model, is not "visible" for tools like traceroute or such.
If you want to traceroute to, lets say: google.com, your traceroute application sends a packet with a TTL of 1 to your default gateway. Your default gateway then decreases the TTL and discards the package, because it has reached a TTL of 0.
Because of that, it answers to your computer and your computer can record, from where it received the first answer.
It then sends again a package to google.com, but this time with a TTL of 2, and the process begins from start.
Now you can't do with switches what you can do with routers, because (normal layer 2) switches do not know about IP...
Cisco offers a layer2 traceroute utility, but this is limited to the cisco ecosystem and only works with cisco hardware.
So, I fear the answer is, that it is not possible in general.
I have created a bandwidth meter application to measure total Internet traffic. I need to test the application with relatively high data transfer rates, such as 4 Mbps. I have a slow Internet connection, so I need a simulator to test my application to see the behavior with high throughput rates.
As an option, you can run some HTTP server in one virtual machine with NAT'ed network adapter and test your bandwidth meter against it from the host system or a similar VM.
There are commercial packet generators that do this, and also a few freely available ones like PackETH and Bit-Twist.
There are also other creative solutions. For example, do the packets need to be IP packets for your purpose? If not, you could always get a "dumb" switch or hub (no spanning-tree or other loop protection) and plug a crossover cable into it. (or a straight-through Ethernet cable would work if the switch supports Auto-MDIX) The idea would be that with a loop in your network, the hub/switch will flood the network to 100% for you since it will continually re-forward the same packets.
If you try this, be sure yours is the only computer on the network, since this technique will effectively render it useless. ;-)
You could always send some IP broadcast packets to "seed" the loop. Otherwise, the first thing I think you'd likely see is broadcast ARP packets, which won't help if you're measuring layer 3 traffic only.
Lastly, (and especially if this sounds like too much trouble) I recommend you read up on dependency injection and refactor your code so you can test it without the need for a high-speed interface. Of course, you'll still need to test your code in a real high-speed environment, but doing this will give you much more confidence in your code.
We are trying to connect two Hyper-V VMs through a serial port. Hyper-V exposes the serial port as a named pipe to the host system, and implements the server end of the named pipe. Consequentially, to connect them, we need to write a named-pipe client which connects to both VMs, and copies the data back and forth.
We have written such an application. Unfortunately, this application loses data.
If we connect two hyperterms, and have them exchange data, the transmission sometimes succeeds, but in many cases, the receiving end reports errors, or the transmission just deadlocks. Likewise, if we use the link to run a kernel debugger, it also seems to hang often.
What could be the cause of the data loss? What precautions must be taken when connecting named pipes in such a manner?
Edit: We have worked around the problem, using kdsrv.exe. The COM port of the debuggee continues to be exposed through a named pipe, however, the debugger end talks to kdserv via TCP.
The data loss is not due to the named pipes. It is infact the COM ports (emulated and physical) that may lose data since they operate with a small buffer in the UART.
The named pipe receives all the data that is written to the COM port. Your program reads data from the named pipe and writes it to another named pipe. This is where data loss can originate if you write too fast the receiveing COM port's UART can overflow leading to data loss.
You may need to add some delay to avoid exceeding the baud rate expected by the receiving side.
In addition, you are missing ResetEvent() calls in your program.
For your KD issues, you may need to add resets=0 to the connection string.
I did not try to connect VM via Serial but I connected VM and Host via usb (through network)
and it works.
If it is required for your software to establish serial connection try to test via serial emulators with work through tcp\ip.
I think John's suggestion is correct - if u are using a slow CPU to emulate TWO VM, then the guest OS's drivers for serial port is highly drifted away from the high speed version. So John's suggestion is to set the input/output side of the serial link to the slowest possible speed. Ie, you cannot use high baud rate for the inter-VM serial communication. Instead u have to use the slowest possible speed, and so that the VM guest driver will take that cue and use the slower version of the driver. But your physical machine must have sufficient CPU speed to run two VM concurrently, to avoid the "emulation drift" of the the serial driver.
Well, just my guess, but there is a VirtualBox version of your problem, seemingly no issues running it:
http://bodocsi.net/2011/02/how-setup-serial-port-link-in-virtualbox-between-two-guest-virtual-machine-in-linux/
But the following bug ticket for VirtualBox does describe many similarities to your problem:
https://www.virtualbox.org/ticket/1548
And reading the end seemingly indicate the solution has to do with VirtualBox's internal source code. Perhaps it is Hyper-V's problem?
I'm doing a project where I must write a network library for a device connected to a Windows machine. The complication comes in that I may only communicate with the device using ethernet frames. So there is no TCP/UDP/IP at all. I don't think the bind/listen/accept approach can be applied here, but maybe I am wrong. Also, there is no routing or switching involved.
I have a few questions. How do I use a socket to communicate with this device? Does winsock have any support for just frames? I haven't been able to find many resources on this. Does anyone have any ideas about how I should proceed?
Is using sockets even a good idea or can I just send out the information with the appropriate headers?
Use WinPCap, it has an an API to send and listen to raw data.
You can build your communicate layer with it.
Give the WinAoE code a look-see - it says it lets Windows talk to ATA over Ethernet devices which means it has to communicate without any of the upper layers of the network stack.
Edited:
As near as I can tell, if you want to send raw ethernet frames, you want NdisSend and friends.
As well as winpcap and NDIS you could also look at raw sockets which are a standard part of the Windows API and don't require you to write driver code http://msdn.microsoft.com/en-us/library/ms740548(v=vs.85).aspx.