Ethernet experts,
I have basic question.
I'm now studying VLAN tag for Ethernet.
One field of the VLAN tag is PCP(Priority Code Point), which is 3 bit field and indicates the frame priority.
How about the priority between frame with VLAN tag and frame without VLAN tag ?
I keep investigating and try to find out the description on IEEE standard (IEEE802.1Q and IEEE802.1D), however can not find out the definition yet.
Any input is highly appreciated.
John
Frames without a 802.1Q tag don't have an inherent CoS priority. If you don't assign a priority on the receiving end (by VLAN, protocol, IP, port, ...) they are handled with the default priority.
However, IP's DSCP priority has largely superseded CoS. The diffserve priority field sits in the IP header, not in the frame tag. Depending on your network equipment, DSCP values need to be mapped to CoS or vice versa for both of them to work.
Related
I want to know in RPL networks, after a node sends one packet to another node (for example RPL-Collect/udp-sender), how to know that intended node will forward this packet or not? I think overhearing neighbors transmission is needed, but is the another simple way to implemented this scenario in Contiki/Cooja?
To overhear packets in addition to normal operation you need to do several things:
Ensure that the radio is turned on and in the right channel. If you're using always-on CSMA or ContikiMAC you don't need to do anything special. Same for TSCH minimal schedule. Otherwise for TSCH you need to schedule a Rx cell with the right channel offset and in the right timeslot.
Somehow hack into the MAC layer to print or account packets not addressed to you - normally the MAC layer silently drops such packets.
Ensure hardware frame filtering is turned off (the radio is in promiscious mode).
Example:
radio_value_t radio_rx_mode;
/* Entering promiscuous mode so that the radio accepts all frames */
NETSTACK_RADIO.get_value(RADIO_PARAM_RX_MODE, &radio_rx_mode);
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, radio_rx_mode & (~RADIO_RX_MODE_ADDRESS_FILTER));
If you just need to overhear packets and don't need the normal operation things and simpler. You can use SenSniff then.
I've found what code parses IP (v4) packets in the kernel source tree. This function, ip_rcv, can to a high degree of certainty detect whether a packet is correct or not, as is outlined in one of the comments:
Length at least the size of an ip header
Version of 4
Checksums correctly. [Speed optimisation for later, skip loopback checksums]
Doesn't have a bogus length
Malformed packets are simply dropped. This function seems to get a bunch of bytes that should resemble an IP packet, but what if some malicious actor would sneak an extra byte on the line? If not handled correctly, all the chunks of bytes that ip_rcv receives from now on will start 1 byte off and no correct IP packet can be reconstructed anymore. I assume the kernel does something smarter than to try all different byte offsets at which to start parsing an IP packet. What exactly, I'm unable to find. Could anyone shed some light on this?
I haven't taken the time to look at the kernel code but most protocol stacks are going to work by parsing data immediately following the previous stack location and not by searching for data.
In the case of Ethernet, an Ethernet frame header is typically 14 bytes in size. It can vary but the header itself indicates the different length in the etherType field when necessary. In this example, the NIC (Network Interface Card) will receive an Ethernet frame. If the frame is destined for this NIC then the data passed from the NIC driver to the IP stack will be an Ethernet frame containing this 14-byte header followed immediately by the IP header (first nibble will be 4 if it is a version 4 IP header for instance).
Again, I didn't look at the network stack code but there are two common cases here:
1) The IP stack is told this is an Ethernet frame and only needs to parse the Ethernet frame header for its length and the very next byte must be an IP header or the data is deemed not an IP frame.
2) The IP stack is given a pointer to the beginning of the data immediately following the Ethernet frame header and the IP stack then starts parsing at that location.
I have set up an experiment to measure Wireless communication parameters using two laptops. I am injecting custom packets into the network on a monitor interface using one laptop programmed as a transmitter(Macbook Pro using Broadcom BCM 4331 interface card) and another laptop ( Dell Latitude E6410 using the Intel Corporation Centrino Ultimate-N 6300 interface card) programmed as a receiver sniffs the network for the custom injected packets and reports parameters such as Received signal strength, propagation delay etc... The transmission is working fine and i am able to get the injected packets on the receiving side.
However , When i use Wireshark to analyze the incoming packets using the monitor interface created using airmon-ng, the radio tap header seems to be malformed. This is the same for all packets .
Also why is the Noise parameter now shown in the radio tap details?
Could anyone help me out with this?
The header might well be malformed, due to, for example, a driver bug. (I.e., a bug in the Linux driver for the Centrino adapter on your laptop.)
Unfortunately, Wireshark didn't put in any indication of what was malformed, so it's hard to diagnose this problem.
I just checked into the Wireshark trunk a change to add expert info for malformed radiotap headers; if you could try building the current SVN trunk head and see what it reports, that might indicate what's wrong with the header.
What's wrong is probably that the length field in the radiotap header is wrong.
If when you said "Also why is the Noise parameter now shown in the radio tap details?" you meant "Also why is the Noise parameter not shown in the radio tap details?", the length field being too short would explain that - the presence bitmap says that the noise parameter is present, but the header field specifies a length not large enough to include the noise parameter, so when Wireshark tries to fetch that field, it discovers that it's run past the end of the radiotap header, and reports a problem.
In addition, that would also explain why the 802.2 LLC header on several of those frames look bogus - if Wiretap skips past the length specified in the radiotap header to find the 802.11 header, and that puts it in the middle of, for example, the Noise parameter, and it tries to dissect that as if it were an 802.11 header, and tries to dissect what's after the 802.11 header as an 802.2 header, both of them could be bogus.
POLICED means that the speed of ingress packet will be limited and the exceeding packets will be dropped.
I saw a comment "skb is shot by police" in include/linux/netdevice.h.
It's of course alike, but is there any story behind this name?
Yes -
http://lxr.linux.no/#linux+v3.2.9/net/sched/Kconfig
menuconfig NET_SCHED
bool "QoS and/or fair queueing"
select NET_SCH_FIFO
---help---
When the kernel has several packets to send out over a network
device, it has to decide which ones to send first, which ones to
delay, and which ones to drop. This is the job of the queueing
disciplines, several different algorithms for how to do this
"fairly" have been proposed.
...
config NET_ACT_POLICE
tristate "Traffic Policing"
depends on NET_CLS_ACT
---help---
Say Y here if you want to do traffic policing, i.e. strict
bandwidth limiting. This action replaces the existing policing
module.
To compile this code as a module, choose M here: the
module will be called act_police.
Is 74DC::02BA a valid IPv6 address?
I am trying to break it down, but the various shortcuts are confusing me.
Valid address, yes. See this question. Also, this validator breaks it down nicely.
Correct address, probably not. See RFC 4291, section 2.4, where this address is defined as a Global Unicast address. (the first bits are 0111 0100, which falls under "everything else" in the table) Then see the IPv6 address assignments. You'll notice this address range has not been assigned for use.
Normally you wouldn't see an address written like this, since it contains extra information. (the leading 0 in the second group of digits) So you would probably see it written like 74dc::2ba. (The IETF makes recommendations about how to print IPv6 addresses in RFC 5952.)
If you want to know the rules for IPv6 address shortening, they are specified in RFC 4291, section 2.2.
Here's what I believe to be the best online IPv6 validator (and not just because I wrote it). It will show you the various address forms and show you how the different representations relate to each other (try hovering over each address group).
The "::" means there's all 0s in between the colons. The address expands to 74dc:0000:0000:0000:0000:0000:0000:02ba
IPv6 Address Validator