Hamradio

Example of “comph” as sysop on IGATE:

⇒sap 2 db0lj

After restarting IGATE the node DB0LJ found an alternative path to IGATE via DB0RES. IGATE learned “comph” for the new connection DB0LJ via DB0RES (Time = 3600). The entry DB0LJ on IGATE is fixed (Time = 0). Is it useful to store more information besides the destinationcall for VJ-compression?

Gedankenspiel IGATE ↔ DB0SMG via DB0SMG-11:

Fall 1: Wenn IGATE resettet wird und wieder hochkommt, pollt DB0SMG via DB0SMG-11 nach IGATE mit einem RR+. IGATE wird ein DM- schicken und die Verbindung wird getrennt. Neuer Verbindungsaufbau ohne Probleme.

Fall 2: Wenn IGATE resettet wird und wieder hochkommt, schickt IGATE ein SABM+ via DB0SMG-11 nach IGATE (bevor Fall 1 eingetreten ist). DB0SMG SABM+ wird ein UA- schicken und einen “Link Reset” intern “verarbeiten”. Ich glaube genau das ist im folgenden Trace passiert. Weiter unten haben ich manuell getrennt und im Trace kam ein “FlexLink:Init fm DB0SMG/15 (20 20)”. Ohne dem wird Xnet nicht anfangen Flexnetprotokoll zu sprechen, was aber eigentlich nach Beschreibung von Fall 2 noetig waere.

⇒mo -x +1 db0smg

Monitoring db0smg [ 1]

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I75^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I67^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I06^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR7v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I70^ pid CE [210]
3DB0AVH06848 DB0AVH7?857 DB0AX 0?412 DB0BER44960 DB0BID0?455 DB0BKK09985 DB0BLN0 ?832 DB0BLO0?831 DB0BQ 00416 DB0BQ 1?416 DB0DSD0?1234 DB0EAM03423 DB0ERZ0?1172 D B0FBG0?1184 DB0FEZ0?871 DB0FFT0?1356 DB0GR 00960

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR1v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I71^ pid CE [212]
3DB0GRL0<1198 DB0LOE0?1121 DB0OCA07455 DB0OCA8?447 DB0NDK0:871 DB0OVN0?596 DB0PS W0?1422 DB0SPR0?860 DB0WST0<649 DB0ZEH0?832 DK0BLN00948 DK0BLN::948 DK0BLN;;948 DK0BLN??871 OK0NI 081272 SR6BBA881086 SR6BBC0?1373

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR2v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I72^ pid CE [210]
3SR6BDX0?1373 DB0FC 00480 DB0FLX0=1015 DB0FUL0?1054 DB0GHH0<830 DB0GOS0?567 DB0H E 00550 DB0II 0<753 DB0II ==803 DB0IUZ02550 DB0IUZ3?562 DB0KG 00410 DB0KH 08436 DB0LJ 0?576 DB0MGB0?479 DB0SIF0?443 SR6DBA041167

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR3v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I73^ pid CE [209]
3SR6DBA;;1084 SR6DBC0?1424 SR6DLG0?1615 DB0ABZ00417 DB0BI 0?553 DB0FBB0>553 DB0GIS00439 DH9FG 89563 DB0DS 0=560 DB0LN 0?569 DB0OE 0?577 DB0YAB0?569 DB0ACC0:587 DB0DFA0?577 DB0MDX07434 DB0ME 0?598 DB0MKL0?497

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR4v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I74^ pid CE [206]
3DB0ACC;?609 DB0BRB0?601 DB0MKN0:515 DB0RHN0?463 DB0EEO0?581 DB0FOR0?459 DB0GIS7 7523 DB0SON0?493 DF0HMB0?639 DB0BM 08645 DB0BOH0<600 DB0KOE0>603 DB0UHA88610 DB0 WAL7<553 DB0AGI0<659 DB0AGI??669 DB0DEQ07624

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR5v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I75^ pid CE [206]
3DB0HB 01676 DB0MKA0?676 DB0NES0?526 DB0SFA0?666 DB0AGI»676 DB0HHN0?642 DB0TGM0 ?588 DB0ABC0?703 DB0KLL0:608 DB0KV 0?703 DB0PCH0?671 DB0PKE0<663 DB0AGM04678 DB0 DUS??581 DB0NDS00627 DB0PRA0?681 DB0RES09577

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR6v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I76^ pid CE [206]
3DB0RES:?581 DB0XO 0?739 DK0SB 88731 DB0DUS0?598 DB0RPL0?603 DB0SAW0>601 DB0SAW? ?610 DB0ACH0?762 DB0HB 55763 DB0MAR0>649 DB0MAR??649 DB0KLE;;735 DA5UHA00752 DB0 AGM55752 DB0AGM«752 DB0HHO0?698 DB0HHW0?689

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR7v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I77^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I07^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I00^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR1v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR0+

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR1-

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I01^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I20^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I12^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR3v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR1+

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR3-

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I13^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I41^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I24^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR5v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR2+

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR5-

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I25^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I62^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I36^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR7v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR3+

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR7-

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I37^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I03^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I40^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR1v

RESET:

⇒mo -x +1 db0smg

Monitoring db0smg [ 1]

1:fm IGATE to DB0SMG via DB0SMG-11 ctl DISC+

1:fm DB0SMG to IGATE via DB0SMG-11* ctl DM-

1:fm DB0SMG to IGATE via DB0SMG-11* ctl SABM+

1:fm IGATE to DB0SMG via DB0SMG-11 ctl UA-

Trash :(640) CONNECTED to 1:DB0SMG via DB0SMG-11 - 12:44:49

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I00^ pid CE [5]
0?%!

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I10^ pid CE [6]
0? !

