RAW Sockets

Oliver Bull

I'm in the process of trying to use RAW IP sockets (not RAW Ethernet) and have come across an issue with the way setsockopt() is handled in the NDK (current version is 2.20.04.26)

Basically the SockSet() handler in sock.c ORs SOCK_IP_HDRINCL into ps->IpFlags if IP_HDRINCL is set.

Now, in SockCreatePacket() in sockint.c, ps->IpFlags is checked (ANDed) with IP_HDRINCL.

Not only is this not great practice, but the #defines are actually 2 and 1 for IP_HDRINCL and SOCK_IP_HDRINCL respectively. Therefore this never (and can) never works.

Can someone please take a look and make sure I've not missed anything and if this is a known issue?

For now I am going to progress with flipping the private SOCK_xxx defines around such that they match the public IP_xxx defines....... but this is not really a great solution.

over 13 years ago

0 Steven Connell over 13 years ago

TI__Mastermind 45025 points

Oliver,

Indeed this looks like a bug to me, thanks for flagging this.

I've filed a bug for this issue to ensure it gets fixed:

SDOCM00086429 #define mismatch for raw IP packet support in NDK

For a workaround, you could change the values of IP_HDRINCL and SOCK_IP_HDRINCL so that they are equal, but this would require a rebuild of the NDK core libraries.

Steve

0 Oliver Bull over 13 years ago in reply to Steven Connell

Prodigy 40 points

Thanks for the confirmation.

I have rebuilt the NDK core libraries, which appears to be successful. (following the instructions here: http://processors.wiki.ti.com/index.php/Rebuilding_the_NDK_Core)

However, when I download an application with this NDK linked in, CCS freezes at the point of boot execution (the bit before the automatic breakpoint is hit at main().

It's not clear to me if this is a CCS thing or my NDK is bad. If I build the NDK without modification to sockif.h, the same thing happens.

If I run the same app with the delivered libraries, it boots OK.

I am building the NDK with :

ccsv5 (5.0.1)

XDC Tools 3.22.1.21

SYS/BIOS 6.32.4.49

These are later versions than the release notes for NDK 2.20.03.24, but I would expect more recent dependencies to be OK (as stated in the release notes).

A binary diff of the libraries to the pre-built ones show masses of changes, so clearly it's being built very differently.

I am running on the TMDXEVM6618LXE, and therefore through the XDS560.

Can you recommend the best steps to try to get this running OK?

Thanks in advance.

0 Steven Connell over 13 years ago in reply to Oliver Bull

TI__Mastermind 45025 points

Oliver,

We need to figure out what's causing it to not work. It is possible that one or more of the new dependencies are causing the problem.

But first, have you tried running the standard NDK examples? (I'm assuming you're using the MCSDK, right?). If not, can you try both the helloWorld and client example that are included with your MCSDK?

For example, on my machine they are here:

C:\Program Files\Texas Instruments\mcsdk_2_01_00_00\examples\ndk\{helloWorld, client}

If you can verify if:

A. the examples work when built against the original NDK

B. changing the example to build against your re-built NDK causes them to break

I think it would be best to try part B. above *without* any modification to the NDK code.

Steve

0 Oliver Bull over 13 years ago in reply to Steven Connell

Prodigy 40 points

Steve,

Thanks for the further help. I have now tried the MCSDK examples of helloWorld and client. (I was actually using a modified version of client for my own raw socket testing)

helloWorld works with the formal NDK and my own built NDK.

client works only with the formal NDK and still causes CCS to hang up with my own built NDK.

Yes, I am using XDC tools 3.22.1.21, MCSDK 2.0.2.14, TMDXEVM6670 PDK 1.0.0.14 and SYS BIOS 6.32.4.49.

While I wait for your next suggestion, I'll try pulling bit out of client to see if I can narrow down on what part of the init sequence (remember this is even before it gets to main()) is triggering the issue.

Thanks,

Oliver.

Processors

Processors forum

RAW Sockets