| |
NL2ZTM > BPQ32 17.10.15 23:58l 258 Lines 10345 Bytes #999 (0) @ WW
BID : 1106_NL3ZTM
Read: GAST
Subj: Fwd: Re: [BPQ32] L3/L4 operation intermittently stuck
Path: DBO595<DBO763<DBX214<CB0ESN<FRB001<NL3ZZE<NL3ZTM
Sent: 151011/2020Z 1106@NL3ZTM.NL3ZTM.ZH.NLD.EU BPQ1.4.64
-------- Doorgestuurd bericht --------
Onderwerp: Re: [BPQ32] L3/L4 operation intermittently stuck
Datum: Sun, 11 Oct 2015 12:58:45 -0400
Van: Tadd Torborg tadd@mac.com [BPQ32] <BPQ32@yahoogroups.com>
Antwoord-naar: BPQ32@yahoogroups.com
Aan: bpq group <BPQ32@yahoogroups.com>
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/17894;_ylc=X3oDMTJyamM4ZWQ1BF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNzg5NARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE0NDQ1ODI3MzA-?act=reply&messageNum=17894>
• 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=X3oDMTJmMDE3Y2RnBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NDQ1ODI3MzA->
• Messages in this topic
<https://groups.yahoo.com/neo/groups/BPQ32/conversations/topics/17884;_ylc=X3oDMTM3ZmhzdDNyBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNzg5NARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE0NDQ1ODI3MzAEdHBjSWQDMTc4ODQ->
(11)
Visit Your Group
<https://groups.yahoo.com/neo/groups/BPQ32/info;_ylc=X3oDMTJmMXFzYzcxBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NDQ1ODI3MzA->
* New Members
<https://groups.yahoo.com/neo/groups/BPQ32/members/all;_ylc=X3oDMTJnYzhwcjYxBF9TAzk3MzU5NzE0BGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxNDQ0NTgyNzMw>
4
Yahoo! Groups
<https://groups.yahoo.com/neo;_ylc=X3oDMTJlMXBoaWJtBF9TAzk3NDc2NTkwBGdycElkAzE1Njk5MTI3BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ0NDU4MjczMA-->
• 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
| |