@MSGID: 2:280/5555 69847b49
@REPLY: 2:5001/100.1 6983d24f
@TID: FMail-W32 2.3.0.1-B20240319
@TZUTC: 0100
@CHRS: CP850 2
Hello Dmitry,

On Wednesday February 04 2026 23:12, you wrote to me:

 MV>> Note that in the particular case of 280/2060, the AKA mismatch
 MV>> only occurs when connecting via IPv6. There is no problem when
 MV>> connecting via IPv4. So you may have to split it up and test both
 MV>> protocols.

 DP> Wow, that`s amazing! I never thought someone would provide different
 DP> addresses on ipv4 and ipv6. It was really beyond my imagination.

 Same here. If last week someone had proposed such a situation could
arise and should be taken covered by error detection, I would have
rejected it as outlandish. It shows that reality can be weirder than
imigination. :-)

 DP> New tests will handle such cases: I was testing both ipv4 and ipv6,
 DP> but saved node information only once (ipv6 preferred). This is
 DP> actually a good case, because now I am getting node information:

 Now someone should repeat the error to test it. The sysop of
2L280/2060 has corrected the original error in the meantime.

 DP> binkp ipv6
 DP> binkp ipv4
 DP> ifcico ipv6
 DP> ifcico ipv4
 DP> modem ifcico

 DP> and more to come..

OK...

 DP> If it`s complicated, I am having a good time testing and fixing it :)

You`r doing a good job. Keep going!


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
 * Origin: http://www.vlist.eu (2:280/5555)
SEEN-BY: 19/10 50/109 154/10 203/0 221/0 6
240/1120 5832 250/1 280/464 5003
SEEN-BY: 280/5555 301/1 310/31 460/58 463/68
5000/111 5015/46 5019/40
SEEN-BY: 5020/329 545 715 830 846 848 1042 4441
12000 5022/77 5030/49 1081
SEEN-BY: 5053/51 58 5058/104 5060/900 5061/133
5075/35 128 5083/1 444
@PATH: 280/5555 5020/1042 4441