Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - SA3THS

Pages: [1]
1
Det är inte för mycket svarstid för remoterig. Det är bara en indikering på att nått är fel då svarstiden är orimligt hög mellan två fiberanslutningar i samma lilla stad.

När jag ansluter "direkt" från publikt IP till publikt IP, utan VPN eller brandväggar i någon av ändarna var det ändå problem. Felet ligger i utbytet av trafik mellan operatörerna då trafiken måste gå 45-50 mil och vända för att ta sig fram.

Min omväg genom ett tredje ställe tvingar trafiken att gå en kortare väg som inte lider av felet.

2
Felkällan är nu inringad och jag har byggt runt felet!

42ms i svarstid tvärs över stan är mycket. För mycket.

Radion står hos en kund och jag minns att jag hade mycket kortare svarstid till kunden innan jag ordnade en direkt VPN-anslutning dit.

Jag tog därför bort den direkta vägen till kunden och ändrade så att trafiken skickas från min brandvägg, via jobbets brandvägg och vidare till kundens brandvägg. Resultatet? Istället för 42ms blev det 5ms. Dessutom routade jag all trafik från mitt nät till kundens publika IP via VPNet. Nu fungerar det direkt och utan några problem. Att jag inte kör interna IPt beror på att det blir enklare att köra mot det publika då jag tar med mig remoterig-lådan och front + mick ibland.


3
Tog med grejerna till jobbet och det funkade direkt. Inga problem.
Ska hitta någon granne med BBB och testa där. Är det samma fel där är det BBB som är boven i dramat.

4
41 ms stabilt till radiosidan.
Båda sidorna på fiber men olika operatörer.

5
Att skarva på 64 hjälpte inte heller.
Jag har även testat att byta ut nätdelen men det hjälpte inte heller.

Kanske värt att nollställa enheterna?

6
En grej som nästan utesluter BBB som felkälla är att jag har samma fenomen över IPSEC VPN. BBB ska inte kunna se vilka portar och tjänster som körs över tunneln.

7
Testade att byta portar. Samma fenomen.
Jag kollade om jag har senaste firmware och jag har version 2.88 dvs nyare än vad som finns på sidan.
Har jag fått en beta?

8
Btw.
Vad innebär inställningen "Use common network settings" ?

9
I felsökningssyfte gick jag ner i källaren och kopplade först in mig i min switch i källaren. Först i LAN-VLANet. Sedan WAN-VLANet utan att det fungerade. Jag kopplade sedan ur min kabel från bredbandsbolagets switch och kopplade in remoterig-lådan där. Samma fel!

Sedan gick jag upp i lägenheten igen och kopplade in remoterig-lådan i mitt net1-modem där det fungerade direkt.

Kan det vara så att BBB blockerar portar på nått vis?
Jag kör SIP 13000 UDP, Audio 13001 UDP och CMD 13002 UDP samt 13080 TCP för web och 13023 TCP.

10
Tog in min Net1-uppkoppling från bilen och där fungerar det direkt!

