Tomi, thanks very much for your answer.
You're right what you've said about ARP. Although the hardwareaddress is
already in the packet and it would be a very good idea to add this
thanksfully to the arp table (like flexnet does) it is vaild to check with
an ARP request. The problem is that my system does not even learn the route
where the packet has came from. So if a new station sends an echo request my
system is completely blind and disorientated where to get the
hardwareaddress to reply. (really stupid behaviour with respect to the fact
that it could get all the information from the received request...) Of
course the station mentioned below can answer ARP, but my system sends it to
QST instead of the real route where it came from. And of course the simple
digipeater (not an IP router) isn't impressed by a frame addressed to QST
which isn't even a valid callsign.
So since it doesn't seem to be possible to tell linux to do arp learning by
listening, my new question is how to tell it to learn routes.
Another question: How to setup a default route for a given port.
By the way, I've tested this VC and it seems to work fine. Thanks again.
But this insistance to do ARP in a VirtualCircuit is even more strange I
think. Now it does the connection, even sends an RR to the AX25 including
the echo request but then it is not able to reply within the already
establised VC connection!! It would be so easy...
Thanks
Robert
-----Ursprüngliche Nachricht-----
Von: Tomi Manninen <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Datum: Samstag, 16. Oktober 1999 20:19
Betreff: Re: ARP problem
>On Sat, 16 Oct 1999, Robert Schelander wrote:
>
>> When a new unknown station sends an IP packet to me, my station
>> sends an ARP request to QST to get the hw_address for the
>> received IP. I'm wondering, why it doesn't learn the hw_addr
>> automatically by looking at the callsign of the received packet.
>
>Because this is the way IP and ARP works. There is no guarantee
>whatsoever that the station that the IP frame came from is the correct
>route back. Usually it is but it doesn't have to be. The way I have
>understood it, this is a fundamental design decision that makes IP as
>flexible as it is.
>
>> The only way to get it work is to
>> apr -s 44.143.216.16 OE8TLQ -H ax25
>> otherwise arp displays the following:
>
>Why? Doesn't OE8TLQ support ARP ??? If that is the case then there isn't
>much else you can do...
