What is this nonsense?
Surely you wondered when reading the title. I admit, I was visited by exactly the same thoughts when reading the documentation from Bar to Scar-Print S.
And the case is as follows, the store complained that there was no unloading on some scales. I will not say how much time I spent on solving this problem, I will simply describe the introductory data under the cut and what led to the solution of the problem.
Input data
What do we have from the source? The scheme from the network point of view is absolutely banal.
- Store subnet 192.168.1.0/24 with devices and router 192.168.1.254 and weights 192.168.1.200
- Subnet terminal server 192.168.2.0/24 with a terminal server 192.168.2.10 and a gateway for it 192.168.2.254
- Between routers that have local addresses 192.168.1.254 and 192.168.2.254, a tunnel is raised on public interfaces and mutual static routes to the subnets that interest us to these tunnels.
- From the terminal server 192.168.2.10 data is not unloaded on 192.168.1.200
Well. First of all I check the ping to the weights from the terminal. Not pinged. Checking the availability of scales from the segment 192.168.1.0/24. Ping Baaa, yes, everything is trite here - the gateway is not registered on the scales, nothing works.
')
Inexplicable but the fact
I enter the weights menu, and then the first point of surprise comprehends me - and there are no gateway settings. Not at all. Yes, this can not be, open the documentation:
ARP is, but the device is passive (what is a passive device with IP / UDP support in general?). But it worked. And it works in other stores with routing. It turns out that these scales also ping from the 192.168.2.254 router. And from the segment 192.168.0.0/24, also connected to the router 192.168.2.254. Thus, the scales know the MAC of the router, the frames form the correct ones, but for some reason they are lost on the way to the terminal server 192.168.2.10.
What was tested? The involved intermediate switches (uncontrollable, without L3 naturally) of the segment 192.168.2.0/254 rebooted. The router 192.168.2.254 rebooted. Changed the IP address on the scales on a knowingly routed to the terminal server.
And the problem is solved very simply by resetting the scales themselves.
PS I wonder how the guys from Streak made support in sending the firmware to other subnets of the packets, do they just take that src MAC that came to them and set it up as dst? And all support for ARP is in the sense that the scales are able to respond to ARP requests, but not generate them?