The amprgw router is now periodically preparing a report of the bad packets that it discards. You can retrieve a copy of this report right next to the statistics report: https://gw.ampr.org/private/pkterrors.txt.
You'll need the same userid and password as for the stats.txt file (same as the one you use to fetch the encap file from the portal.)
It's in gateway and source address order to make finding your own gateway and host in the listing somewhat easier.
Current plan is to update the report every 15 minutes, and restart the tally at midnight Pacific time.
Here are the first few lines (there are currently about 2,300).
Let me know if you have any problems or questions with this. - Brian
Last update at Wed May 3 15:45:00 2017
gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 2.84.96.101 44.154.0.1 9 [ 8] dropped: encap to encap 2.84.96.101 44.154.2.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.3.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.4.1 4 [ 8] dropped: encap to encap 2.84.96.101 44.165.2.3 106 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.225 6 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.232 8 [ 8] dropped: encap to encap 23.30.150.141 23.30.150.141 1326 [19] dropped: non-44 inner source address
On Wed, May 03, 2017 at 03:54:32PM -0700, Brian Kantor wrote:
You'll need the same userid and password as for the stats.txt file (same as the one you use to fetch the encap file from the portal.)
Hint: it's not your callsign nor your portal login. It's the old FTP credentials. If you don't have them, write to me and I'll mail them to you. Obviously I don't want to post them here on the list. - Brian
Hello Brian,
Can I have the login/pass for this please, I never use the encap file allways work with RIP
Thankyou
73 de Pascal
ve2hom
Le 2017-05-03 à 19:09, Brian Kantor a écrit :
(Please trim inclusions from previous messages) _______________________________________________ On Wed, May 03, 2017 at 03:54:32PM -0700, Brian Kantor wrote:
You'll need the same userid and password as for the stats.txt file (same as the one you use to fetch the encap file from the portal.)
Hint: it's not your callsign nor your portal login. It's the old FTP credentials. If you don't have them, write to me and I'll mail them to you. Obviously I don't want to post them here on the list.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Oops; 23.30.150.141 is me. I think I've mitigated it via firewall rules now.
On Wed, May 3, 2017 at 6:54 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ The amprgw router is now periodically preparing a report of the bad packets that it discards. You can retrieve a copy of this report right next to the statistics report: <https://gw.ampr.org/private/pkterrors.txt
.
You'll need the same userid and password as for the stats.txt file (same as the one you use to fetch the encap file from the portal.)
It's in gateway and source address order to make finding your own gateway and host in the listing somewhat easier.
Current plan is to update the report every 15 minutes, and restart the tally at midnight Pacific time.
Here are the first few lines (there are currently about 2,300).
Let me know if you have any problems or questions with this. - Brian
Last update at Wed May 3 15:45:00 2017
gateway inner src #errs indx error type
2.84.96.101 44.154.0.1 9 [ 8] dropped: encap to encap 2.84.96.101 44.154.2.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.3.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.4.1 4 [ 8] dropped: encap to encap 2.84.96.101 44.165.2.3 106 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.225 6 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.232 8 [ 8] dropped: encap to encap 23.30.150.141 23.30.150.141 1326 [19] dropped: non-44 inner source address
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian,
I've reviewed my traffic for the past 48 hours for any destination 44 traffic. I have a few flows that have 44.0.0.0/8 destinations, but they are not encap to encap. The IPs below (I see) that were sent responses via AMPRGW:
HamWAN: 44.25.8.12 * 44.103.0.2 * 44.103.1.2 *
It seems no route existed: 44.225.36.222 *
root@router:~# ip route get 44.255.36.222 from 44.60.44.1 44.255.36.222 from 44.60.44.1 via 169.228.66.251 dev tunl0 table 44 cache
WHEN I CHECKED 5 MINUTES LATER...
root@router:~# ip route get 44.225.36.222 from 44.60.44.1 44.225.36.222 from 44.60.44.1 via 141.75.245.225 dev tunl0 table 44 cache window 840
- Lynwood KB3VWG
71.163.58.163 44.60.44.3 262 [ 8] dropped: encap to enc
It seems I transposed the 2nd octet of the last IP I gave earlier (255 for 225):
root@router:~# ip route get 44.225.36.222 from 44.60.44.1 44.225.36.222 from 44.60.44.1 via 141.75.245.225 dev tunl0 table 44 cache window 840
this route exists - my apologies.
I'm only sending to HamWAN (an 'exception' in my old documentation, which we have programmability worked around).
73,
- Lynwood KB3VWG
Hello Brian.
Just spotted IP address of my JNOS 44.165.2.3 in file:
https://gw.ampr.org/private/pkterrors.txt dated Tue May 9 02:15:01 2017 PDT [-0700]
2.84.96.101 44.165.2.3 79 [ 8] dropped: encap to encap
Although 44.165.2.3 belongs to me I _DON'T_ have any link with 2.84.96.101 gateway and this public IP _ISN'T_ mine either because SV1UY is the owner of this IP.
What's up, please?
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
I don't know the cause of it. The source of the packets seems to be 2.84.96.101, which as you mention is the address of the gateway registered to Demetre, SV1UY. You could write to him at demetre.sv1uy@gmail.com.
The packet dump shows that the encapsulated packets in question were
00:03:20.554371 IP (tos 0x0, ttl 221, id 279, offset 0, flags [none], proto unknown (93), length 276) 44.165.2.3 > 44.154.2.5: ip-proto-93 256
IP protocol 93 is AX.25 over IP. Could there be an AXIP link set up between those two hosts? It wouldn't be working since the packets are misrouted or misaddressed and amprgw is dropping them.
There were also encapsulated UDP packets showing related pairs of addresses:
06:33:55.192282 IP (tos 0x0, ttl 15, id 22444, offset 0, flags [none], proto UDP (17), length 60) 44.165.2.2.40984 > 44.154.0.4.33483: UDP, length 32 06:34:10.761959 IP (tos 0x0, ttl 1, id 35343, offset 0, flags [none], proto UDP (17), length 60) 44.165.2.2.59870 > 44.154.63.1.33440: UDP, length 32
I don't know what this is, as the UDP port numbers seem random. Could it be the old AXUDP linking protocol?
You can look at the actual error packets by downloading file
https://gw.ampr.org/private/errors/2.84.96.101.pcap
and use tcpdump or wireshark to look at them. Perhaps some clue is to be found inside the packet itself. Unfortunately, my tcpdump doesn't know how to decode the (probably) embedded AX.25 packets in the packet payload area. - Brian
On Tue, May 09, 2017 at 11:44:44AM +0200, SP2L Tom wrote:
Just spotted IP address of my JNOS 44.165.2.3 in file: https://gw.ampr.org/private/pkterrors.txt dated Tue May 9 02:15:01 2017 PDT [-0700] 2.84.96.101 44.165.2.3 79 [ 8] dropped: encap to encap Although 44.165.2.3 belongs to me I _DON'T_ have any link with 2.84.96.101 gateway and this public IP _ISN'T_ mine either because SV1UY is the owner of this IP. What's up, please? Best regards.
Tom - SP2L
Brian.
Thank you very much. Will check locally looking more deeper...
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
Brian.
Regarding belows frames...
06:33:55.192282 IP (tos 0x0, ttl 15, id 22444, offset 0, flags [none], proto UDP (17), length (60) 44.165.2.2.40984 > 44.154.0.4.33483: UDP, length 32
Today it was me pinging few addressess from 44.154/18 range... Hi!
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
On Tue, May 9, 2017 at 7:23 AM, Brian Kantor Brian@ucsd.edu wrote:
You can look at the actual error packets by downloading file
https://gw.ampr.org/private/errors/2.84.96.101.pcap
and use tcpdump or wireshark to look at them. Perhaps some clue is to be found inside the packet itself. Unfortunately, my tcpdump doesn't know how to decode the (probably) embedded AX.25 packets in the packet payload area.
Brian,
I downloaded this pcap and opened it in Wireshark. It decodes the embedded AX25 frames and NetRom protocol! This is very cool. Thank you for implementing the pcap format!
Tom KD7LXL
Glad it works! Once I solved the timestamp size problem, it was easy to implement. Thanks again for the suggestion of using pcap format. - Brian
On Tue, May 09, 2017 at 08:40:36AM -0700, Tom Hayward wrote:
I downloaded this pcap and opened it in Wireshark. It decodes the embedded AX25 frames and NetRom protocol! This is very cool. Thank you for implementing the pcap format! Tom KD7LXL
-
Brian Kantor -
Dan Cross -
lleachii＠aol.com -
SP2L Tom -
Tom Hayward -
ve2hom Pascal Lafond