I know Ethernet has a EthernetType bit and that is 2 byte which ethernet protocol can we find. But I am looking for this question: I have two devices and they communicate between X ethernet protocol. I said to that talk with Profinet ethernet protocol. But how can i proof that type by officially unlike the first thing I said.Is there a software that does this ?
The EtherType field identifies the payload protocol, not the Ethernet protocol (as there's only a single Ethernet data link layer). The EtherType enables the system's interface handler to pass those frames to the according network stack.
E.g. IPv4 uses an EtherType of 0x0800, PROFINET uses 0x8892. So, frames with those EtherType values are passed to the appropriate, registered handler. When a frame with an unknown (unregistered) EtherType is received the frame is simply ignored.
Related
I am writing a Lua script to capture profisafe packets on wireshark.It is above the profinet layer in the stack.The wireshark dissect the profinet packets but does not dissect the profisafe.
For other protocols built on tcp or udp protocol one can do something like
local tcp_port = Dissector.get("tcp.port")
tcp_port:add(1234,foo_protocol)
to capture the packets that arises and received by the port 1234.
But profisafe is built on profinet and does not contain tcp or udp as the underlying layer.How to capture the packets in this case? I tried giving ethernet frame address in the place of port name but it did not work.
Use the menu Edit, Preferences, Protocols and search for PNIO:
PNIO options
Then select the checkbox "Enable detailed PROFIsafe dissection" and define a directory, where the GSDML file of the PROFIsafe device is located.
Read a lot of specifications and still can't get a simple thing.
All UDS requests encapsulated in ISO-TP packets, which are encapsulated in simple CAN frames, so ECU constantly receives a stream of frames from CAN bus.
How does ECU decide that this CAN frame is a part of any high-level protocol?
For example, I've sent Security request to ECU, CAN frame data will look like this
02 27 01
How does ECU determine that this is not just a chunk of data but a part of the protocol?
I wasn't able to find any relation to ISO/OSI stack when high-level protocols "talk to each other" using headers, so we know how to decode data packets.
The CAN message IDs that are used for specific protocols are defined per system.
In most cases the OBD-II will be sent over CAN ID 7DFh for the query and higher IDs for responses from different modules, but even that might be different on specific car models.
One way of figuring out the CAN IDs that are used for UDS-based communication is to send simple tester-present (SID 3Eh) messages and watching for CAN IDs which seems to have an appropriate response.
UDS via CAN is specified in the DoCAN ISO-15765-2 part and describe the network and transport layer for a functional (broadcast) and physical (p2p) communication between ECUs or better control functions.
Normal CAN id's don't implement any network functionalities like a addressing. For that purpose the SAE J1939 network layer is used. In a J1939 network each CAN client has a address and each functionality a parameter group (PGN). All of this is encoded in a 29bit CAN ID. For example the CAN ID 0x18EF8081. This will transport a message from the CAN client 0x81 to 0x80 via the PGN 0xEF, 0x18 is the priority.
In UDS over CAN the PGNs 0xDA (physical) and 0xDB (functional) are used for all communications. With that information's you can implement a CAN ID filter which match only the PGN part of the CAN ID.
In Erlang, it is very simple to send UDP packet, that is to use gen_udp:open() to create a socket, then use gen_udp:send() to send out the data.
However, by default, the Linux TCP/IP stack will set the don't fragment (DF)flag in IP header if the size of IP packet doesn't exceed the MTU size. If the size exceeds the MTU size, the UDP packet will be fragmented.
Is there some way to not set DF flag for UDP packet only?
I know in C language, the following code could be used to clear the DF flag. But i couldn't find a way in Erlang.
int optval=0;
if(-1 == setsockopt(sockfd,IPPROTO_IP,IP_MTU_DISCOVER,&optval,sizeof(optval))) {
printf("Error: setsockopt %d\n",errno);
exit(1);
}
Thanks
i found the solution after i posted this question :-(...:-)...
The solution is to set socket raw option by using inet:setopts() like what is done in C language, but the difference is that you need to know the definition of IPPROTO_IP and IP_MTU_DISCOVER.
The value of IPPROTO_IP is 0, defined in netinet/in.h
The value of IP_MTU_DISCOVER is 10, defined in linux/in.h
Below is example.
inet:setopts(Socket,[{raw,0,10,<<0:32/native>>}]).
I have tested it using small program, it is working.
You can find detail help for inet:setopts on erlang man page: http://www.erlang.org/doc/man/inet.html
Thanks.
How can I handle buffer overflow in ndis driver. Can anybody tell some buffer overflow scenarios or some use cases of buffer overflow conditions.
For NDIS miniport drivers
If you receive a packet that is larger than the MTU, discard it. Do not indicate the packet up to NDIS (i.e., do not pass the packet to NdisMIndicateReceiveNetBufferLists). If possible, increment the ifInErrors statistical counter.
The above rule is not affected by the NDIS_PACKET_TYPE_PROMISCUOUS flag; do not indicate excessively-large packets even when in promiscuous mode. However, you should indicate excessively-small (aka "runt") packets when in promiscuous mode, if your hardware permits it.
If you are asked to transmit a packet that is larger than the MTU, do not attempt to transmit it. Assign NET_BUFFER_LIST::Status = NDIS_STATUS_INVALID_LENGTH and return the NBL back to NDIS with NdisMSendNetBufferListsComplete. (I wouldn't expect you to ever see such a packet; it would be a bug for NDIS to attempt to send you such a packet.)
For NDIS protocol drivers
If you receive a packet that is larger than the MTU, you are free to discard it.
Never attempt to send a packet that is larger than the MTU.
For NDIS filter drivers
If a filter receives a packet that is larger than the MTU (FilterReceiveNetBufferLists), the filter may immediately discard the packet (NdisFReturnNetBufferLists if the receive indication is not made with NDIS_RECEIVE_FLAGS_RESOURCES, or just returning immediately if the resources flag is set).
If a filter is asked to send a packet that is larger than the MTU (FilterSendNetBufferLists), the filter may assign NET_BUFFER_LIST::Status = NDIS_STATUS_INVALID_LENGTH and return the packet immediately (NdisFSendNetBufferListsComplete).
Filters are not obligated to validate the size of every packet that passes through them. However, your filter should validate the size of any packets where a malformed packet would otherwise cause your filter to trigger a buffer overflow. For example, if your filter copies all ARP replies into a pre-allocated buffer, first validate that the ARP reply isn't too large to fit into the buffer. (This is not strictly necessary, since the miniport "shouldn't" give you an excessively-large packet. However, you are on the network datapath, which means you're handling untrusted data being processed by a potentially-buggy miniport. A little extra defense-in-depth is a good idea.)
Filters must not originate packets that are larger than the MTU (on either the send or receive paths).
I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !
First one, we can see an Ethernet II header following the wifi header :
Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.
Second is "raw data" directly following the wifi header.
Same question as before, how are we supposed to know that Data was following, and not LLC ?
First question:
To quote a comment in the Wireshark 802.11 dissector:
/* I guess some bridges take Netware Ethernet_802_3 frames,
which are 802.3 frames (with a length field rather than
a type field, but with no 802.2 header in the payload),
and just stick the payload into an 802.11 frame. I've seen
captures that show frames of that sort.
There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.
IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.
"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.
Second question:
The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).
Are you capturing on a "protected" (WEP or WPA/WPA2) network?