44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] FW: Making Packet Node with Pi ?
by Leon Zetekoff 09 Mar '16

09 Mar '16

I apologize to everyone been extremely busy and other things have cropped up taking my time away from pulling the tnc out. I'll definitely try to get it out this weekend and report back thanks 73 leon On 3/9/2016 7:10 PM, Assi Friedman wrote: > Hi Leon: > How much are you asking for the TNC? I assume this is the model consisting > of the TNC + the 9600 G6RUH card? > Thanks, > Assi kk7kx > > -----Original Message----- > From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On > Behalf Of Leon Zetekoff > Sent: Wednesday, March 02, 2016 4:23 PM > To: 44net(a)hamradio.ucsd.edu > Subject: Re: [44net] Making Packet Node with Pi ? > > (Please trim inclusions from previous messages) > _______________________________________________ > I have a paccomm 9600 which i really never used much way back when. I'd > unload it if anyone wants it. please contact me off list. > > Leon WA4ZLW > > On 3/2/2016 6:43 PM, Jerry Kutche (N9LYA) wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> Yes I have an SCS Tracker and yes it too can do 9600 baud.. >> >> A lot of miss information going on here... >> >> That's two TNCs... Still in production.... Any more probably... >> >> 73 jerry n9lya >> >> -----Original Message----- >> From: 44Net >> [mailto:44net-bounces+n9lya=uronode.n9lya.ampr.org@hamradio.ucsd.edu] >> On Behalf Of Bill Vodall >> Sent: Wednesday, March 2, 2016 6:18 PM >> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> >> Subject: Re: [44net] Making Packet Node with Pi ? >> >> (Please trim inclusions from previous messages) >> _______________________________________________ >>> I'd LOVE a 9K6+++ modem but they just don;t seem to be available. >> SCS TNC tracker (http://www.p4dragon.com/en/Modems.html#widget4) and >> the sound card modes such as DireWolf and UZ7HO now claim to support >> 19,200 so 9600 should be doable. >> >> Bill, WA7NWP >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net >> >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net >

1 0

Re: [44net] Is there raceroutre machine on 44 net available for public ?
by Rob Janssen 09 Mar '16

09 Mar '16

> Even APRS would be useful for folks that have 44net services to share. > (Re-inventing bonjour/ZeroConf....) Perhaps this is a good reason to > revive the HTPP convsers server (IRC clone) and use it for > announcements like the DStar folks do with IRC technology. I think there would be some slightly different approaches: 1. a written announcement like writing "I have this nice webserver" on convers and requiring people to read the discussion there. of course this information will get lost over time as other services are announced there. 2. a more static approach like putting all available services on a WiKi page that can be edited by everyone. (possibly in a hierarchic way with a page linking to other regional pages) 3. an automatic system like bonjour where every active service is regularly announcing itself on the network and some page is dynamically updated when services appear and disappear. It certainly is something that is worthwhile to take up because it is a frequent question when having new users. "what can I find on the net and where" Rob

11 15

Re: [44net] RIP packet loss
by Rob Janssen 09 Mar '16

09 Mar '16

> Subject: > Re: [44net] Is there raceroutre machine on 44 net available forpublic ? > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 03/09/2016 02:37 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I've never found the cause of this; the rip sender would report protocol > buffer overflows and never has. The UCSD network can easily take the > amount of traffic that the rip transmissions constitute, and is not rate > limited, so I am led to the conclusion that the loss must be along the > transit path somewhere. Of course, being UDP inside IP, we don't get > notified of in-transit packet drops so it remains a mystery why this > is/was happening. Well, when you send a few thousand UDP packets from a fast system on a gigabit ethernet it does not really surprise me that there can be drops somewhere. Probably not within the fast infrastructure of a university network, but maybe further along the path. There could be queues on interfaces that are slower or loaded with other traffic and that drop some of the packets. At that time there was an obscure second transmission of the same RIP data and when that was dropped, the situation appeared to improve. The gateway where I was observing the problem is on a 100 Mbit line shared with several other systems, maybe the drops were occurring locally due to some rate limiting in place to achieve fair sharing of the bandwidth. I don't think I observed it on our gigabit connected gateway, that was installed later. You could put a small delay between sending the packets or after each small group of packets. Also when you are sending the series of packets to all the gateways, consider to make the inner loop by gateway and the outer loop by packet of the series, not sending all packets for 1 gateway first and then the series to the next gateway. The small delay could then be in the outer loop, and each gateway receives its packets somewhat spaced. Rob

1 0

amprnet routing
by Rob Janssen 09 Mar '16

09 Mar '16

> For a mesh this information gathering step can not be circumvented. Even if > we change routing protocols, you still need to know your peers BEFORE being > able to set up BGP or OSPF. > And if you know your peers, you can know their subnets, too. So there is > actually no need for a routing protocol running on a limited bandwidth > network, because the information is already there, in your peering data. Way back in the days of the previous packet radio network and NETCHL I started to code a solution for this. I implemented multicast in NETCHL and created a simple info protocol that multicasted information about the local system to address 224.0.1.31 port 1535 (look them up in DNS and /etc/services!) These announcements were sent with a TTL of 5 or so, so the neighborhood in the then existing IP/AX.25/NETROM network learned some details about the nodes, like the sysop call, the frequencies it was operating on, and the subnets it was serving. The info could be displayed when connected to the NETROM. The intention was to create an automatic IP routing protocol from there, and then replace IP-over-NETROM and plain connects over NETROM by an automatically routed IP network and a service to encapsulate plain user AX.25 connects (user1-node1-node2-user2) in TCP/IP connects between the nodes. (replacing NETROM) This never materialized, and in neighboring Germany a network was deployed (Flexnet) that stuck to the AX.25 routing, and it became quite popular. The author was not interested in IP at all. More and more operators wanted to switch to that network so further development on NETCHL was mostly halted. Of course, now this change has been made anyway (the network is IP with AX.25 running on top of it instead of under it), but quite some time has passed... Of course we could again embark on such a project, but there is always the issue of migration to a new method without breaking the whole network in the transition phase. Rob

1 0

Re: [44net] Is there raceroutre machine on 44 net available for public ?
by Rob Janssen 08 Mar '16

08 Mar '16

> 3-rd option is interesting. Just that there will be alot of opposition > from people worrying about 1 ping an hour should some multicast group > announcement and subscription messages appear on the network... No, it would work the other way around! Someone sets up a service on amprnet where services can announce themselves to be in the global directory of services. Anyone running a service who would want to be in that directory sends regular announcements to the central server, and those who do not want traffic simply don't annouce themselves and won't have any unwanted traffic. It can be really simple, any capable PHP or ASP programmer can write this in "one rainy sunday afternoon" as the saying is here. Of course to get it universally accepted is another matter. Design would be like this: Anyone who wants to announce their service makes a cron job that once per day posts a file to the central server (XML, JSON, whatever) using a simple call to wget or curl. The file contains the specification of the local services. It can be called manually whenever the file has been edited for quick update. The central server receives the posts (simple HTTP POST) and parses the data, if valid it creates one or more database records with services and sets the time it (last) received this announcement. The same central server provides an overview page (with search and/or selection options) that just dumps the contents of the database as a table. There is some expiration interval (a small multiple of the post interval, e.g. 3 days) after which records are deleted or no longer shown. This can also be a parameter in the selection. Bottleneck: convince everyone who provides some service on amprnet to write the corresponding XML/JSON file and setting up the cron job. Providing a working script callable by cron (i.e. the wget call with the proper parameters) will help. An indication how to write a properly formatted file and/or a tool to do this will also help. It can be made a part of www.ampr.org, for example. Then we can direct anyone there to lookup the service directory. Rob

2 1

Re: [44net] Is there raceroutre machine on 44 net available for public ?
by Rob Janssen 08 Mar '16

08 Mar '16

> Do you have any way to check connectivity and routing problem without doing at least ping and trace route ? > I dont know ... > Whats the point to put the encap file if you cant use it ? What you have just found out is that a network by itself may be fun to construct but is not very useful on its own. That has always been a weak spot of tunneling amprnet over internet: why would you want to do that, when you can just use internet. When you want to actually use amprnet you need some way to find public services that are of interest. Then you can try to connect those, and assume that the operators have no problem with visitors. That is something different than pinging or tracerouting everything in sight. For example, enter in Google: site:ampr.org hamradio Or some other keywords after that text "site:ampr.org" (without the quotes) That way you will find websites on ampr.org (as far as they are connected to real internet), and you may find interesting pages that tell you about other things available on amprnet. Rob

5 4

Re: [44net] Is there raceroutre machine on 44 net available for public ?
by marius 08 Mar '16

08 Mar '16

WW Converse is actually live and wll. Just more servers than users. Maybe it could be made more useful by association with some other populas service. Marius, YO2LOJ Sent from Samsung tablet. -------- Original message -------- From: Bill Vodall <wa7nwp(a)gmail.com> Date:08/03/2016 01:34 (GMT+02:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Is there raceroutre machine on 44 net available for public ? ... Perhaps this is a good reason to revive the HTPP convsers server (IRC clone) and use it for announcements like the DStar folks do with IRC technology.

1 0

Re: [44net] Is there raceroutre machine on 44 net available for public ?
by Rob Janssen 07 Mar '16

07 Mar '16

> Subject: > Re: [44net] Is there raceroutre machine on 44 net available for public ? > From: > Antonio Querubin <tony(a)lavanauts.org> > Date: > 03/07/2016 08:52 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > You should NOT assume that all gateways actually have the entire mesh encap table loaded. Some only load a partial table to those networks they want to reach. You'd have to check with each gateway operator to verify which encap routes are > actually loaded if you can't reach any of the net-44 nodes behind their gateway. And of course the encap table does not tell you anything about which 44-net address is used by the gateway itself. So there is no way you can check if you can reach the gateway. (even if you would know the address of the gateway there is no guarantee that it will reply to detection attempts) It has already been made clear to mr "Please Advice" that lots of operators do not appreciate what he is doing. Unfortunately, he rarely listens to the advice he is constantly asking for.... Rob

2 1

Misconfiguration of gateway tunnel interfaces
by Rob Janssen 07 Mar '16

07 Mar '16

> Is there a amprnet wiki page with recommendations and notes on just > how to do this? It depends too much on the layout of your network and the equipment and software you are using how to do this. I normally use tshark (terminal version), unfortunately it can only display a condensed version of each packet that does not show how it is tunneled, or a way-to-verbose version where one packet takes up multiple screens full of data. The GUI version 'wireshark' can nicely fold and unfold all levels of detail but of course it is more difficult to run it inside a router or small Linux system used as a router. Rob

2 1

Re: [44net] Misconfiguration of gateway tunnel interfaces
by Steve L 07 Mar '16

07 Mar '16

I just use tcpdump: tcpdump -i eth0 -vvv host amprgw.sysnet.ucsd.edu or ip proto \\icmp tcpdump -vvv -s0 -n proto ipencap > I would recommend amprnet operators starting a network analyzer on your > network > (like wireshark) every time you have made a configuration change, added some > equipment, > or just have a few minutes of time to spend.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net