Bridge is not transparent default ?

neck99 · Sun Aug 14, 2022 11:29 am

Hello guys, I have strange case.

I have some machine that i can manage via PC application. I connect notebook via RJ45 to router and same, machine via RJ45 to router. Both get IP address from router DHCP and then i see in my notebook application what IP get machine. I can click on this IP then connect to machine and manage it.

If i use router TP-Link, Asus, D-link etc. no problem. I always see machine IP and I can manage it. But if i use Mikrotik. I can`t see.
I remove whole configuration from MT. No firewall, no other parametrs. Just create bridge + set IP addres to bridge and setup DHCP on bridge.
In DHCP leases I see that notebook and machine get IP but i can`t see this IP on my notebook aplication. So I can`t click on it and manage.

It is clear ?

It looks like simple bridge block something that machine IP don`t show in notebook aplication. Any idea ?
I tryed arp enable, proxy arp on bridge etc. Hmm.. Please help me.

BTW: tried on RB 450G i have I have 3 pieces of different years and different software on it. Same situation

Sun Aug 14, 2022 10:09 pm

Please send configuration.

k6ccc · Sun Aug 14, 2022 10:40 pm

To export and paste your configuration (and I'm assuming you are using WebFig or Winbox), open a terminal window,
and type (without the quotes) "/export hide-sensitive file=any-filename-you-wish". Then open the files section
and right click on the filename you created and select download in order to download the file to your computer.
It will be a text file with whatever name you saved to with an extension of .rsc. Open that file in your favorite
text editor and redact any sensitive information if desired / needed. Then in your message here, click the code
display icon in the toolbar above the text entry (the code display icon is the 7th one from the left and looks
like a square with a blob in the middle). Then paste the text from the file in between the two code words in brackets.

neck99 · Sun Aug 14, 2022 11:13 pm

Thanks a lot for interesting my case.
Config below. It is default MT config as is if you do reset configuration. If you can i can get access to MT because nothing is conected to it. This is my sample MT for test

.

P.S Bartku jak chcesz dam Ci zdalny dostęp

.

# jan/02/1970 00:01:43 by RouterOS 6.49.6
# software id = KBLB-9206
#
# model = 450G
# serial number = 725208F66990
/interface bridge
add admin-mac=CC:2D:E0:A7:7A:F6 auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

benoitc · Mon Aug 15, 2022 8:40 am

on wich version?

neck99 · Mon Aug 15, 2022 10:54 am

on wich version?

version ? RouterOS 6.49.6 on RB450G old one and bran new just buy. Same situation.

inteq · Mon Aug 15, 2022 11:41 am

Wild guess because I just woke up.
Maybe because your machine has a static IP in 192.168.1.0 that is default on Asus and Mikrotik's default is 192.168.88.0 ?
Change pool and DHCP server details to 182.168.1.0 or 192.168.0.0 network on Mikrotik.
Could be that the machine has a firewall allowing only connections from certain networks.

sindy · Mon Aug 15, 2022 12:11 pm

From what you wrote it seems that the "application" for the "machine" is using some kind of discovery protocol at L2. With default settings, the Mikrotik bridge conforms to IEEE 802.1D in terms that it does not forward frames with "link-local" multicast destination MAC addresses (such as STP, LLDP). So if your "application" uses this kind of multicast MAC address (or even LLDP as such), setting protocol-mode on the bridge to none might resolve your issue, but for the cost of losing STP on the bridge.

neck99 · Mon Aug 15, 2022 1:03 pm

Wild guess because I just woke up.
Maybe because your machine has a static IP in 192.168.1.0 that is default on Asus and Mikrotik's default is 192.168.88.0 ?
Change pool and DHCP server details to 182.168.1.0 or 192.168.0.0 network on Mikrotik.
Could be that the machine has a firewall allowing only connections from certain networks.

No. I can set any IP range on Dlink, TP-LINK etc. No matter. On D-link in range 192.168.88.1/24 working fine

neck99 · Mon Aug 15, 2022 1:10 pm

From what you wrote it seems that the "application" for the "machine" is using some kind of discovery protocol at L2. With default settings, the Mikrotik bridge conforms to IEEE 802.1D in terms that it does not forward frames with "link-local" multicast destination MAC addresses (such as STP, LLDP). So if your "application" uses this kind of multicast MAC address (or even LLDP as such), setting protocol-mode on the bridge to none might resolve your issue, but for the cost of losing STP on the bridge.

Interesting. Was RSTP on bridge setting. Will change to NONE and check evening. Thanks. Let you know.
No problem for my to lose STP on the bridge.

. This is MT only for this machine for maintenence

.

neck99 · Tue Aug 16, 2022 9:37 am

From what you wrote it seems that the "application" for the "machine" is using some kind of discovery protocol at L2. With default settings, the Mikrotik bridge conforms to IEEE 802.1D in terms that it does not forward frames with "link-local" multicast destination MAC addresses (such as STP, LLDP). So if your "application" uses this kind of multicast MAC address (or even LLDP as such), setting protocol-mode on the bridge to none might resolve your issue, but for the cost of losing STP on the bridge.

Unfortunately, setting protocol-mode on the bridge to none not resolve problem. Still IP address not show on aplication.
Anyway You had a good idea Sindy. I also think that something is blocking the broadcast in the bridge layer.
The question is what ?

Someone have any idea ?

bpwl · Tue Aug 16, 2022 1:12 pm

In the "bridge" "Hosts" tab, you can see the MAC addresses of PC and device, with the correct ethernet interface in the "On Interface" column. Right?

neck99 · Sat Aug 20, 2022 3:44 pm

Yes. All MAC address are from machine and one from tablet.
On other router for example D-Link it looks same.

bpwl · Sat Aug 20, 2022 4:01 pm

That's the "DHCP Leases" table, not the "Bridge Hosts" table !

Klembord-2.jpg

anav · Sat Aug 20, 2022 4:07 pm

thanks bpwl, I didnt know the bridge's dirty laundry was visible in that way.
Curious what would you have done if the bridge was not pulling dhcp duty and all data was being passed via vlan(s) ????

sindy · Sat Aug 20, 2022 4:07 pm

The bridge ports window shows that the traffic between ether2 and ether3 bypasses the CPU (both indicate H, so hardware forwarding is active). That makes it even more strange, as if something blocks the discovery traffic of the "application", it must be the switch chip. So can you set hw=no on the /interface bridge port rows for ether2 and ether3 and try again?

neck99 · Sat Aug 20, 2022 4:51 pm

That's the "DHCP Leases" table, not the "Bridge Hosts" table !

Klembord-2.jpg

sorry

neck99 · Sat Aug 20, 2022 4:52 pm

The bridge ports window shows that the traffic between ether2 and ether3 bypasses the CPU (both indicate H, so hardware forwarding is active). That makes it even more strange, as if something blocks the discovery traffic of the "application", it must be the switch chip. So can you set hw=no on the /interface bridge port rows for ether2 and ether3 and try again?

done but still no effect

neck99 · Sat Aug 20, 2022 5:06 pm

if anyone wants, I can give access to MT and show how it works with a regular router dlink/ asus etc.
Please send me whatsup number on prv message

sindy · Sat Aug 20, 2022 5:21 pm

Private messaging is disabled on this forum.

The key is what kind of frames the application sends when discovering the devices, so the best next step would be to run Wireshark one the PC and sniff the exchange between the application and the device, once when the device is connected via one of the switches with which everything works and once when it is connected via Mikrotik.

neck99 · Sat Aug 20, 2022 5:46 pm

Below compare traffic in Wireshark - ASUS rouer vs MT.
On ASUS machine get IP 192.168.1.22 and i See this IP on application. Tablet IP is 192.168.1.26

https://www.szybkiplik.pl/m6B4AkJ7UM

neck99 · Sat Aug 20, 2022 6:09 pm

it look like f8:55

63:79:67 is machine MAC and get IP 192.168.1.22 from ASUS Router and i see it in Wireshark log file - talk with tablet with TP-Link card 192.168.1.26 on UDP port

No. Time Source Destination Protocol Length Info
78 5.450033 192.168.1.22 192.168.1.26 UDP 98 6811 → 57241 Len=56

Frame 78: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface \Device\NPF_{74A3B348-DF45-45B2-94FA-45471B5AAE9F}, id 0
Ethernet II, Src: Visteon_63:79:67 (f8:55

63:79:67), Dst: Tp-LinkT_63:c7:b6 (50:3e:aa:63:c7:b6)
Internet Protocol Version 4, Src: 192.168.1.22, Dst: 192.168.1.26
User Datagram Protocol, Src Port: 6811, Dst Port: 57241
Data (56 bytes)

0000 00 00 00 32 00 11 44 49 41 47 41 44 52 31 30 42 ...2..DIAGADR10B
0010 4d 57 4d 41 43 46 38 35 35 43 44 36 33 37 39 36 MWMACF855CD63796
0020 37 42 4d 57 56 49 4e 57 42 41 33 31 42 4e 30 33 7MINWA31BN03
0030 30 43 46 38 34 39 33 39 0CF84939

But not see this MAC in Wireshark log file on MT connection. I go to check it anagin

neck99 · Sat Aug 20, 2022 6:47 pm

After restart MT to default. I see connection with Machine MAC and ip 192.168.88.246 (PC 192.168.88.250) but still no present on aplication.

https://www.szybkiplik.pl/iDq7eX79mm

I Can ping machine IP via MT and PC.

No idea realy

sindy · Sat Aug 20, 2022 7:09 pm

Open a command line (Terminal) window in Winbox, make it as wide as your screen allows, and with hw still set to no for both Ethernet interfaces involved (the one to which the tablet is connected and the one to which the visteon device is connected), run /tool sniffer quick port=6811 while the application is running. It should show you whether the query packets from the tablet get in, whether Mikrotik forwards them, whether any responses arrive, and whether Mikrotik forwards the responses back.

If you can't see the queries to even come, run /interface ethernet print stats and see whether the rx-too-short counter or the rx-fcs-error counter are non-zero and grow while the application is running.

I can see nothing too strange about the query frames - they are broadcast ones as expected, but other than that all the Ethernet, IP, and UDP headers look normal. The size of 48 bytes is lower than the minimum Ethernet frame size required (64 bytes), but there is some more software and hardware between the point where npcap is hooked to the network stack and the wire, so I don't expect this to be the actual issue (there are other frames smaller than 64 bytes as well).

bpwl · Sat Aug 20, 2022 7:24 pm

Just opened Wireshark to look at the MT flow.
I'm a bit lost ... what is that ARP request from 192.168.88.250 for 169.254.255.255 supposed to be initiated for? (broadcast address of a self-assigned IP address ????)

Above in "Hosts" I see that device is on ether3 and tablet is on ether4 . Traffic should flow, transparant.
Config file contains no special blocking AFAIK.
I was looking for "identical Horizon" value on ether3 and ether4 port, what would block traffic between them. But this is not set in the config file.

bpwl · Sat Aug 20, 2022 7:53 pm

thanks bpwl, I didnt know the bridge's dirty laundry was visible in that way.
Curious what would you have done if the bridge was not pulling dhcp duty and all data was being passed via vlan(s) ????

Dirty Laundry?

I don't know any relation between DHCP and the L2 bridge and VLAN traffic. Once the IP address is assigned then the flow is L2 managed, with ARP to find the L3/L2 address translation.

Bridge "hosts" table shows all information, including VLAN MAC addresses, and that info is in "Switch Host" with HW offloading.

My current home setup here ... wAP with different VLAN (some tag/untag via bridge like WLAN1.30, and some tag/untag via wifi driver like 1.40 for MAC address based dynamic VLAN)
Don't want to explain what is what and why (my evolving home setup, nothing special, only the airco is connected now on WLAN1.40)
Just wanted to show that "Bridge Hosts" information is not bound to DHCP or even explicit VLAN interface definitions.

Klembord-2.jpg

Klembord-3.jpg

neck99 · Sat Aug 20, 2022 8:08 pm

All time only this same:

eth4 PC and bridge - visible in sniff
eth3 Machine - no exist in sniff

no errors - checked couple times

neck99 · Sat Aug 20, 2022 8:22 pm

Maybe someone want access for test it. It's MT with default configuration, nothing is connect. Onl PC and Machine. You can break as much as possible, nothing will happen

bpwl · Sat Aug 20, 2022 8:53 pm

And here I see that confusion again between the "DHCP lease table"and the "ARP table". Both contain MAC/IP tuples.
5 years ago I saw router firmware developers optimise their memory usage by merging both tables in one. It was very popular and they seemed to copy it from each other.
They both contained (almost) the same information.
DHCP trouble began ....

DHCP table is : MAC-chaddr / IP address
ARP table is : MAC-srcaddr / IP address

All cases with L2.5 bridges in the network (like wifi repeaters) started to have problems, because then the MAC-srcaddr and MAC-chaddr for a device differ !
(The MAC-chaddr is the MAC of the device, the MAC-srcaddr is the MAC of the bridge interface.)
Sometimes (MT) there is an option to always use MAC-srcaddr for DHCP server, making it impossible to give a unique IP address to a client behind a L2.5 bridge.
In other cases (MT?) the DHCP Offer is sent (as response) to the unreachable MAC-chaddr.

PS: 'chaddr' is for DHCP (payload data) only. 'srcaddr' is in the packets address header and appears in "ARP", "Bridge Hosts", "Switch host"

bpwl · Sat Aug 20, 2022 8:56 pm

All time only this same:

eth4 PC and bridge - visible in sniff
eth3 Machine - no exist in sniff

no errors - checked couple times

Device 192.168.88.250 is sending broadcast (to what IP? 169.254.255.255 or 192.168.88.255 ??)
Broadcast should be flooded to all ports of bridge.

sindy · Sat Aug 20, 2022 9:02 pm

eth4 PC and bridge - visible in sniff
eth3 Machine - no exist in sniff

Well, you say eth3 does not exist in sniff, but the statistics for ether3 is completely empty, so if the device did get an IP address via DHCP, it could not be connected to ether3.

Second, was the hardware forwarding disabled on all ports when doing the sniff (as you've mentioned you've reset the Mikrotik to defaults in the meantime)?

The sniff shows that the Mikrotik has no problems receiving the queries from the application. It may have forwarded them or may have not - it depends on whether the hardware forwarding was disabled or not. If it was disabled, the sniff proves that the queries have not been forwarded. If it was enabled, it proves nothing because they could have been forwarded by the switch chip, and the sniffer cannot see frames that bypass the CPU.

neck99 · Sat Aug 20, 2022 11:02 pm

HW is enable as default. So after restart HW is enable.
Machine was connected to ETH3 and blinking (get IP address).

I completely do not understand what is blocking here

(

bpwl · Sun Aug 21, 2022 12:37 am

IIf it's totally weird, you have to think about hardware. First suspect is ethernet connector, ethernet port and ethernet cable.
More difficult things come later, like grounding loops.

A blinking LED is not very precise for troubleshooting. Replace the machine with a known good device (PC?) with good diagnostics. Another MT device could also be used.

sambuddy200471 · Sun Aug 21, 2022 4:00 am

Hello neck99,
I have been experiencing an issue i think is similar/same as yours. I have a standard domestic wifi access point connected to my MT router. If i connect my laptop to that wifi access point, i can open winbox and the MT router is discovered and i can connect to it. I also have a MT access point connected to the router. If i connect my laptop to the MT access point, winbox cannot discover the MT router, but, if i manually enter the mac address, i can connect to it. This was indicating to me that i had something blocking either the discover requests or responses in the MT access point.
I have just resolved this issue. I found that when i connected to the MT access point, windows would clasify it as a public network and by default have network discover and file/print sharing turned off. It seems as though network discovery also includes blocking broadcast packets which is why winbox couldn't discover my router. My solution was to tell windows it was a private network and to turn network discover on.
To turn it on, I simply opened a file explorer window. I selected "Network" from the left hand column. I was then prompted to turn on "sharing and discover" and i followed the prompts.

If this is the same issue as your, I hope this solution helps.
Regards
Stuart

neck99 · Sun Aug 21, 2022 12:18 pm

IIf it's totally weird, you have to think about hardware. First suspect is ethernet connector, ethernet port and ethernet cable.
More difficult things come later, like grounding loops.

A blinking LED is not very precise for troubleshooting. Replace the machine with a known good device (PC?) with good diagnostics. Another MT device could also be used.

Hardware and cable all is OK.

I have connect PC and Machine to ASUS router and working fine in this same time I disconect from ASUS and plug it to MT which is located at ASUS and not working.

neck99 · Sun Aug 21, 2022 12:18 pm

Hello neck99,
I have been experiencing an issue i think is similar/same as yours. I have a standard domestic wifi access point connected to my MT router. If i connect my laptop to that wifi access point, i can open winbox and the MT router is discovered and i can connect to it. I also have a MT access point connected to the router. If i connect my laptop to the MT access point, winbox cannot discover the MT router, but, if i manually enter the mac address, i can connect to it. This was indicating to me that i had something blocking either the discover requests or responses in the MT access point.
I have just resolved this issue. I found that when i connected to the MT access point, windows would clasify it as a public network and by default have network discover and file/print sharing turned off. It seems as though network discovery also includes blocking broadcast packets which is why winbox couldn't discover my router. My solution was to tell windows it was a private network and to turn network discover on.
To turn it on, I simply opened a file explorer window. I selected "Network" from the left hand column. I was then prompted to turn on "sharing and discover" and i followed the prompts.

If this is the same issue as your, I hope this solution helps.
Regards
Stuart

All firewalls was totally OFF for all networks

sambuddy200471 · Sun Aug 21, 2022 12:25 pm

Hello neck99,
You may find that the network discovery and the firewall are treated seperately in windows. E.g. With the firewall disabled, network discovery still wont work. Please check that network discovery is enabled regardless of firewall state.
Cheers
STuart

neck99 · Sun Aug 21, 2022 1:03 pm

I want to check if prolem is in DHCP or BRIDGE

I have idea to create new bridge on ETH3, ETH4 and ETH5 without DHCP. Connect Asus router with DHCP and conect it to MT. Also machine and PC connect to MT.

Let me know i need to create only BRIDGE and add ETH3,4,5 to it without set IP addreess to bridge right ? It should working like transparent switch right ?

sindy · Sun Aug 21, 2022 1:09 pm

I have to repeat my suggestion - when hw is set to no on all bridge ports, what does the sniffer show? Also, I did not understand your description of the meaning of the flashing LED on the "device" - does it mean it is currently attempting to get an IP address via DHCP or that it has already got one?

If it means that it is attempting to get one, the issue may be both hardware as @bpwl has suggested (even mechanical compatibility of the 8p8c plug and receptacle can be an issue, I did experience such cases) and the DHCP response. If the "device" was indeed connected to ether3 when the statistics was showing 0 packets on it, it is definitely a hardware issue, because if it was a DHCP issue, at least the DHCPDISCOVER frames would have to be shown in the statistics.

Who is online