| |
NL2ZTM > BPQ32 23.10.15 21:32l 327 Lines 13304 Bytes #999 (0) @ WW
BID : 1940_NL3ZTM
Read: GAST
Subj: Fwd: Re: [BPQ32] L3/L4 operation intermittently stuck
Path: DBO595<BX0RBL<DBX233<CB0ESN<FRB001<NL3ZZE<NL3ZTM
Sent: 151019/1559Z 1940@NL3ZTM.NL3ZTM.ZH.NLD.EU BPQ1.4.64
-------- Doorgestuurd bericht --------
Onderwerp: Re: [BPQ32] L3/L4 operation intermittently stuck
Datum: Sun, 18 Oct 2015 19:18:16 -0400
Van: Tadd Torborg tadd@mac.com [BPQ32] <BPQ32@yahoogroups.com>
Antwoord-naar: BPQ32@yahoogroups.com
Aan: bpq group <BPQ32@yahoogroups.com>
The event occurred again. I have not taken action to fix it. None of
the setup or versions has changed. Here is the data
Connected to TelnetServer
r r
TADD:KA2DEW-2} Routes
> 1 NC4FG-2 200 9!1262 46 3% 0 0 23:08 3 200
> 2 KM4DVE-2 200 3! 175 2 1% 0 0 23:10 0 199
> 3 KM4IFU-2 200 5! 926 15 1% 0 0 23:11 0 189
> 4 KM4IFV-2 200 6!1135 59 5% 0 0 23:11 0 200
l
TADD:KA2DEW-2} Links
NC4FG-2 KA2DEW-2 S=5 P=1 T=3 V=2
KM4IFV-2 KA2DEW-2 S=5 P=4 T=3 V=2
KM4IFU-2 KA2DEW-2 S=5 P=3 T=3 V=2
KM4DVE-2 KA2DEW-2 S=5 P=2 T=3 V=2
u
TADD:KA2DEW-2} G8BPQ Network System 6.0.10.16 for Linux (824)
TNC Uplink Port 32/1(KA2DEW) <--> Host01(CROWD:KA2DEW-9)
TNC Uplink Port 32/2(KA2DEW)
Circuit(NATHAN:KM4DVE-2 KM4DVE) <--> Host02(CROWD:KA2DEW-9)
TNC Uplink Port 32/3(KA2DEW)
stat
TADD:KA2DEW-2}
Uptime (Days Hours Mins) 03:22:52
Semaphore Get-Rel/Clashes 1 429612
Buffers:Max/Cur/Min/Out/Wait 828 824 807 0 0
Known Nodes/Max Nodes 13 200
L4 Connects Sent/Rxed 4 0
L4 Frames TX/RX/Resent/Reseq 2324 4810 284 0
L3 Frames Relayed 222
Port 01 Port 02 Port 03 Port 04 Port 32
L2 Frames Digied 0 0 0 0 0
L2 Frames Heard 7647 5420 6256 7400 0
L2 Frames Rxed 5994 3581 4455 5666 676
L2 Frames Sent 8378 5589 6473 7918 99
L2 Timeouts 557 216 154 138 0
REJ Frames Rxed 0 0 0 2 0
RX out of Seq 2 2 0 0 0
L2 Resequenced 0 0 0 0 0
Undrun/Poll T/o 0 0 0 0 0
RX Overruns 0 0 0 0 0
RX CRC Errors 1 1 0 2 0
FRMRs Sent 0 1 0 0 0
FRMRs Received 0 0 0 0 0
Frames abandoned 0 0 0 0 0
Link Active % 0 0 0 0 0 0 0 0 0
Tadd Torborg
tadd@mac.com <mailto:tadd@mac.com>
> On Oct 11, 2015, at 12:58 PM, Tadd Torborg tadd@mac.com
> <mailto:tadd@mac.com> [BPQ32] <BPQ32@yahoogroups.com
> <mailto:BPQ32@yahoogroups.com>> wrote:
>
> John,
>
> yes, there is a full correlation between the R R queued packets and
> the links having issues. At least from the last time the issue
> occurred. I haven’t seen it since I did that movie. I did a KILL on
> the linbpq after that and after it started up again I haven’t seen the
> problem happen.
>
> The queued packets count in R R goes up when I type packets to be
> sent. I’m not sure if it goes up when I try to connect.
>
> I’ll do the L command the next time the issue presents as well as R R,
> and then try connecting and watching R R and L, and etc.. .
>
> I had a program running on the Raspberry PI which requires an RR/Info
> frames sent/increase every 10 minutes on every dedicated link with
> qual > 70. All of our manually entered links have a qual of 190 or
> 200. If the program doesn’t see an /Info frames sent/ increase since
> 10 minutes ago, it connects across the link, gets the connect text,
> and then sends control C, d<return>. If it doesn’t complete any
> task in 60 seconds, it sends it sends control C, d<return>. If at
> the start of 10 minutes the host port is connected, it sends control
> C, d<return>. I stopped that program after the issue started, before
> I did the movie. Several of the other nodes are also running that
> program. If the issue does not re-occur for a few days, I’ll try
> turning that program on again. The purpose of the program is to get
> some/info frames sent/ and/info frames retransmitted/values for R R so
> we can determine the reliability of the links. The program does a
> delta on the two numbers every hour on both ends of every link from
> the node running the program and saves that on the PI for later
> retrieval. I also wrote a program that accepts an incoming connect
> from the node to “PERFö and dumps out the last 24 hours worth of link
> qualities. For the moment our network is only used by a few people so
> without the program it isn’t really obvious how well the links work.
>
> Right now we have a total of 11 nodes and about 5 daily participants,
> at most 9 total participants. 3 of the nodes are owned and maintained
> by me. We have a total of 26 radios with TNC-PIs on-line in the
> network, only 20 of which are part of active links. 4 others are
> waiting for other nodes to come on-line and 2 are from planning on
> nodes that never happened. There are 10 more nodes that are not fully
> assembled, or are presently outside the range of our network.
>
> I wonder if my performance and artificial load program is doing
> something bad? It uses the host interface as an emulated TNC. You
> can see that set-up in the config file.
>
> Tadd Torborg
> tadd@mac.com <mailto:tadd@mac.com>
>
>
>
>
>> On Oct 11, 2015, at 11:29 AM, 'John Wiseman'john.wiseman@cantab.net
>> <mailto:john.wiseman@cantab.net>[BPQ32] <BPQ32@yahoogroups.com
>> <mailto:BPQ32@yahoogroups.com>> wrote:
>>
>>
>> Tadd,
>>
>> I think the R R output is the clue, but that is actually showing
>> packets queued at level 2 to go over the node-node connection. I
>> assume the nodes you have trouble connecting with are the ones
>> showing queued frames, and it would be useful to confirm if the count
>> goes up each time you try to make a connection.
>>
>> This leaves the question of why is the L2 connection stuck. What does
>> the L command show?
>>
>> 73, John
>>
>> ------------------------------------------------------------------------
>>
>> *From:*BPQ32@yahoogroups.com
>> <mailto:BPQ32@yahoogroups.com>[mailto:BPQ32@yahoogroups.com]
>> *Sent:*11 October 2015 02:15
>> *To:*bpq group
>> *Subject:*[BPQ32] L3/L4 operation intermittently stuck
>>
>> I’m having some difficulty suddenly on one of my Raspberry PI/TNC-PI/
>> pilinbpq nodes. It gets into a mode where uplink/downlink traffic
>> in and out works great on all ports but circuit traffic from and to
>> other g8bpq nodes gets hung up and appears to be not working. It is
>> actually working but can be delayed by many minutes. You can see the
>> stuck packets in the R R response — see below. Perhaps L4 is waiting
>> to time-out and then will work again? I never see the packets go
>> through until they finally do several minutes later. This issue
>> showed itself after I RESET the Raspberry PI attempting to make the
>> problem go away. It came back within 11 hours of the reset, maybe
>> sooner. It isn’t consistent but once the issue starts, it never
>> fully clears. Perhaps I could have fixed it by killing pilinbpq and
>> restarting it or some other big manual something. I’m hoping
>> somebody can point to this and tell me where I was stupid.
>>
>> I’m running pilinbpq 6.0.10.16 April 2015
>>
>> Raspberry PI 2 quadcore
>>
>> I have my cfg file and a copy of the Monitor traffic from BPQtermTCP
>> and also a Quicktime movie watching BPQtermTCP as the bug is
>> demonstrated.
>>
>> The*sysinfo*file has linux versions, CPU identification, uptime,
>> installed packages, usb devices, and other useful information.
>>
>> The logs and whatnot are here:
>>
>> http://torborg.com/nodeproblem/nb_bpq32.cfg
>>
>> http://torborg.com/nodeproblem/nb_monitor_log.txt
>>
>> http://torborg.com/nodeproblem/nb.mov
>>
>> http://torborg.com/nodeproblem/nb_sysinfo.txt
>>
>> As I’m typing this, this is just a few minutes after i closed the
>> movie and after I took the monitor log, I can get L4/L3 circuit
>> connects to NATHAN:km4dve-2 and JENRET:km4ifv-2, ports 4 and 2. But
>> not to FIN:nc4fg-2 or ERECH:km4ifu-2, ports 1 and 3. But I can get
>> connects to any of them by connecting to nodename dash number. Ok.
>> after a couple of minutes I finally got the connect acknowledge and
>> info text from FIN and ERECH. This has to have something to do with
>> L4 timeout. That’s the only thing I can think of that is set that
>> long. L4TIMEOUT=180 in the cfg. could that be the 26 resent? ok.
>> I’m convinced that this could be it. Why is this happening? Why
>> those particular ports? We’re on very quiet channels. Only 2 users
>> per frequency. The bpq32.cfg for the 4 ports is almost identical.
>> Should be different only in the I2C address #. The TNC-PI could be
>> different versions but I don’t know how to query those.
>>
>> See STATs result below in this email.
>>
>> Thanks for any input!
>>
>> TADD:KA2DEW-2} Routes
>>
>> > 1 NC4FG-2 200 5! 264 8 3% 0 0 00:57 *6 200 *
>>
>> > 2 KM4DVE-2 200 5! 12 1 8% 0 0 00:58 0 199
>>
>> > 3 KM4IFU-2 200 5! 136 7 5% 0 0 01:00 *7 189*
>>
>> > 4 KM4IFV-2 200 1! 149 12 8% 0 0 00:58 0 200
>>
>> stat
>>
>> TADD:KA2DEW-2}
>>
>> Uptime (Days Hours Mins) 00:11:21
>>
>> Semaphore Get-Rel/Clashes 1 50303
>>
>> Buffers:Max/Cur/Min/Out/Wait 828 820 803 0 0
>>
>> Known Nodes/Max Nodes 10 200
>>
>> L4 Connects Sent/Rxed 9 0
>>
>> L4 Frames TX/RX/Resent/Reseq 353 767 26 0
>>
>> L3 Frames Relayed 6
>>
>> Port 01 Port 02 Port 03 Port 04 Port 32
>>
>> L2 Frames Digied 0 0 0 0 0
>>
>> L2 Frames Heard 1048 423 851 856 0
>>
>> L2 Frames Rxed 907 272 701 708 233
>>
>> L2 Frames Sent 1152 443 919 923 145
>>
>> L2 Timeouts 88 12 61 25 0
>>
>> REJ Frames Rxed 0 0 0 0 0
>>
>> RX out of Seq 0 0 1 0 0
>>
>> L2 Resequenced 0 0 0 0 0
>>
>> Undrun/Poll T/o 0 0 0 0 0
>>
>> RX Overruns 0 0 0 0 0
>>
>> RX CRC Errors 0 0 0 0 0
>>
>> FRMRs Sent 0 0 0 0 0
>>
>> FRMRs Received 0 0 0 0 0
>>
>> Frames abandoned 0 0 0 0 0
>>
>> Link Active % 0 0 0 0 0 0 0 0 0 0
>>
>> Thanks
>>
>> *Tadd / KA2DEW*
>>
>> *tadd@mac.com <mailto:tadd@mac.com>*
>>
>> *Raleigh**NC** FM05pv*
>>
>> *“Packet networking over ham radio":
>> http://tarpn.net/t/packet_radio_networking.html*
>>
>>
>
>
__._,_.___
------------------------------------------------------------------------
Posted by: Tadd Torborg <tadd@mac.com>
------------------------------------------------------------------------
Reply via web post
<https://groups.yahoo.com/neo/groups/BPQ32/conversations/messages/17982;_ylc=X3oDMTJyZTkxMHZoBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNzk4MgRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE0NDUyMTAzMDM-?act=reply&messageNum=17982>
• Reply to sender
<mailto:tadd@mac.com?subject=Re%3A%20%5BBPQ32%5D%20L3%2FL4%20operation%20intermittently%20stuck>
• Reply to group
<mailto:BPQ32@yahoogroups.com?subject=Re%3A%20%5BBPQ32%5D%20L3%2FL4%20operation%20intermittently%20stuck>
• Start a New Topic
<https://groups.yahoo.com/neo/groups/BPQ32/conversations/newtopic;_ylc=X3oDMTJmamNrNWw0BF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NDUyMTAzMDM->
• Messages in this topic
<https://groups.yahoo.com/neo/groups/BPQ32/conversations/topics/17884;_ylc=X3oDMTM3YWRpcjlxBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNzk4MgRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE0NDUyMTAzMDMEdHBjSWQDMTc4ODQ->
(28)
------------------------------------------------------------------------
Check out the automatic photo album with 2 photo(s)
<https://groups.yahoo.com/neo/groups/BPQ32/photos/photomatic/1116021444;_ylc=X3oDMTE4M3R1OW82BF9TAzk3MzU5NzE0BGNmOQNQSE9UT01BVElDBHNlYwNtZWdhcGhvbmU->
from this topic.
null.jpg rows.jpg
<https://groups.yahoo.com/neo/groups/BPQ32/photos/photomatic/1116021444;_ylc=X3oDMTE4M3R1OW82BF9TAzk3MzU5NzE0BGNmOQNQSE9UT01BVElDBHNlYwNtZWdhcGhvbmU->
------------------------------------------------------------------------
Visit Your Group
<https://groups.yahoo.com/neo/groups/BPQ32/info;_ylc=X3oDMTJmdnNwaWF1BF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NDUyMTAzMDM->
* New Members
<https://groups.yahoo.com/neo/groups/BPQ32/members/all;_ylc=X3oDMTJnN3ExaTQwBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxNDQ1MjEwMzAz>
4
Yahoo! Groups
<https://groups.yahoo.com/neo;_ylc=X3oDMTJlYWt2ZHVyBF9TAzk3NDc2NTkwBGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ0NTIxMDMwMw-->
• Privacy <https://info.yahoo.com/privacy/us/yahoo/groups/details.html>
• Unsubscribe
<mailto:BPQ32-unsubscribe@yahoogroups.com?subject=Unsubscribe> • Terms
of Use <https://info.yahoo.com/legal/us/yahoo/utos/terms/>
..
__,_._,___
Lese vorherige Mail | Lese naechste Mail
| |