Community discussions

MikroTik App
 
User avatar
vecernik87
Forum Veteran
Forum Veteran
Topic Author
Posts: 882
Joined: Fri Nov 10, 2017 8:19 am

packet sniffer streams incorrect data

Thu Jan 24, 2019 7:25 am

I have been playing with virtual machines, tunnels etc... long story short: when sniffing and streaming packets, sniffed data seems correct but streamed data are different and most likely wrong!
Running code where 00:15:5D:C9:30:09 = my virtual machine MAC and 10.245.24.67 = my desktop
/tool sniffer
set file-name=vlan.pcap filter-interface=eoip-chr-trunk filter-mac-address=00:15:5D:C9:30:09/FF:FF:FF:FF:FF:FF filter-operator-between-entries=and streaming-enabled=yes streaming-server=10.245.24.67
This code should obviously produce two same results - save the data straight in the router to "vlan.pcap" and at the same time stream data to my desktop (where is already wireshark capturing it)
Result: nope, data are NOT same. I tried several times, with both CHR and physical router, capturing different interfaces, capturing everything - in all cases, half of packets is always streamed without VLAN.
Feel free to observe my PCAP files. Here is the link: https://drive.google.com/drive/folders/ ... sp=sharing (I can't upload it to this forum - unsupported format)
I am getting bit clueless what to do. streaming and displaying live packets with wireshark is much faster than sniffing it to router, then downloading the file and opening it later. And it is quite hard to debug VLANs when I can't trust sniffed packets...
(obviously files are not exactly same as streamed packets are encapsulated in TZSP, therefore almost twice as large)

Please, can anyone test this simple behavior in his lab and confirm if I am completely out of my mind or the
/tool sniffer
can't stream properly? If it gets confirmed, I will be happy to follow up with support@mkt


TL;DR background story: I need to get full L1 connectivity between Debian VM running on Hyper-V and remote site network (remote site is available via site2site L3 VPN but my VM needs complete access to all vlans etc). This is typical use case for EoIP as it behaves like another Ethernet cable and my VM feels exactly as being plugged into switch on remote site. Job should be simple - as I am running CHR on same hypervisor, I created EoIP tunnel between RBD52G at remote site to local CHR. in CHR I already have separate virtual network adapter (as well as virtual switch in HyperV) which connects it to Debian VM. All I needed was simple bridge between EoIP and this virtual network adapter. Should be easy peasy.
Booting Debian VM for the first time, configuring eth1 for DHCP and it gets the IP from remote site untagged DHCP! Great!
Now setting up VLANS: iface eth1.1016 inet dhcp should do the job but...
Haaang on! It does not get the IP. Why not?
Lets set IP manually and capture packets on RB to see whats going on. All arp-responses are without VLAN? Oh, silly me, I had to misconfigure bridge vlans along the path, right?
Well, nope. Bridges are fine.
Allright, lets watch the packets on CHR. Again half of them without VLAN. This time all arp-requests ... thats getting weird...
Watch packets straight on router without streaming? hey, they are all fine? *shenanigans intensifies*
...
Now I am really confused why my Debian doesn't get the IP - virtual adapters are configured properly (vlan's work fine on another adapter on the same VM). But thats not a question for this time. Later I will do separate topic where I will cry how stupid HyperV is, because there is no 802.1ad (QinQ) support and how DHCP in CHR does not work when it is on VLAN on bridge, but it works when it is on VLAN on Eth, all while bridge has no filters or dhcp guard and Eth is connected to the bridge (so technically Eth is slave and VLAN should be on the bridge)
 
innokentiy
just joined
Posts: 4
Joined: Thu Feb 16, 2012 9:04 am

Re: packet sniffer streams incorrect data

Mon Sep 19, 2022 1:46 pm

I confirm that sniffer tool indeed streams incorrect data even in the latest 7.6beta6. Ethernet packets captured by the tool and streamed via TZSP do not contain 802.1Q headers, while the same packets written a file or displayed from buffer do contain those.

I've enabled both streaming and local file capture and sent a single packet. Both captures are attached, and it's clear that in streamed pcap 802.1Q headers are missing.

This is truly inconvenient, 'cause when you're unsure where packets go, VLAN label is indispensable to determine outgoing interface.
You do not have the required permissions to view the files attached to this post.
 
Kaldek
Member Candidate
Member Candidate
Posts: 111
Joined: Sat Jul 11, 2015 2:40 pm

Re: packet sniffer streams incorrect data

Tue Jan 24, 2023 11:45 am

Confirmed I am seeing the same problem on RouterOS 7.7. Pcap files have the VLAN tag, streamed TZSP packets do not. Mirrored the two side by side and I even have the File Pcap and what Wireshark saw both available in PCAP format.
 
peretuset
Trainer
Trainer
Posts: 7
Joined: Sat Apr 16, 2022 5:09 pm

Re: packet sniffer streams incorrect data

Fri Mar 31, 2023 12:03 pm

Hello,
I have run into the same issue with RouterOS 7.8.
When streaming, the VLAN tag is stripped from the packet and cannot be observed on the other end with Wireshark.
Did you run the problem through official Mikrotik support? If not, I will do it since it is a very useful tool with remote laboratories.
Best,
Pere
 
RobK
just joined
Posts: 2
Joined: Fri Mar 03, 2023 5:23 pm

Re: packet sniffer streams incorrect data

Wed Jul 05, 2023 11:54 am

Same issue still with 7.10.1. I found that outgoing packets are streamed correctly with VLAN ID. Just for incoming packets the .1Q header is missing in the stream. Local capture to memory or file is correct.
I'm currently working on a VLAN issue at a remote location and would love to have streaming work correctly. Has someone raised this with MikroTik support already?

Who is online

Users browsing this forum: Google [Bot], LabarH, sinisa and 97 guests