I've seen conflicting data for exactly which flags are set in an xmas packet. nmap and other packet tools use PUF flags. However, I also see documentation that states all flags are set; and that the PUF flags are used for certain implementations but, by definition, an xmas has all flags set.
Even http://en.wikipedia.org/wiki/Christmas_tree_packet is a bit confusing in that it alludes to all flags set but then goes on to talk about what happens when the SYN flag is omitted which would not be all flags:
"Some stateless firewalls only check
against security policy those packets
which have the SYN flag set (that is,
packets that initiate connection
according to the standards). Since
Christmas tree scan packets do not
have the SYN flag turned on, they can
pass through these simple systems and
reach the target host."
I know the distinction is a bit meaningless because either way you're essentially sending junk combinations of bits that wouldn't normally be used in a TCP/IP stream. However, I'd like to know whether an xmas packet has all bits or just the PUF bits (or either, etc.)
'When I use a word,' Humpty Dumpty
said, in rather a scornful tone, 'it
means just what I choose it to mean —
neither more nor less.'
Such is the case with "xmas packets". There is no authoritative definition - it means whatever the person using the term chooses it to mean.
Related
We are parsing DHCP packets in TC egress BPF program, In our case, the packet after the UDP header was not present in between skb->data and skb->data_end. On further investigation we found that it lies in non-linear portion. and we have bpf_skb_pull_data(skb,len) to direct access non-linear data.
Few questions based on above:
After call to bpf_skb_pull_data(skb, skb->len); the value of skb->data and skb->data_end pointers changed. Can there be any implication down the stack with change in value of skb->data pointer. Also is this helper function analogous to skb_pull which changes the skb->data pointer and is typically moved when the packet goes up the stack as a result of packet being parsed on that layer? Do we have something similar to skb_linearize() in BPF or any other way to parse non-linear portion?
For our case, packet after the UDP header was in non-linear portion, can it happen that packet after IP header go in non-linear or packet after ethernet-header?
After call to bpf_skb_pull_data(skb, skb->len); the value of skb->data and skb->data_end pointers changed. Can there be any implication down the stack with change in value of skb->data pointer.
bpf_skb_pull_data ends up calling pskb_expand_head in the kernel, which clarifies the impact:
Expands (or creates identical copy, if #nhead and #ntail are zero) header of #skb. [...] All the pointers pointing into skb header may change and must be reloaded after call to this function.
It is therefore expected that the data and data_end pointers are updated. I can't think of any other implication if you are only consuming the kernel's API (and not making changes to the kernel itself).
Also is this helper function analogous to skb_pull which changes the skb->data pointer
Not really. skb_pull removes data from the start of the packet's memory buffer. bpf_skb_pull_data pulls in non-linear data when you want to perform a direct packet access with BPF.
Do we have something similar to skb_linearize() in BPF or any other way to parse non-linear portion?
As far as I know, the closest is bpf_skb_pull_data. If that helper doesn't address your use case for some reason, I would suggest asking on the BPF mailing list.
For our case, packet after the UDP header was in non-linear portion, can it happen that packet after IP header go in non-linear or packet after ethernet-header?
Yes for the IP payload; It's just a matter of how large your IP header is. It seems unlikely for the Ethernet header.
I am new to writing dissectors in Lua and I had two quick questions. I have a packet which has the TCP Options as MSS, TCP SACK, TimeStamps, NOP, Window Scale, Unknown. I am basically trying to dissect the unknown section in the TCP Options field. I am aware that I will have to use the chained dissector.
The first question is while using the chained dissector to parse the TCP Options, do I have to parse all the Options from the beginning. For Example will I need to parse MSS, TCP SACK, .... and then finally parse Unknown section or is there any direct way for me to jump to the Unknown section.
The second question I have is I have seen the code for many custom protocol dissectors and if I need to dissect a protocol which follows (for example)TCP, then I will have to include the following:
-- load the tcp.port table
tcp_table = DissectorTable.get("tcp.port")
-- register our protocol to handle tcp port
tcp_table:add(port,myproto_tcp_proto)
My question is, is there anyway for me to jump to the middle of the protocol. For example in my case I want to parse TCP Options. Can I directly call tcp.options and the parser will start dissecting from where the options will start?
The TCP option is "uint8_t type; uint8_t len; uint8_t* data" structure.
I usually give common used ones a name. For example getSack(), getMss().
For others, keep them in an array(maximum size like 20).
For your second question, you mean you don't care about TCP header, right? If so, just move your pointer 20 bytes further to get access the TCP options.
Here is a question I've been trying to solve since quite some time ago. This does not attain a particular languaje, although it's not really beneficial for some that have a VM that specifies endianess. I know, like the 99.9999% of people that use sockets to send data using TCP/IP, that the protocol specifies a endianess for the transmission elements, like destination address, port and such. The thing I don't know is if it requires the payload to be in a specific format to prevent incompatibilities.
For example, let's say I develop a protocol that is not a presentation layer, and that I, due to the inmense dominance that little endian devices have nowadays, decide to make it little endian (for example the positions of the players and such are transmitted in little endian order). For example a network module for a game engine, where latencies matter and byte conversion would cost a noticeable amount of time. Of course the address, port and all of that data that is protocol related would be specified in big endian as is mandatory, I'm talking about the payload, and only that.
Would that protocol work out of the box (translating the contents as necessary, of course, once the the transmission is received) on a big endian machine? Or would the checksums of the IP protocol or something of the kind get computed wrong since the data is in a different order, and the programmer does not have control of them if raw_sockets aren't used?
Since the whole explanation can be misleading, feel free to ask for clarifications.
Thank you very much.
The thing I don't know is if it requires the payload to be in a specific format to prevent incompatibilities.
It doesn't, and it doesn't have a way of telling. To TCP it's just a byte-stream. It is up to the application protocol to decide endian-ness, and it is up to the implementors at each end to implement it correctly. There is a convention to use big-endian, but there's no compulsion.
Application-layer protocols dictate their own endianness. However, by convention, multi-byte integer values should be sent in network-byte order (big endian) for consistency across platforms, such as by using platform-provided hton...() (host-to-network) and ntoh...() (network-to-host) function implementations in your code. On little-endian systems, they will do the necessary byte swapping. On big endian systems, they are no-ops. The functions provide an abtraction layer so code does not have to worry about that.
i need to create some statistics from packets in my network interface, but i'm concerned only for my tcp sessions. i thought i could do that with nfdump and nfsen. because i'm new to this stuff, i dont really get what nfdump defines as 'flow'.
furthermore, can i get statistics with these tools only for the tcp protocol sessions? i mean, for example, that i need to have some average duration of all the connections(srcip-srcport, dstip-dstport pairs) in a server of mine. And for this reason i need the time between the 3WH and the closing of each connection (either with [fin/ack,ack] or with [rst]). Is that possible with nfdump-nfsen?
Short answer here is no: you don't have anything in your list of software that generates netflow information. It's not going to work. Netflow collectors do not work as hard as you might like to maintain your idea of a connection - a flow is just a collection of related packets that happen during part of the collection cycle. For a long-lived session, you can expect to see a few flows.
For your application, you will do better to capture syn-ack and fin packets with tcpdump and analyse the timing of these with your favourite text processing tool.
Also, on the left side of your keyboard, you may find a key with an arrow that allows you to type capital letters.
When packet loss occurs while in slow start, does the reno/newreno algorithms notice possible dupacks, or is it purely slowstart -> rto?
Thus, if sending two packets (in start of slow start), and first one goes missing, does slow start do anything else but rto?
It is confusing, since rfc states that 'in practice they (slow start & congestion avoidance) are implemented together'. And linux source is a bit thick read and only one implementation.
When packet loss occurs while in slow
start, does the reno/newreno
algorithms notice possible dupacks, or
is it purely slowstart -> rto?
I would say "yes", duplicate ACKs will be detected and acted upon. See RFC 2001, Section 2.3.
Thus, if sending two packets (in start
of slow start), and first one goes
missing, does slow start do anything
else but rto?
This particular example would lead to a "simple RTO". During the beginning of slow start when only two packets can be sent there will at most be one duplicate ACK (triggered by the second packet arriving). There might even be none if both packets are (would be) acknowledged together. But one duplicate ACK does not trigger fast retransmit. So TCP will wait for the retransmission timer to expire.
It is confusing, since rfc states that
'in practice they (slow start &
congestion avoidance) are implemented
together'. And linux source is a bit
thick read and only one
implementation.
I agree that the linux source is a thick read. But it's definitive and if you really need to know might be the only option :) Unless you find someone who read (or wrote) it; which I have not.