Indeed, what we have is a result of your previous work helping Mitch. It is the same project that I am working on.
Since I inherited this project in the company without knowing all the details, I don't know specifically what was done to accomplish the PROMISC functionality.
The project seems to be linked with version 2.20.03.24 of the NDK. For my sake, do you know in what way the NDK has been updated?
Is the update manifested in the modified versions of nimu.c, nimu_eth.c, nimu_eth.h found in my project?
If you think modifications have been applied to the NDK project itself, I am happy to send you the source of the NDK I'm linking against.
Thanks
Corey
Corey,
Yes, there were most certainly changes made to the NDK and the driver as well, I believe.
I hunted around and found this forum post that has the "final answer" of all the back and forth exchanges to that it took to get everything into promiscous mode.
The post has some details about which files were updated, however I think it would be easiest just to zip up the *entire* NDK you have and post it to the forum. This would allow me to build against the exact same thing as you are. Would it be possible to do that? It may also be a good idea to do the same for the NSP you have.
Thanks,
Steve
Happy to send you my copy of the NDK and NSP.
I have had trouble posting files to the forums before. Do you have any hints for how to do this? zip format, etc?
A zip format should work ... however I'm wondering if there's some sort of file size limit for the forums.
An alternative would be to use a cloud file share service such as drop box. As long as you are not putting any proprietary code into the zip (it should just be NDK stuff, which is open sourced) then I don't see any issue with that.
Here's my copy of the packages:
http://dl.dropbox.com/u/47211568/ndk_2_20_03_24.zip
http://dl.dropbox.com/u/47211568/nsp_1_00_00_09.zip
Other possibly relevant modifications may be found in the code you received which I had sent to your co-worker.
Specifically, I think the version of ethdriver.c in my code will override the version of ethdriver.c contained in the above-linked NSP sources.
Is there a project file you could share?
So far I've taken the sources you gave Todd and put them into an existing NDK project.
It looks like I need the file "listlib.h". Maybe just sharing that would work.
Also, the preprocessor.tcf file requires the file "uppSample.tci".
I see in the PSP drivers there are two versions of this file. Do you know which one your application is using?
The files are in either "evmA" or "evmB" directories:
C:\Program Files\Texas Instruments\pspdrivers_01_30_01\packages\ti\pspiom\examples\evmOMAPL138\uppEvm\{evmA, evmB}\build
"C:/ti/ccsv5/tools/compiler/c6000/bin/cl6x" -mv6740 -g --include_path="C:/ti/ccsv5/tools/compiler/c6000/include" --include_path="C:/Documents and Settings/a0323418/workspace_forums/ndk_evm6748_bios5_client" --include_path="C:/Program Files/Texas Instruments/ndk_2_20_03_24/packages/ti/ndk/inc" --include_path="C:/Program Files/Texas Instruments/ndk_2_20_03_24/packages/ti/ndk/inc/tools" --include_path="C:/Documents and Settings/a0323418/workspace_forums/ndk_evm6748_bios5_client/Debug" --include_path="C:/ti/bios_5_41_11_38/packages/ti/bios/include" --include_path="C:/ti/bios_5_41_11_38/packages/ti/rtdx/include/c6000" --diag_warning=225 --preproc_with_compile --preproc_dependency="preprocessor.pp" "../preprocessor.c""../preprocessor.c", line 11: fatal error: could not open source file "listlib.h"1 fatal error detected in the compilation of "../preprocessor.c".Compilation terminated.
Steve,
listlib.h: http://dl.dropbox.com/u/47211568/listlib.h
Note: This is identical to the one found at: packages\ti\ndk\inc\stack\inc\listlib.h within ndk version I previously posted (http://dl.dropbox.com/u/47211568/ndk_2_20_03_24.zip). You probably just need to add "packages\ti\ndk\inc\stack\inc" to your project's included directories.
uppSample.tci: http://dl.dropbox.com/u/47211568/uppSample.tci
Hi Corey,
Thanks for posting those.
I'm now hitting the following:
"../preprocessor.c", line 39: fatal error: could not open source file "gpiofunctions.h"
I'm not sure where this file is coming from. I thought it would be part of the PSP drivers, but I'm not finding it in there. Do you know where I could find this file?
Also, it may be easier if you zip up and attach your entire project. This would allow me to see all of the dependencies you are using so I would be able to find things like this on my own (assuming they are part of a TI product).
Thank you for your persistence.
I agree, it would be easier to send you the whole project. As it may include proprietary and sensitive content, I need a way to send it to you directly, rather than posting it publicly.
Maybe I can send it to your email?
I've had some set up issues but finally have an Ubuntu machine where I'm able to run the eth-send application you shared.
However, I'm having trouble reproducing the issue still, but maybe you have an idea. Here's where I'm at so far ...
I'm able to build your project that you sent.
I've got my PC and OMAPL138 hooked up to a hub which in turn is going through a switch that connects to the LAN. The PC is used for CCS and also running Wireshark so that I can see packets being sent to the DSP. The Ubuntu box is on the LAN.
I am able to ping the DSP (146.252.161.26) from the Ubuntu box (146.252.161.36) and I see those packets being captured in Wireshark.
However, when I run the eth-send app, I don't see any packets showing up in Wireshark.
I'd like to avoid fully digging into debugging the eth-send program as I'm short on time and you probably know this program well ... How does the app find the DSP? Do I need to add the DSP's IP address <--> MAC Address mapping into the ARP table of the Ubuntu box? Or do I need a different network set up?
From the Ubuntu box:
a0323418@dta0868361-ubuntu1:~/ethtest$ ping 146.252.161.26PING 146.252.161.26 (146.252.161.26) 56(84) bytes of data.64 bytes from 146.252.161.26: icmp_seq=1 ttl=255 time=1.38 ms64 bytes from 146.252.161.26: icmp_seq=2 ttl=255 time=0.380 ms64 bytes from 146.252.161.26: icmp_seq=3 ttl=255 time=0.378 ms^C--- 146.252.161.26 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2000msrtt min/avg/max/mdev = 0.378/0.714/1.385/0.474 msa0323418@dta0868361-ubuntu1:~/ethtest$ sudo ./eth-send eth0 5sent 5 framesa0323418@dta0868361-ubuntu1:~/ethtest$
And I only see the pings ...
The configuration is a point-to-point link, so connect the DSP to the Linux box directly a cross-over cable (it's possible that a regular patch cable will work, too).
In the "eth-send" call make sure you reference the ethernet port through which they are connected. If it's eth0, then "eth0". If eth1, then "eth1".
"eth-send" may need to be run as root to allow promiscuous mode.
Let me know how it goes.
Over the past few weeks I've been spending a few hours here and there trying to get a good set up in order to reproduce and then debug this problem, but I have not been able to suceed so far.
I first tried to use a physical Ubuntu machine which we already have had set up. However, TI has restricted the Linux box to prevent users like me to set a static IP address on it.
So, I next tried a different route. I've downloaded Ubuntu and got it running on my PC as a virtual machine. I'm able to ping the board from within the virtual machine with the default DHCP assigned IP address. However, once I try to configure the virtual Ubuntu image to have a static IP address, I can no longer reach the board with ping. (maybe I need to set my windows machine to use a static IP as well...)
Before I spent too much time on trying to debug this set up, I wanted to know if you believe it is even valid? Will I be able to reproduce this using a virtual machine?
My physical network set up is as follows. I'm using a hub, which I don't think should be an issue here but I'll mention it just in case:
It seems to me that it should be able to work with a virtual machine.
Remember, this has nothing to do with IP. The packets we are sending are not IP packets; they are raw MAC-layer packets.
Things to consider:
1. The hub could be a problem; I recommended an Ethernet cable running directly between the PC (running Ubuntu as VM) and the c6748. 2. If the PC grants the Ubuntu VM the permissions to send Raw packets (and run in promiscuous mode) it should work. The test program must be run as root. 3. After taking care of (1) and (2) we should be able to test whether the packets are being sent from the Ubuntu VM. 1. If Wireshark reports outgoing packets, try running it on the PC and see if the outgoing packets show up. 2. Unplug the Ethernet cable from the c6748 and plug it into another PC running Wireshark and look for the incoming packets. I know for sure (as I have done this before) that (if Wireshark is configured correctly) Wireshark does show incoming packets sent by my test problem. I don't remember about the configuration of Wireshark but make sure it will show packets with the wrong destination MAC address (aka "Promiscuous mode")
Do you have a Windows side version of the test apps (eth-send, etc.)?
I went and bought a crossover cable to eliminate the hub from the equation.
However, I'm still not able to see anything coming through on Wireshark on the set up mentioned above. I run the command (sudo ./eth-send eth0 5) and it says that it sends the 5 packets. But, I don't see anything show up in Wireshark. I also ensured that the network settings within VirtualBox are set to "allow all" for promiscuous mode, as well as in the Wireshark settings. Is there something else that I'm missing??
I've also tried booting Ubuntu from a USB drive to eliminate the virtual machine + Windows setup. I'm able to successfully boot; however I'm not able to mount a USB stick that has a Wireshark bundle for Linux on it (actually not even sure that Wireshark will work on Ubuntu ... and I'm not sure how I will be able to know that the packets are going through without Wireshark).
I can keep trying with this approach, but it's taking a lot of time here, and I want to use the time I have allocated for your issue as wisely as possible. So, I'm hoping there is a way to reproduce this issue from my Windows machine as it would eliminate all of this set up overhead ...
I appreciate all the effort and time trying to get this to work. Honestly, I never had this much difficulty trying to do this. On the other hand, I have had access to Linux machines as well as root permissions.
I think the Ubuntu thumb drive approach is better, since then you don't have any questions about Virtual Machines and network interface permissions. Ideally you would be given a Linux box on which you could run programs as "root", since this is needed for raw socket communication and promiscuous mode, but if you can run as "root" with a Ubuntu thumb drive then I guess that's the way to go.
Instead of worrying about putting Wireshark on the Linux box, see if the sent packets can be seen on the receiving end. To do this, instead of connecting the cable to the c6748, connect it to a Windows machine running Wireshark; Wireshark should be able to see the incoming packets.
Also before running "eth-send", if the Ubuntu machine has multiple ethernet ports, make sure you are sending through the correct network device.
If there is only one the correct command is probably: sudo ./eth-send eth0 5
But, if there are two ethernet ports, the correct command may be: sudo ./eth-send eth1 5
Also, what version of Ubuntu are you running?
Let me know what happens...