Problems with FlowData in Data Filter

hi,all

readBytes: An NSData object containing the data to filter. For non-UDP/TCP flows, since the data may optionally include the IP header, readBytes includes a 4-byte NEFilterDataAttribute field preceding the user data. Your handler must examine the NEFilterDataAttribute field and handle the data accordingly.

the param above in method handleInboundDataFromFlow:readBytesStartOffset:readBytes:

i assume it contains a 4-byte NEFilterDataAttribute field preceding the user data all the time,

is it normal that i get a NEFilterDataAttribute: 1099782776645(and some other very big number)


const NEFilterDataAttribute* dataAttr = readBytes.bytes;

    NSLog(@"NEFilterDataAttribute: %ld",*dataAttr);

and after the initial 4 bytes, if the offset param is 0, can i assume that UDP/TCP or IP packet headers can be extracted from the data?

Accepted Reply

There’s a bit of type mixup here. NEFilterDataAttribute is defined like so:

typedef NS_ENUM(NSInteger, NEFilterDataAttribute) { … } …

Note the base type of NSInteger. That’s a pointer-sized integer, which means it’s 8 bytes. So, your code would read 4 bytes of attributes and the next 4 bytes, which is the IP header.

To read just the data attributes, assuming they’re present, you’d need code like this:

const uint32_t * dataAttrPtr = readBytes.bytes;
uint32_t dataAttr = *dataAttrPtr;

is it normal that i get a NEFilterDataAttribute: 1099782776645(and some other very big number)

No. Consider this:

(lldb) p/x 1099782776645
(long) 0x0000010010296745

Note how the last byte is 0x45, that is, which is what you typically find in the first byte of an IP header.

What type of flow did you get this value from?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • oh, I SEE.

    What type of flow did you get this value from?

    i didn't know to check the protocol type with NEFilterSocketFlow at that time...

    and now I try to decode TCP Header, the result looks better by including the initial 4 bytes. so when Data have a protocol type with TCP/UDP, it does not have a 4-byte attr field?

  • it seems that in the case of tcp, readBytes only contains the data of upper layer, i have retrieve http packet when I access a website. and one flow corresponds to one TCP connection. so in the whole process of accessing a website the request i send and the response i get all belongs to that flow with direction attribute set to outbound(i just got confused about i didn't get any inbound flow before). hope i'm not making any mistake this time?

Add a Comment

Replies

There’s a bit of type mixup here. NEFilterDataAttribute is defined like so:

typedef NS_ENUM(NSInteger, NEFilterDataAttribute) { … } …

Note the base type of NSInteger. That’s a pointer-sized integer, which means it’s 8 bytes. So, your code would read 4 bytes of attributes and the next 4 bytes, which is the IP header.

To read just the data attributes, assuming they’re present, you’d need code like this:

const uint32_t * dataAttrPtr = readBytes.bytes;
uint32_t dataAttr = *dataAttrPtr;

is it normal that i get a NEFilterDataAttribute: 1099782776645(and some other very big number)

No. Consider this:

(lldb) p/x 1099782776645
(long) 0x0000010010296745

Note how the last byte is 0x45, that is, which is what you typically find in the first byte of an IP header.

What type of flow did you get this value from?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • oh, I SEE.

    What type of flow did you get this value from?

    i didn't know to check the protocol type with NEFilterSocketFlow at that time...

    and now I try to decode TCP Header, the result looks better by including the initial 4 bytes. so when Data have a protocol type with TCP/UDP, it does not have a 4-byte attr field?

  • it seems that in the case of tcp, readBytes only contains the data of upper layer, i have retrieve http packet when I access a website. and one flow corresponds to one TCP connection. so in the whole process of accessing a website the request i send and the response i get all belongs to that flow with direction attribute set to outbound(i just got confused about i didn't get any inbound flow before). hope i'm not making any mistake this time?

Add a Comment