11
Har testat att köra anslutningen över IPSEC-VPN till andra sidan.
Såhär ser det ut i kontroll-änden med debug 2:
Code: [Select]
Power ON due to P1.30 high
CP-> Radio ON(Idle)
sipTx: 192.168.1.254 [13000] INVITE 0 [24] CI=19011147@192.168.127.110
duplex: New Audiocoding 111 (24 KHz)
sipRx: 192.168.1.254 [13000] SIP/2.0 401=Unauthorized [24] CI=19011147@192.168.127.110
sipTx: 192.168.1.254 [13000] ACK 0 [24] CI=19011147@192.168.127.110
sipTx: 192.168.1.254 [13000] INVITE 407 [25] CI=19011147@192.168.127.110
duplex: New Audiocoding 111 (24 KHz)
sipRx: 192.168.1.254 [13000] SIP/2.0 180=Ringing [25] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 4
AudioTonePlay, tone: 3
appSipCmdHandler: Sip-status: 0
duplex: New Audiocoding 111 (24 KHz)
New UDP CmdTxPort=13002
sipRx: 192.168.1.254 [13000] SIP/2.0 200=OK [25] CI=19011147@192.168.127.110
rtp enable [192.168.1.254/13001 192.168.1.254/13001]
sipTx: 192.168.1.254 [13000] ACK 0 [25] CI=19011147@192.168.127.110
sipTx: 192.168.1.254 [13000] INFO 0 [26] CI=19011147@192.168.127.110
CP-> Sending 8V: 0 Mute spk: 0
queueExtIOManually, In1=8 In2=32 In0=4
sendExtInputs, In1=8 In2=32 In0=4
sipRx: 192.168.1.254 [13000] INFO 0=unknown [16] CI=19011147@192.168.127.110
Got Radio Info, Len 5, data: '8VOff'
CP-> Panel '8V off' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [16] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
controlUDPMsg, Out1=0 Out2=0 Out0=4
CP-> PTT off, sending RTP now
appSipCmdHandler: Sip-status: 0
CP-> audioQuality=11
duplex: New Audiocoding 111 (24 KHz)
sipRx: 192.168.1.254 [13000] SIP/2.0 200=OK [26] CI=19011147@192.168.127.110
sipRx: 192.168.1.254 [13000] INFO 0=unknown [17] CI=19011147@192.168.127.110
Got Radio Info, Len 4, data: '8VOn'
CP-> Panel '8V on' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [17] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
CP-> PTT off, sending RTP now
sipRx: 192.168.1.254 [13000] INFO 0=unknown [18] CI=19011147@192.168.127.110
Got Radio Info, Len 5, data: '8VOff'
CP-> Panel '8V off' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [18] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
sipRx: 192.168.1.254 [13000] INFO 0=unknown [19] CI=19011147@192.168.127.110
Got Radio Info, Len 4, data: '8VOn'
CP-> Panel '8V on' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [19] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
CP-> PTT off, sending RTP now
sipRx: 192.168.1.254 [13000] INFO 0=unknown [20] CI=19011147@192.168.127.110
Got Radio Info, Len 5, data: '8VOff'
CP-> Panel '8V off' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [20] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
sipRx: 192.168.1.254 [13000] INFO 0=unknown [21] CI=19011147@192.168.127.110
Got Radio Info, Len 4, data: '8VOn'
CP-> Panel '8V on' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [21] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
CP-> PTT off, sending RTP now
sipRx: 192.168.1.254 [13000] INFO 0=unknown [22] CI=19011147@192.168.127.110
Got Radio Info, Len 5, data: '8VOff'
CP-> Panel '8V off' from radio
sipTx: 192.168.1.254 [13000] SIP/2.0 200 [22] CI=19011147@192.168.127.110
appSipCmdHandler: Sip-status: 6
appSipCmdHandler: Sip-status: 0
CP-> Radio/Panel OFF
sipTx: 192.168.1.254 [13000] BYE 0 [27] CI=19011147@192.168.127.110
rtp disable
duplex: New Audiocoding 111 (24 KHz)
sipRx: 192.168.1.254 [13000] SIP/2.0 200=OK [27] CI=19011147@192.168.127.110

Jag tänkte fixa en likadan logg för radio-änden men när jag telnetar dit och aktiverar debug 2 fryser sessionen. Lådan hänger sig och startar sedan om. Kontroll-lådan spelar en ton-sekvens som brukar innebära att numret inte går att nå.

På websidan på radio-lådan står det:
Saved error message:
Data Abort at 0x00003710, called by 0x0000363c

Firmware och sånt i båda ändarna är:
Software   2.88
Bootloader   1.10
Compiler   4.6.2

