I am doing some changes in the SO_PRIORITY of the socket that sends UDP packets, using the command setsockopt, is there a way to see that changes with Wireshark or Tcpdump.
I read that can be DSF (Differentiated Services Field), but I am not sure because when I make the changes I see that this field is 00.
I am running a Linux Mint 19.3
It is part of the 802.1Q header. For ex:
> 802.1Q Virtual LAN, PRI: 5, DEI: 0, ID: 4
101. .... .... .... = Priority: Voice, < 10ms latency and jitter (5)
...0 .... .... .... = DEI: Ineligible
.... 0000 0000 0100 = ID: 4
Type: IPv6 (0x86dd)
Related
Random mac address that changes every five-ten minutes or so. Sending out two different packets from the same address. What is this for?
No. Time Source Destination Protocol Length Info
9 0.821581 controller host HCI_EVT 42 Rcvd LE Meta (LE Advertising Report)
Frame 9: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface bluetooth-monitor, id 0
Bluetooth
Bluetooth Linux Monitor Transport
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 40
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scannable Undirected Advertising (0x02)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: 77:fd:98:85:c9:32 (77:fd:98:85:c9:32)
Data Length: 28
Advertising Data
16-bit Service Class UUIDs
Length: 3
Type: 16-bit Service Class UUIDs (0x03)
UUID 16: Google (0xfe9f)
Service Data - 16 bit UUID
Length: 23
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Google (0xfe9f)
Service Data: 026f4c574c3751686a4f4c63000001759a6c74b2
RSSI: -75dBm
No. Time Source Destination Protocol Length Info
10 0.823598 controller host HCI_EVT 24 Rcvd LE Meta (LE Advertising Report)
Frame 10: 24 bytes on wire (192 bits), 24 bytes captured (192 bits) on
interface bluetooth-monitor, id 0
Bluetooth
Bluetooth Linux Monitor Transport
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 22
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: 77:fd:98:85:c9:32 (77:fd:98:85:c9:32)
Data Length: 10
Advertising Data
Manufacturer Specific
Length: 9
Type: Manufacturer Specific (0xff)
Company ID: Google (0x00e0)
Data: 0a89fa5bf176
RSSI: -75dBm
This might be some kind of BLE beacon using a random address for privacy. Apart from being registered to Google, there doesn't seem to be any other public information on its use
I am trying to read the data coming from one device with the CAN communication protocol. I am using the Kvaser CAN-USB connector and python-can, but after sending the message I get the following:
Here's the my code:
import can
import time
bus=can.interface.Bus(bustype='kvaser',channel=0, bitrate=250000)
print (bus)
time.sleep(1)
msg =can.Message(arbitration_id=0x032)
print(msg)
time.sleep(1)
while True:
bus.send(msg)
recvMsg = bus.recv(timeout=0.5)
print (recvMsg)
time.sleep(1)
And here's the response i'm getting:
Kvaser Leaf Light v2, S/N 54781 (#1)
Timestamp: 0.000000 ID: 00000032 X DLC: 0
Timestamp: 1546613346.010231 ID: 0000 S E DLC: 4 00 01 00 00 Channel: 0
According to the manual I have to use the following:
Bitrate: 250 kbs
11-bit identifier: 0x031
Default settings TX only
8 byte message structure:
Byte:1,
Description:State of charge [%],
Type: Unsigned char,
Value: 0-200 LSB = 0.5 % SOC.
This is my first time I use this communication protocol and I have read the python-can 3.0 description, but still is not clear to me how to solve the problem. Any recommendation?
ID: 0000 indicates an error frame!
In the script you set the arbitration_id=0x032, but the manual says
11-bit identifier: 0x031
is that a typo?
How does your network look like? How many nodes do you have?
Have you terminated the CAN bus?
Is there any reason why you do not use PyCANlib from Kvaser?
The situation i have is Linux client is using UDP Socket. Client is sending message and in case no response within 10 seconds , Client will retry again in 10 seconds intervals.
The case is when connection is down , many trials are sent from client at the same time nothing was received on server side . Once the connection is up i found all previous messages are received at the same moment on server which means it was buffered and it causes a lot of problems because of duplicated messages received on the same moment on server side .
TCPDUMP ON client Side:
21:01:14.691903 IP 172.123.13211 > 172.34.13211: length 88 "1st at second 14"
21:01:24.692791 IP 172.123.13211 > 172.34.13211: length 88 "2nd at second 24"
21:01:34.694930 IP 172.123.13211 > 172.34.13211: length 88 "3rd at second 34"
21:01:44.696020 IP 172.123.13211 > 172.34.13211: length 88 "4th ate second 44"
Server TCPDUMP once the connection is up :
12:02:01.509518 IP 172.123.13211 > 13211: length 88 "Received 1st at second 1"
12:02:01.517841 IP 172.123.13211 > 13211: length 88 "Received 2nd at second 1"
12:02:01.543759 IP 172.123.13211 > 13211 length 88 "Received 3rd at second 1"
12:02:01.550741 IP 13211 > 172.123.13211: length 36
12:02:01.567948 IP 172.123.13211 > .13211: length 88
I need to understand in case of UDP socket is used and Connection is down .
how to avoid buffering packets during shortage
Client Code is in C++
Thank you
you might be looking for this :
How to flush Input Buffer of an UDP Socket in C?
Also the language you have used in the question is wrong. Please be more clean and precise and use relevant terminology
Use of IPv6 tunnels (like tunnelbroker.net) is possible on Azure VM, via ILPIP (Instance Level Public IP)?
I tried to use it, but I don't get replies for ping packets to IPv6 gateway.
Internet Protocol Version 4, Src: 100.90.204.79, Dst: 216.66.84.46
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 124
Identification: 0x33d7 (13271)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: IPv6 (41)
Header checksum: 0xea66 [validation disabled]
[Good: False]
[Bad: False]
Source: 100.90.204.79
Destination: 216.66.84.46
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 6, Src: 2001:470:1f14:105a::2, Dst: 2001:470:1f14:105a::1
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1001 0111 0111 0110 1010 = Flowlabel: 0x0009776a
Payload length: 64
Next header: ICMPv6 (58)
Hop limit: 64
Source: 2001:470:1f14:105a::2
Destination: 2001:470:1f14:105a::1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xd3f8 [correct]
Identifier: 0x5016
Sequence: 1
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 212]
[No response seen to ICMPv6 request in frame 212]
[Severity level: Warn]
[Group: Sequence]
Data (56 bytes)
Data: 8bb5ed56000000006ed40d00000000001011121314151617...
[Length: 56]
I suspect that Azure is rejecting IPv4 protocol 41, am I correct?
The following is documented:
Microsoft has played a leading role in helping customers to smoothly transition from IPv4 to IPv6 for the past several years. To date, Microsoft has built IPv6 support into many of its products and solutions like Windows 8 and Windows Server 2012 R2. Microsoft is committed to expanding the worldwide capabilities of the Internet through IPv6 and enabling a variety of valuable and exciting scenarios, including peer-to-peer and mobile applications. The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time.
If I generate an Ethernet frame without any upper layers payload and send it at layer two with sendp(), then I receive the "Mac address to reach destination not found. Using broadcast." warning and frame put to wire indeed uses ff:ff:ff:ff:ff:ff as a destination MAC address. Why is this so? Shouldn't the Scapy send exactly the frame I constructed?
My crafted package can be seen below:
>>> ls(x)
dst : DestMACField = '01:00:0c:cc:cc:cc' (None)
src : SourceMACField = '00:11:22:33:44:55' (None)
type : XShortEnumField = 0 (0)
>>> sendp(x, iface="eth0")
WARNING: Mac address to reach destination not found. Using broadcast.
.
Sent 1 packets.
>>>
Most people encountering this issue are incorrectly using send() (or sr(), sr1(), srloop()) instead of sendp() (or srp(), srp1(), srploop()). For the record, the "without-p" functions like send() are for sending layer 3 packets (send(IP())) while the "with-p" variants are for sending layer 2 packets (sendp(Ether() / IP())).
If you define x like I do below and use sendp() (and not send()) and you still have this issue, you should probably try with the latest version from the project's git repository (see https://github.com/secdev/scapy).
I've tried:
>>> x = Ether(src='01:00:0c:cc:cc:cc', dst='00:11:22:33:44:55')
>>> ls(x)
dst : DestMACField = '00:11:22:33:44:55' (None)
src : SourceMACField = '01:00:0c:cc:cc:cc' (None)
type : XShortEnumField = 0 (0)
>>> sendp(x, iface='eth0')
.
Sent 1 packets.
At the same time I was running tcpdump:
# tcpdump -eni eth0 ether host 00:11:22:33:44:55
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:33:47.774570 01:00:0c:cc:cc:cc > 00:11:22:33:44:55, 802.3, length 14: [|llc]