Trace incoming multicast UDP messages with Wireshark - networking

I have an application A that is sending a multicast message to application B
The log shows the following:
Sender: 48704 -> /239.6.7.8:46655
Receiver: /172.17.95.17:48704, Hello, world!
Sender: 48704 -> /239.6.7.8:46655
Receiver: /172.17.95.17:48704, Hello, world!
Sender: 48704 -> /239.6.7.8:46655
Receiver: /172.17.95.17:48704, Hello, world!
As you can see, I am able to connect, send and receive messages.
In tshark, I can see only what the sender is sending.
What do I need to do in order to see the incoming message?
[hudson#edg-perf09 ~]$ tshark -ni any | grep "46655"
Capturing on 'any'
0.114114866 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
1.115497174 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
2.116822371 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
3.118153942 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
4.119370365 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
5.120568524 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655
6.121715504 172.17.95.17 -> 239.6.7.8 UDP 57 Source port: 48704 Destination port: 46655

Related

postman http get request with authentification fails with 401 reply

I have an IOT device (PV inverter). As with many of these there is an official API mostly for data retrival and some settings. However, given the right credentials (admin account) you can configure significantly more in the webinterface.
I would like to be able to do this from my home automation server directly (via node red finally). So I tried to have a look at the communication between the browser and the inverter via Wireshark.
I found some GET an POST calls, and wanted to start with the replication of a GET call via node-red or Postman first.
However, no matter what I tried so far I only get 401 replies.
Seemingly, I'm not able to setup the message with proper authentificaion. In wireshark the Postman and the original GET request are very close.
Here is the original (followed by a "200 OK" response):
Internet Protocol Version 4, Src: 192.168.0.64, Dst: 192.168.0.5
Transmission Control Protocol, Src Port: 56183, Dst Port: 80, Seq: 1, Ack: 1, Len: 601
Source Port: 56183
Destination Port: 80
[Stream index: 1]
[Conversation completeness: Incomplete (28)]
[TCP Segment Len: 601]
Sequence Number: 1 (relative sequence number)
Sequence Number (raw): 2463465501
[Next Sequence Number: 602 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 1894190984
0101 .... = Header Length: 20 bytes (5)
Flags: 0x018 (PSH, ACK)
[TCP Flags: ·······AP···]
Window: 512
[Calculated window size: 512]
[Window size scaling factor: -1 (unknown)]
Checksum: 0x8409 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[SEQ/ACK analysis]
TCP payload (601 bytes)
Hypertext Transfer Protocol
GET /commands/StandbyState HTTP/1.1\r\n
Host: 192.168.0.5\r\n
Connection: keep-alive\r\n
Accept: application/json, text/plain, /\r\n
Authorization: Digest username="technician", realm="Webinterface area",
nonce="63af2777:24350f8b8a09fb90b82b6ac480d325cc", uri="/commands/StandbyState", response="a09ac5fe504563040d0ff8acfd68653e", qop=auth, nc=00000022, cnonce="NaN"\r\n
username="technician"
realm="Webinterface area"
nonce="63af2777:24350f8b8a09fb90b82b6ac480d325cc"
uri="/commands/StandbyState"
response="a09ac5fe504563040d0ff8acfd68653e"
qop=auth
nc=00000022
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/108.0.0.0 Safari/537.36\r\n
Referer: http://192.168.0.5/\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\r\n
\r\n
[Full request URI: http://192.168.0.5/commands/StandbyState]
and here is the captured Postman packet
Internet Protocol Version 4, Src: 192.168.0.64, Dst: 192.168.0.5
Transmission Control Protocol, Src Port: 43404, Dst Port: 80, Seq: 1, Ack: 1, Len: 471
Source Port: 43404
Destination Port: 80
[Stream index: 5]
[Conversation completeness: Incomplete, DATA (15)]
[TCP Segment Len: 471]
Sequence Number: 1 (relative sequence number)
Sequence Number (raw): 990556558
[Next Sequence Number: 472 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 2175082347
0101 .... = Header Length: 20 bytes (5)
Flags: 0x018 (PSH, ACK)
[TCP Flags: ·······AP···]
Window: 513
[Calculated window size: 131328]
[Window size scaling factor: 256]
Checksum: 0x8387 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[SEQ/ACK analysis]
TCP payload (471 bytes)
Hypertext Transfer Protocol
GET /commands/StandbyState HTTP/1.1\r\n
[truncated]Authorization: Digest username="technician", realm="Webinterface area", nonce="63af2777:24350f8b8a09fb90b82b6ac480d325cc", uri="/commands/StandbyState", algorithm="MD5", qop=auth, nc=00000022, cnonce="NaN", response="a09ac5fe5
username="technician"
realm="Webinterface area"
nonce="63af2777:24350f8b8a09fb90b82b6ac480d325cc"
uri="/commands/StandbyState"
algorithm="MD5"
qop=auth
nc=00000022
cnonce="NaN"
User-Agent: PostmanRuntime/7.30.0\r\n
Accept: /\r\n
Postman-Token: e5d8ee2c-37fb-49ae-aa37-1cf05bfe8608\r\n
Host: 192.168.0.5\r\n
Accept-Encoding: gzip, deflate, br\r\n
Connection: keep-alive\r\n
\r\n
[Full request URI: http://192.168.0.5/commands/StandbyState]
[HTTP request 1/1]
Why does this not work?

VNF do not forward packets sent from Client in Openstack using VNFF Graph

I'm trying to ping from Client to 8.8.8.8 via VNF1 so I use VNFFG to force ICMP traffic of Client go through VNF1 before going out to internet.
After I apply the VNFFG rule in openstack, VNF1 can see MPLS packet encapsulated from Client's ICMP packet by openstack when I use tcpdump but the Forwarding Table of VNF1 do not receive any packet to continue forward that packet.
This is packet seen on VNF1:
09:15:12.161830 MPLS (label 13311, exp 0, [S], ttl 255) IP 12.0.0.58 > 8.8.8.8: ICMP echo request, id 10531, seq 15, length 64
I capture that packet, see that the content can be read (without encryption) and src, dst MAC belong to Client and VNF1 respectively.
This is my VNFFG template:
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Sample VNFFG template
topology_template:
node_templates:
Forwarding_path1:
type: tosca.nodes.nfv.FP.TackerV2
description: demo chain
properties:
id: 51
policy:
type: ACL
criteria:
- name: block_icmp
classifier:
network_src_port_id: 0304e8b5-6c37-4634-bde2-1351cdee5134 #CLIENT PORT ID
ip_proto: 1
- name: block_udp
classifier:
network_src_port_id: 0304e8b5-6c37-4634-bde2-1351cdee5134 #CLIENT PORT ID
ip_proto: 17
path:
- forwarder: VNF1
capability: CP1
groups:
VNFFG1:
type: tosca.groups.nfv.VNFFG
description: Traffic to server
properties:
vendor: tacker
version: 1.0
number_of_endpoints: 1
dependent_virtual_link: [VL1]
connection_point: [CP1]
constituent_vnfs: [VNF1]
members: [Forwarding_path1]
This is my VNF Descriptor:
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example
metadata:
template_name: sample-tosca-vnfd
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
capabilities:
nfv_compute:
properties:
num_cpus: 1
mem_size: 2 GB
disk_size: 20 GB
properties:
image: VNF1
availability_zone: nova
mgmt_driver: noop
key_name: my-key-pair
config: |
param0: key1
param1: key2
CP1:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
order: 0
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: my-private-network
vendor: Tacker
FIP1:
type: tosca.nodes.network.FloatingIP
properties:
floating_network: public
requirements:
- link:
node: CP1
I used this command to deploy VNFGG rule:
tacker vnffg-create --vnffgd-template vnffg_test.yaml forward_traffic
I do not know if the problem can come from the key I defined for VNF1 because I do not know what param0: key0 and param1: key1 used for and where are they?
How can I resolve to make the VNF forward these packet.

How to make grafana on nixos available in local network

My laptop and my nixos-server (hostname=nixos) are both conected to my router (fritz.box). I can access the rooter via ping (ping nixos.fritz.box) and ssh (ssh username#nixos.fritz.box).
What I want is to follow the first part of this guide to set up grafana on nixos. I then want to be able to access grafana from my laptop.
On the server I have configured nixos to run both grafana and a reverse proxy (nginx):
services.grafana = {
enable = true;
domain = "grafana.nixos.fritz.box";
port = 2342;
addr = "127.0.0.1";
};
# nginx reverse proxy for grafana
services.nginx.virtualHosts.${config.services.grafana.domain} = {
locations."/" = {
proxyPass = "http://127.0.0.1:${toString config.services.grafana.port}";
proxyWebsockets = true;
};
};
# Open ports for http and https
networking.firewall.allowedTCPPorts = [ 80 443 ];
system.stateVersion = "21.03";
Unfortunatelly I can't access the grafana webinterface from my laptop.
I tried changing around the value of services.grafana.domain and what I type into my browser (firefox/curl), here is what I got:
services.grafana.domain
argument of curl
output of curl
grafana.nixos.fritz.box
http://grafana.nixos.fritz.box/
curl: (6) Could not resolve host: grafana.nixos.fritz.box
grafana.nixos.fritz.box
https://grafana.nixos.fritz.box/
curl: (6) Could not resolve host: grafana.nixos.fritz.box
grafana.nixos.fritz.box
http://nixos.fritz.box/
curl: (52) Empty reply from server
grafana.nixos.fritz.box
https://nixos.fritz.box/
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to nixos.fritz.box:443
nixos.fritz.box
http://nixos.fritz.box/
curl: (52) Empty reply from server
nixos.fritz.box
https://nixos.fritz.box/
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to nixos.fritz.box:443
grafana.localhost
(on the server) http://grafana.localhost
curl: (7) Failed to connect to grafana.localhost port 80: Connection refused
grafana.localhost
(on the server) https://grafana.localhost
curl: (7) Failed to connect to grafana.localhost port 443: Connection refused
Especially the last 2 lines leave me perplexed.
netstat -an | grep LISTEN on the server gives me this:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2342 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
unix 2 [ ACC ] STREAM LISTENING 1837 /run/systemd/private
unix 2 [ ACC ] STREAM LISTENING 1841 /run/systemd/userdb/io.systemd.DynamicUser
unix 2 [ ACC ] SEQPACKET LISTENING 1853 /run/systemd/coredump
unix 2 [ ACC ] STREAM LISTENING 1862 /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 1868 /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 26958 /var/run/nscd/socket
unix 2 [ ACC ] STREAM LISTENING 1905 /run/systemd/journal/io.systemd.journal
unix 2 [ ACC ] STREAM LISTENING 12193659 /run/user/1001/bus
unix 2 [ ACC ] STREAM LISTENING 12205464 /run/user/1001/systemd/private
unix 2 [ ACC ] STREAM LISTENING 13312 /nix/var/nix/daemon-socket/socket
unix 2 [ ACC ] STREAM LISTENING 18416 /var/run/dhcpcd.sock
unix 2 [ ACC ] STREAM LISTENING 18418 /var/run/dhcpcd.unpriv.sock
unix 2 [ ACC ] STREAM LISTENING 13308 /run/dbus/system_bus_socket
I don't know how to make grafana available in the local network. Can someone help me with that, please?
(I know this question is somewhat similar to this one, but the solution there doesn't help me)
Adding the following line solved my problem (thanks to #Tch):
services.nginx.enable = true;

eth1 disappear after use new kernel 5.6.0 | uSID | Centos

In order to test SRv6 uSID in Linux, I compiled the new kernel 5.6.0 that in following Github:
https://github.com/netgroup/srv6-usid-linux-kernel.git
After compiled and reboot, my 2nd network adapter port(eth1) disappeared, two network adapter ports should the same type, and only eth0 was renamed to ens3, as follow:
[root#frank cisco]# uname -a
Linux frank 5.6.0+ #3 SMP Tue Jun 30 17:32:20 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root#frank cisco]# dmesg |grep eth
[ 2.311925] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 5e:00:00:00:00:00
[ 2.314897] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 2.770167] e1000 0000:00:04.0 eth1: (PCI:33MHz:32-bit) fa:16:3e:38:fd:91
[ 2.773194] e1000 0000:00:04.0 eth1: Intel(R) PRO/1000 Network Connection
[ 5.352825] e1000 0000:00:03.0 ens3: renamed from eth0
[root#frank cisco]#
[root#frank cisco]# lshw -class network -businfo
Bus info Device Class Description
========================================================
pci#0000:00:03.0 ens3 network 82540EM Gigabit Ethernet Controller
pci#0000:00:04.0 network 82540EM Gigabit Ethernet Controller
Follow is dmesg for two ports:
[root#frank cisco]# dmesg |grep 00:03.0
[ 0.700489] pci 0000:00:03.0: [8086:100e] type 00 class 0x020000
[ 0.702057] pci 0000:00:03.0: reg 0x10: [mem 0xfeb80000-0xfeb9ffff]
[ 0.703921] pci 0000:00:03.0: reg 0x14: [io 0xc000-0xc03f]
[ 0.707532] pci 0000:00:03.0: reg 0x30: [mem 0xfeb00000-0xfeb3ffff pref]
[ 2.311925] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 5e:00:00:00:00:00
[ 2.314897] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 5.352825] e1000 0000:00:03.0 ens3: renamed from eth0
[root#frank cisco]#
[root#frank cisco]# dmesg |grep 00:04.0
[ 0.708456] pci 0000:00:04.0: [8086:100e] type 00 class 0x020000
[ 0.710057] pci 0000:00:04.0: reg 0x10: [mem 0xfeba0000-0xfebbffff]
[ 0.711846] pci 0000:00:04.0: reg 0x14: [io 0xc040-0xc07f]
[ 0.715515] pci 0000:00:04.0: reg 0x30: [mem 0xfeb40000-0xfeb7ffff pref]
[ 2.770167] e1000 0000:00:04.0 eth1: (PCI:33MHz:32-bit) fa:16:3e:38:fd:91
[ 2.773194] e1000 0000:00:04.0 eth1: Intel(R) PRO/1000 Network Connection
Follow lshw cmd
"driver=uio_pci_generic"
[root#frank v2.81]# lshw -c network
*-network:0
description: Ethernet interface
product: 82540EM Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 3
bus info: pci#0000:00:03.0
logical name: ens3
version: 03
serial: 5e:00:00:00:00:00
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: bus_master rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000 driverversion=7.3.21-k8-NAPI duplex=full ip=172.16.1.140 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:10 memory:feb80000-feb9ffff ioport:c000(size=64) memory:feb00000-feb3ffff
*-network:1
description: Ethernet controller
product: 82540EM Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 4
bus info: pci#0000:00:04.0
version: 03
width: 32 bits
clock: 33MHz
capabilities: bus_master rom
configuration: driver=uio_pci_generic latency=0 <<<
resources: irq:11 memory:feba0000-febbffff ioport:c040(size=64) memory:feb40000-feb7ffff
And found the port bound by dpdk, but I didn't set any bound config...
[root#frank v2.81]# ./dpdk_setup_ports.py -s
Network devices using DPDK-compatible driver
============================================
0000:00:04.0 '82540EM Gigabit Ethernet Controller' drv=uio_pci_generic unused=e1000,igb_uio,vfio-pci <<<
Network devices using kernel driver
===================================
0000:00:03.0 '82540EM Gigabit Ethernet Controller' if=ens3 drv=e1000 unused=igb_uio,vfio-pci,uio_pci_generic
Other network devices
=====================
<none>
Does anyone know what is going on...and how to solve this problem...?
Thanks a lot!
Frank
After discussed with colleagues, the issue should be followed by this link:
https://www.kernel.org/doc/html/v4.12/driver-api/uio-howto.html
And as above guide, I can workaround the issue, but issue appear again after reboot...
[root#frank v2.81]# ls -l /sys/bus/pci/devices/0000:00:04.0/driver
lrwxrwxrwx. 1 root root 0 Jun 30 17:59 /sys/bus/pci/devices/0000:00:04.0/driver -> ../../../bus/pci/drivers/uio_pci_generic
[root#frank v2.81]# echo -n 0000:00:04.0 > /sys/bus/pci/drivers/uio_pci_generic/unbind
[root#frank v2.81]# echo -n 0000:00:04.0 > /sys/bus/pci/drivers/e1000/bind
[79965.358393] e1000 0000:00:04.0 eth0: (PCI:33MHz:32-bit) fa:16:3e:38:fd:91
[79965.360499] e1000 0000:00:04.0 eth0: Intel(R) PRO/1000 Network Connection
[root#frank v2.81]# ls -l /sys/bus/pci/devices/0000:00:04.0/driver
lrwxrwxrwx. 1 root root 0 Jul 1 16:12 /sys/bus/pci/devices/0000:00:04.0/driver -> ../../../bus/pci/drivers/e1000
[root#frank cisco]# ifconfig eth0 up
[ 221.792886] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 221.796553] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[root#frank cisco]# lshw -c network
*-network:0
description: Ethernet interface
product: 82540EM Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 3
bus info: pci#0000:00:03.0
logical name: ens3
version: 03
serial: 5e:00:00:00:00:00
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: bus_master rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000 driverversion=7.3.21-k8-NAPI duplex=full ip=172.16.1.140 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:11 memory:feb80000-feb9ffff ioport:c000(size=64) memory:feb00000-feb3ffff
*-network:1
description: Ethernet interface
product: 82540EM Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 4
bus info: pci#0000:00:04.0
logical name: eth0
version: 03
serial: fa:16:3e:38:fd:91
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: bus_master rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000 driverversion=7.3.21-k8-NAPI duplex=full latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:11 memory:feba0000-febbffff ioport:c040(size=64) memory:feb40000-feb7ffff

Puzzled about the `telnet localhost` and `telnet 0.0.0.0`

I wrote a simple GO program which listens to 0.0.0.0:9999 and 127.0.0.1:9999:
func main() {
go bind("0.0.0.0:9999", "111 ")
go func() {
time.Sleep(2 * time.Second)
bind("127.0.0.1:9999", "222 ")
}()
time.Sleep(time.Hour)
}
func bind(address string, content string) {
fmt.Println("-------------", address, "-----------------")
listener, err := net.Listen("tcp", address)
if err != nil {
panic(err)
return
}
fmt.Println(listener.Addr().String())
conn, _ := listener.Accept()
for {
_, err := conn.Write([]byte(content))
if err != nil {
panic(err)
}
time.Sleep(1 * time.Second)
}
}
The meaning of the code:
It binds two addresses, and gives different responses to the clients of them
binding "0.0.0.0:9999": will send "111 " repeat to client
binding "127.0.0.1:9999": will send "222 " repeat to client
And then I use telnet to try different addresses, and the responses are:
telnet 127.0.0.1 9999: 222 (OK)
telnet localhost 9999: 111 (WHY?!)
telnet 0.0.0.0 9999: 222 (WHY?!)
telnet <my-internal-ip> 9999: 111 (OK)
I'm quite confused about some of them:
telnet localhost 9999: 111 (WHY?!)
localhost should point to 127.0.0.1, so I think it's same to telnet 127.0.0.1 9999 and the response should be 222, but the actual one is 111
telnet 0.0.0.0 9999: 222 (WHY?!)
I think 0.0.0.0 is not same to 127.0.0.1, I expect to get response of 111, but get 222
I also have a demo project: https://github.com/golang-demos/go-bind-0.0.0.0-127.0.0.1-demo
Update: My os is OSX
Both localhost and 0.0.0.0 are resolved to 127.0.0.1 by the OS
$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms
$ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.035 ms`
localhost could resolve to something else depending on /etc/hosts file.
An excellent explanation for Linux ping 0.0.0.0 behavior is here.

Resources