Om jag ändrar till debug 1 istället för två får jag:
Code: [Select]
duplex: New Audiocoding 111 (24 KHz)
duplex: New Audiocoding 111 (24 KHz)
New UDP CmdTxPort=13002
SIP Saved Call-ID '19011145@192.168.127.110'(2)
duplex: New Audiocoding 111 (24 KHz)
duplex: New Audiocoding 111 (24 KHz)
duplex: New Audiocoding 111 (24 KHz)
New UDP CmdTxPort=13002
SIP Saved Call-ID '19011145@192.168.127.110'(2)
R-> Radio ON requested
rtp enable [192.168.127.110/13001 192.168.127.110/13001]
R-> Connection established, radio ON, audioQuality=11
duplex: New Audiocoding 111 (24 KHz)
R-> Sending '8V is off'
queueExtIOManually, In1=0 In2=0 In0=4
sendExtInputs, In1=0 In2=0 In0=4
Got Radio Info, Len 5, data: '8VOff'
R-> Radio '8V off' from panel
controlUDPMsg, Out1=8 Out2=32 Out0=4
ptt off (delayed)
R-> Sending '8V on'
R-> Radio power ON detected
R-> Sending '8V is off'
R-> Sending '8V on'
R-> Radio power ON detected
ptt off (delayed)
R-> Sending '8V is off'
R-> Sending '8V on'
R-> Radio power ON detected
ptt off (delayed)
R-> Sending '8V is off'
rtp disable
>>>Unknown ICMP-package received, type 3 code 3
>>>Unknown ICMP-package received, type 3 code 3
>>>Unknown ICMP-package received, type 3 code 3
>>>Unknown ICMP-package received, type 3 code 3
>>>Unknown ICMP-package received, type 3 code 3
>>>Unknown ICMP-package received, type 3 code 3

De sista raderna gör allt ännu mer konstigt!

Jag kör en trace på trafiken som går till och från radio-lådans IP. Här är slutet av den:
Code: [Select]
6.712816 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.719543 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.726301 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.732874 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.739472 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.746145 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.752800 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.759564 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.766187 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.768171 192.168.127.110.13000 -> 192.168.1.254.13000: udp 311
6.768408 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.772860 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.773527 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.779520 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.780164 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.786167 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.786790 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.792797 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.793509 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.799490 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.800149 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.806123 192.168.1.254.13001 -> 192.168.127.110.13001: udp 336
6.806774 192.168.127.110 -> 192.168.1.254: icmp: 192.168.127.110 udp port 13001 unreachable
6.813518 192.168.1.254.13000 -> 192.168.127.110.13000: udp 278
6.848688 192.168.1.254.13023 -> 192.168.127.13.62344: psh 23363 ack 844200022
6.849350 192.168.127.13.62344 -> 192.168.1.254.13023: ack 23719

12
Precis. 5060 påverkas av SIP-ALGer. Ska prova från Net1-routern senare och se om jag har samma fenomen där.
Är det OK på den är det troligtvis nått i BBBs nät eller i det switcharna hos mig. Mellan min remoterig-låda och BBB är de en kedja av switchar där BBBs nät är ett eget taggat VLAN

13
Tjena
Har nyligen köpt ett kit för FT-857 som jag har fått fart i.
Jag körde kontroll-sidan i min datorförening. Den kopplade upp direkt till radio-sidan.

Så fort jag kommer hem går det inte alls. Lådan försöker koppla upp men det verkar som att UDP-trafiken från radio-lådan inte kan nå tillbaka till kontroll-lådan.
För att utesluta brandväggen jag kör (pfsense, samma som i min datorförening), kopplade jag in kontroll-lådan direkt mot bredbandsbolaget och även där blir det samma fenomen.
Det bör utesluta min egna utrustning här hemma.

Jag har testat att ändra portar i båda ändarna. Jag kan nå båda lådorna via telnet och HTTP.

Kan BBB ha nått filter aktiverat för att blockera UDP-trafiken?

Allt annat fungerar här hemma. Inga problem med telefoni, spel eller surfande. Jag har kört ett test med analysverktyget netrounds och ser inga paketförluster.


Pages: [1]