44net

44net@mailman.ampr.org

1 participants
3192 discussions

need help in AMPRGW statistics PCAP decode (gateway errors)

by R P

I get the following error in the statistic file of amprgate 5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address when i look on the PCAP file here is what I see #1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20 #2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20 #3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20 #4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20 #5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20 #6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20 #7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20 #8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20 #9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20 #10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20 #11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20 #12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20 #13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20 #14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20 #15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20 inside the PCAP here is what I see Frame 1: 20 bytes on wire (160 bits), 20 bytes captured (160 bits) Encapsulation type: Raw IP (7) Arrival Time: May 29, 2017 08:59:04.652285000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1496041144.652285000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 20 bytes (160 bits) Capture Length: 20 bytes (160 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: raw:ip] Raw packet data Internet Protocol Version 4, Src: 169.228.66.251, Dst: 192.168.1.180 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 20 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: IPIP (4) Header checksum: 0x0caa [validation disabled] [Good: False] [Bad: False] Source: 169.228.66.251 Destination: 192.168.1.180 [Source GeoIP: La Jolla, CA, United States, AS7377 University of California, San Diego, 32.880699, -117.235901] [Source GeoIP City: La Jolla, CA] [Source GeoIP Country: United States] [Source GeoIP AS Number: AS7377 University of California, San Diego] [Source GeoIP Latitude: 32.880699] [Source GeoIP Longitude: -117.235901] [Destination GeoIP: Unknown] Collapse Tree I dont understand what is the problem May anyone help ? Thank Forward Ronen - 4Z4ZQ

8 years, 11 months

PCAP viewer ?

by R P

Hi Someone know if there is somewhere on the net something that (web page) can view PCAP file ? If not is there any Software that doesn't need to be installed (unlike WireShark) for PC ? Thanks for Any info Ronen - 4Z4ZQ

8 years, 11 months

Re: [44net] MNDP packets

by Rob Janssen

> there have only been 8 hosts sending broadcast destination packets Maybe some have turned this off (easy to do) because they are considered errors now. > I don't know if it would be worth the effort to decode them into a text > file since they are already available for download. > What information is in them that might be of general interest? Well, as also suggested by Lynwood, these packets (and others) can be used to maintain a table of software in use, and can be helpful when there is some problem that appears to affect part of the gateways, but it is not immediately clear what they have in common. Rob

8 years, 11 months

message to all gateway operators

by Brian Kantor

The following message is being queued for email delivery to everyone registered on the portal as operating a gateway. - Brian -------------------------------------------------------------------- From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet Gateway Operators:; Subject: AMPRNet - Important notice regarding your gateway system Hello. You are receiving this email because you are registered with portal.ampr.org as operating an IPIP encapsulating gateway, and there are changes coming that will affect the operation of your gateway. We are replacing the equipment at the UCSD Internet-AMPRNet gateway with a newer, more capable device. In the process, the new equipment will be assigned a NEW IP ADDRESS. You will have to make changes in YOUR gateway configuration for your gateway to continue functioning. The new equipment is already in service as amprgw.ucsd.edu and is on IP address 169.228.34.84. This replaces the old equipment, known as amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. What you have to do to maintain the operability of your gateway: 1. You must change the outgoing destination address of your gateway from 169.228.66.251 to 169.228.34.84. You may do this immediately; the new equipment at UCSD is already operational. 2. You must allow packets from the new address, 169.228.34.84, into your gateway router software configuration. If you are running with a firewall, you must open a new path through it to your equipment. Packets (RIP44 transmissions) are already being sent to you from this address. 3. You must continue to accept packets from the old address, 169.228.66.251, for a period of a few weeks as the changeover is being made. After a few weeks, packets will stop coming from that address and you may remove permission for them to enter your firewall, if you have one. These are simple changes, involving editing a few configuration parameters, but because there are so many different types of gateway in operation on AMPRNet, how to make these changes cannot be detailed here. You may find more information regarding your particular configuration on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion mailing list, which you should join if you are not already a subscriber. Best wishes and 73, - Brian

8 years, 11 months

ampr-ripd 2.1.1 bugfix released

by Marius Petrescu

Hello everyone, Due to an cut instead of copy /paste error, there was a wrong tunnel interface index detection (it always got the last interface in the system). So here the a correted version of ampr-ripd (2.1.1) with the fix. Changelog: - Fixed a tunnel interface detection error - No functional changes Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.1.tgz Have fun, Marius, YO2LOJ

8 years, 11 months

Re: [44net] AMPRNet - Important notice regarding your gateway system

by jerome schatten