FlexLink:Init fm DB0SMG/15 (20 20)

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR1v

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I11^ pid CE [201]
2

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I21^ pid CE [5]
1600

1:fm DB0SMG to IGATE via DB0SMG-11* ctl RR2v

1:fm IGATE to DB0SMG via DB0SMG-11 ctl I22^ pid CE [241]
2

1:fm DB0SMG to IGATE via DB0SMG-11* ctl I32^ pid CE [5]
1301

1:fm IGATE to DB0SMG via DB0SMG-11 ctl RR3v

Nachtrag:

Aehnliche Beobachtungen nachdem IGATE ↔ DB0ZKA-6 ausgefallen war und IP-over-AX25 von DB0ZKA-6 nach IGATE via DB0EL gelaufen ist. Bisher keine weiteren Gedanken dazu gemacht.

14.04.2007:

IGATE hatte Internetconnectionprobleme. DB0SIF ↔ IGATE kam nicht mehr hoch. Nach 13 Stunden ein Trace:Tracefile

I played around with AGWPE IP-over-AX25 adapter. This adapter talks only in UI-mode. I did an ARP-request on RF requesting the ARP of 44.130.60.100 (DB0FHN). DB0FHN answered with SABM+ (AX25) instead of UI (AX25DG). Is there an IP-default mode?

Warum wird ein UDP-Paket an IGATE mit der falschen Portnummer im ICMP UDP-Port unreachable beantwortet? Mit DB0SIF geht das:

server:~# nmap -P0 -sU -p10000 db0sif.ampr.org
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-04-28 14:13 CEST
Interesting ports on db0sif.ampr.org (44.130.28.100):
PORT      STATE  SERVICE
10000/udp closed unknown
Nmap finished: 1 IP address (1 host up) scanned in 0.453 seconds

Der tcpdump dazu:

14:13:32.411909 IP 84.147.221.158.60486 > 44.130.28.100.10000: UDP, length 0
14:13:32.437897 IP 44.130.28.100 > 84.147.221.158: ICMP 44.130.28.100 udp port 10000 unreachable, length 36

Nun aber mit IGATE:

server:~# nmap -P0 -sU -p10000 igate.ampr.org
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-04-28 14:14 CEST
Interesting ports on igate.ampr.org (44.130.254.254):
PORT      STATE         SERVICE
10000/udp open|filtered unknown
Nmap finished: 1 IP address (1 host up) scanned in 2.153 seconds

Der tcpdump dazu:

14:14:31.642260 IP 84.147.221.158.35302 > 44.130.254.254.10000: UDP, length 0
14:14:31.660560 IP 44.130.254.254 > 84.147.221.158: ICMP 44.130.254.254 udp port 4135 unreachable, length 36
14:14:32.643985 IP 84.147.221.158.35303 > 44.130.254.254.10000: UDP, length 0
14:14:32.657036 IP 44.130.254.254 > 84.147.221.158: ICMP 44.130.254.254 udp port 4135 unreachable, length 36

Jeder um 1 erhoehte angeforderte Port erhoeht sich um 256 beim Antwortport.

Funktionierende Systeme:
DB0SIF: Compiled:Feb 24 2007 15:10:58 © Jimy, DL1GJI
DB0AGI: Compiled:Apr 11 2007 21:28:58 © Jimy, DL1GJI
DB0AX: Compiled:Sep 20 2005 10:21:20 © Jimy, DL1GJI
DB0SAO: Compiled:Oct 25 2006 22:28:06 © Jimy, DL1GJI
DB0PRT: Compiled:Nov 14 2006 22:05:50 © Jimy, DL1GJI

Kaputte Systeme:
DB0MAR: Compiled:Oct 25 2006 22:31:53 © Jimy, DL1GJI
DB0ZWI: Compiled:Jul 21 2006 15:41:50 © Jimy, DL1GJI
IGATE: selbstcompiliert mit letzten Source von dir: Compiled:Apr 9 2007 12:13:04 © Jimy, DL1GJI

Kann man wohl nicht an der Version ausmachen :(

IGATE will learn DB0FC, but NETROMrouting is switched off (po 1 acon = 0!). Some Frames on the interlink:

1:fm DB0FC to IGATE via DB0FC-10* ctl I70^ pid CF [59]
L3 fm DB0FC to L3RTT LT 2 I --- IN=0 ID=0 S(0) R(0) [39]
L3RTT:     486915         10         10
1:fm IGATE to DB0FC via DB0FC-10 ctl I17^ pid CF [59]
L3 fm DB0FC to L3RTT LT 1 I --- IN=0 ID=0 S(0) R(0) [39]
L3RTT:     486915         10         10

1:fm DB0FC to IGATE via DB0FC-10* ctl I01^ pid CF [59]
L3 fm DB0FC to L3RTT LT 2 I --- IN=0 ID=0 S(0) R(0) [39]
L3RTT:     504945         10         10
1:fm IGATE to DB0FC via DB0FC-10 ctl I20^ pid CF [59]
L3 fm DB0FC to L3RTT LT 1 I --- IN=0 ID=0 S(0) R(0) [39]
L3RTT:     504945         10         10

It is not possible to enforce such behaviour with another Xnetinstance. DB0FC is a very old TNN-Node.

IP.NET: “arp port <number>”

<number> must be in range of available ports (0-23). If <number> is >23 and Xnet tries to send an ARP-request, it will crash.

DB0ZKA has a corrupt APRS-TNC. Sometimes the SMACK-Header is missing resulting in a corrupt KISS-frame. Xnet will NOT drop this packet.