PB> of course. Why not. The responding host has really no right to
PB> assume that the same AX.25 channel will be used. But it's
PB> impossible to find ARP over digipeaters using UI frames. In
PB> most cases is the path same in both directions. I do not know
PB> how to make let the ARP request use existing virtual circuit.I
PB> have set the default IP mode set to VC, not to datagram.
PB> If I set the HW address using arp, it's OK. When the calling
PB> station is not known to system (DNS, ARP, routing) and only
PB> known informations are taken from IP request and the QSO, than
PB> the ARP request is sent to QST. How to change it?
This is something of a hot topic. Whether to cache digipeated paths learned
about on the air is a trade-off, with advantages and disadvantages. In fact,
whether to put digipeating into the kernel is also something of a hot topic.
The solution for digipeated paths is to set a manual ARP entry. This has been
the workaround for some time.
Don't forget that the AX.25 specification itself states that digipeating is a
temporary measure that should go away. Of course, it has been temporary for at
least the last 13 years since the specification was published!