As regards preparing a jnos system: http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm gives a 404 What port will the new gateway ip nee? Still 520 udp? Thanks, jerome - ve7ass > On May 28, 2017, at 20:56, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > Hello. You are receiving this email because you are registered with > portal.ampr.org as operating an IPIP encapsulating gateway, and there > are changes coming that will affect the operation of your gateway. > > We are replacing the equipment at the UCSD Internet-AMPRNet gateway > with a newer, more capable device. In the process, the new equipment > will be assigned a NEW IP ADDRESS. You will have to make changes in > YOUR gateway configuration for your gateway to continue functioning. > > The new equipment is already in service as amprgw.ucsd.edu and is on > IP address 169.228.34.84. This replaces the old equipment, known as > amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. > > What you have to do to maintain the operability of your gateway: > > 1. You must change the outgoing destination address of your gateway > from 169.228.66.251 to 169.228.34.84. You may do this immediately; > the new equipment at UCSD is already operational. > > 2. You must allow packets from the new address, 169.228.34.84, into > your gateway router software configuration. If you are running with > a firewall, you must open a new path through it to your equipment. > Packets (RIP44 transmissions) are already being sent to you from > this address. > > 3. You must continue to accept packets from the old address, > 169.228.66.251, for a period of a few weeks as the changeover is being > made. After a few weeks, packets will stop coming from that address > and you may remove permission for them to enter your firewall, if you > have one. > > These are simple changes, involving editing a few configuration > parameters, but because there are so many different types of gateway in > operation on AMPRNet, how to make these changes cannot be detailed here. > You may find more information regarding your particular configuration > on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion > mailing list, which you should join if you are not already a subscriber. > > Best wishes and 73, > - Brian > .

8 years, 11 months

ampr-ripd 2.1 released

by Marius Petrescu

Hello everyone, I released a new version of ampr-ripd (2.1) with fixes and additions. Changelog: - Fixed a segfault when using the -F option - Added the possibility to use interface names for the -g option - Interface used for raw RIP forwarding restarts on interface error Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.tgz Have fun, Marius, YO2LOJ

8 years, 11 months

Latency in various protocoles

by R P

Im experimenting two net cameras on the AMPRNET One is http streaming the other is RTSP streaming The http uses tcp port 80 the rtsp uses udp (dont remember the port now ) The http replace photo every 250 MS (i assume after it get ACK and then send the next image) ( i see about 4 frames per second) and make a traffic of about 1000 kbit/sec the RTSP send photos in about 10 frames per second and produce traffic of about 500-800 Kbit sec all this over the amprNet May someone explain this ? how come that the RTSP photo is like movie and the http is 4 frames per second (of course that if i view the http camera direct on the net i see the 10 frames per second i set the camera for) And why i tell you all of this ? Because i wonder how a DMR repeater connection will work on the amprNet ... If i can see in RTSP video without problems or frame loss should a VOIP (or more exact) data stream of the DMR work ? after all it is less data .... Is there anyone that can light my eyes on the subject ? Regards Ronen - 4Z4ZQ

8 years, 11 months

unreachable gateways and hosts

by Brian Kantor

I'm experimenting with a new technique in the routing daemon on amprgw: if during a send to a gateway, the router gets certain ICMP UNREACHABLE packets from the gateway it's sending to, it drops the host or gateway from the routing table for a time. This has the effect that if a gateway tells us that they don't want packets from us by means of sending us a HOST or NET unreachable ICMP response, we'll stop sending to them for a while. Specifically, PORT UNREACHABLE is ignored. We don't route based on ports. Any of the various HOST UNREACHABLE packets will defer just the one destination host that was being sent to from the routing table; any of the NET UNREACHABLE or PROTOCOL UNREACHABLE packets will defer the subnet from the routing table. The deferral period is currently set to 15 minutes. Watching this happen, one can observe that every 15 minutes, there are a number of hosts and a subnet or two deferred out of the table as packets are sent to them and rejected by the gateways. The number added to the deferral list drops in rate as time goes on. When a gateway changes its address, it is immediately removed from the deferral list. As with the ICMP response suppressing sending RIP transmissions, the purpose of this is to not bombard gateways with packets they don't want and aren't going to deliver anywhere. This is especially important with the number of dynamic gateways we have, where a change in the gateway address may wind up sending IPIP packets to an innocent host that has inherited the gateway's old address. Packets to unreachable destinations are dropped; we don't send UNREACHABLES ourselves. (With all the backscatter and probes, we'd be sending a LOT of them.) We're trying to be good net neighbors. - Brian This is what the log entries look like: May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.104 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.236 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.4 deferred May 28 03:54:37 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 97.84.0.85: subnet 44.102.132.0/24 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.153 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:42 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 40.143.112.188: subnet 44.88.8.32/28 deferred May 28 03:54:43 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 216.161.250.190: host 44.22.128.10 deferred May 28 03:54:44 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.102 deferred May 28 03:54:45 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 78.226.112.146: host 44.151.67.67 deferred

8 years, 11 months

icmp redirects to the new router

by Brian Kantor

On Fri, May 26, 2017 at 04:04:24PM -0700, David Ranch wrote: > Hey Brian, > What about configuring an ICMP direct on the old IP to point to the new IP? > --David > KI6ZHD Well, after thinking about it a bit and reading the relevant RFCs, I thought I'd give it a try and wrote some code in the router daemon to do this. Unfortunately, the FreeBSD kernel prohibits a user-space process from sending ICMP Redirects - you get 'Permission denied' errors when you attempt to write one to the outgoing ICMP socket. Too bad, it would have been an interesting experiment. Maybe there's some way to fiddle the routing table so that the kernel itself sends them. I'll look into it, but a quick peek into the kernel source suggests it's not doable. - Brian

8 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net