44net

44net@mailman.ampr.org

3196 discussions

AMPR Gateway down?
by lx1duc＠laru.lu 28 May '14

28 May '14

Good afternoon/morning, I'm unable traceroute from the internet to 44.161.200.11, the trace stops at ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131). Is anybody experiencing similar issues? 73 de Marc, LX1DUC

4 4

Gateways to where?
by kb9mwr＠gmail.com 28 May '14

28 May '14

I have been reading this common thread on the.broadband hamnet forums. "Are there any lists with available tunnel connections?" On the portal, unless noted in the notes area, the only way to really tell is from looking up the geographic area for the listed subnet. This is probably something we should re-think. You shouldn't have to do all that leg work to see what areas have tunnels available. If we can make that easier to determine, I'd like to think more people will find what we are doing here on 44net more useful to them. Back to painful data loss recovery..

3 2

Strange route entry: 44.140.0.0/16
by Marius Petrescu 23 May '14

23 May '14

Just peeked in th RIP broadcasts today: 44.140.0.0/16 via 44.140.0.1 This entry is invalid, since the gateway is in its own subnet and no other entry for 44.140.0.1 exists. Please correct the entry. Marius, YO2LOJ

6 8

Re: [44net] 802.11 link planning
by Steve Wright 21 May '14

21 May '14

On Thu, May 22, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote: > http://www.scc-ares-races.org/mesh/preso/Basic_WiFi_Net_Planning_v140516.pdf That's a really good document. This really needs to be in the wiki, or else no one can find it. It can be dangerous for total newbs to read this, because it suggests the process is fraught with danger, which of course it's not. We all agree that it's actually completely trivial to put up an AP and connect to it from miles away. rmonline is also a good tool to quickly check links for LOS. There is also some Android app as well. http://www.ve2dbe.com/rmonline.html I don't do link calcs any more - there's just no need to. A pair of Nanobridges will work real well over a huge distance provided there is line-of-sight. Really, this stuff is point-and-shoot trivial now. A really important consideration with an 802.11 ham network, is keeping the snake-oil protocols separate from the ones that actually work! Viz, don't run mesh on an AirMax channel. AirMax can push a huge amount of data, even on a busy channel. Advice I'd give to a group of total newbies who want to build a network, is ignore all the tech talk and go buy a 2.4GHz AirMax sector access point, install on a nice high line-of-sight location, and just play with connecting to it from all around the place. There's nothing complicated about it at all. The tricky stuff does come later, but you'll get to that once you see the network up and alive, and your enthusiasm starts to take off. Newbs giving up early because it looks too hard is an avoidable tragedy. Steve ZL1BHD

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 104
by Rob Janssen 21 May '14

21 May '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 103 > From: > Pedro Converso <pconver(a)gmail.com> > Date: > 05/21/2014 12:17 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello Rob et all crew aboard this 44 ship, > > Thanks for taking time to answer, > > If I ping from my jnos> ping pe1chl.ampr.org then ping is answered. > > If I ping from any operating system pe1chl.ampr.org or using remote ping > fromhttps://www.wormly.com/test_remote_ping then ping is not answered. > > Therefore any other function as web, telnet, nntp, etc are not answered or > handled using a PC with any operating system other than a linux with encap. > > This is my concern that also happens to others ampr system including yours. Oh but that is because pe1chl.ampr.org allows only traffic from net-44. It is a NET system and I don't want to open it to the abusers and portscanners. Try sys2.pe1chl.ampr.org or www.pe1chl.ampr.org. Those are Linux systems and you can ping them both from net-44 and from the entire internet. > > In fact a ping to any ampr.org does go to amprgw (169.228.66.251) as shown > by traces, and that happens using any system being or not a linux. > > Question is how to resolve this, and reason of seeking help/advice from > amprnet experts to guide toward finding a solution. > > Best 73, > lu7abf, Pedro Converso What I deduced from your trace was that incoming the packets were encapped as IP-in-IP but outgoing they were not. But maybe it is a characteristic of the way you traced, sometimes those extra encapsulations are not shown in a trace. I think the best solution today is to handle the net-44 routing in Linux and then when you want to run jnos put that behind an extra address that you route locally. Rob

1 0

Re: [44net] 802.11 link planning
by Bryan Fields 21 May '14

21 May '14

I have 3.4 ghz mini pci cards for 8.50 USD each. On May 21, 2014 1:09:52 AM EDT, Michael E Fox - N6MEF <n6mef(a)mefox.org> wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >I haven't seen any commercial equipment available. If you're aware of >any, >can you provide links? > >M > >-----Original Message----- >From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu >[mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of >Tom >Hayward >Sent: Tuesday, May 20, 2014 1:48 PM >To: AMPRNet working group >Subject: Re: [44net] 802.11 link planning > >(Please trim inclusions from previous messages) >_______________________________________________ >On Tue, May 20, 2014 at 12:44 PM, Michael E Fox - N6MEF ><n6mef(a)mefox.org> >wrote: >> >http://www.scc-ares-races.org/mesh/preso/Basic_WiFi_Net_Planning_v140516.pdf > >You might add 3.4 GHz and 5.9 GHz to you list of bands. These are >worth mentioning because they're [US] ham-only and therefore avoid >many common noise sources. > >Tom KD7LXL >_________________________________________ >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 -- Bryan Fields 727-409-1194 http://bryanfields.net

2 1

Re: [44net] 802.11 link planning
by kb9mwr＠gmail.com 21 May '14

21 May '14

I have a nice summary here: http://www.qsl.net/k/kb9mwr/projects/wireless/ham-how-to.html ---- Quote ---- I haven't seen any commercial equipment available. If you're aware of any, can you provide links? M

2 1

802.11 link planning
by Michael E Fox - N6MEF 21 May '14

21 May '14

All, I know some on this list have already rolled out substantial 802.11 outdoor networks. For those who are getting started, this preso might be helpful. I put it together to help new folks in our area understand how all the numbers and terminology fits together. http://www.scc-ares-races.org/mesh/preso/Basic_WiFi_Net_Planning_v140516.pdf At some point, I may follow up with a white paper on how to calculate various items of interest, such as: -- what speed can I expect from a given link? -- what is the minimum antenna gain I need for a given link? -- etc. Michael, N6MEF

2 3

Re: [44net] 44Net Digest, Vol 3, Issue 103
by Rob Janssen 20 May '14

20 May '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] Pings to 44... from Internet not returning > From: > Pedro Converso <pconver(a)gmail.com> > Date: > 05/19/2014 11:26 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello fellows 44 crew > > I have a ping not returning syndrome from my 44 address via Internet. It looks like you are not sending your pings back encapped to 169.228.66.251 You send them directly without encap. That may work if you have a bad ISP, but normally it should not work. You should have separate route tables for net-44 and public-IP traffic and send all traffic originating at net-44 back out via 169.228.66.251. I don't think jnos can do that. It really is outdated, you should consider migrating to Linux where this is no problem. (see earlier recipes provided on this list) Rob

2 1

Pings to 44... from Internet not returning
by Pedro Converso 19 May '14

19 May '14

Hello fellows 44 crew I have a ping not returning syndrome from my 44 address via Internet. >From any ampr system ping to 44.153.0.1 are answered ok, but from internet don't receive answer to pings sent to 44.153.0.1 To try thru Internet I use https://www.wormly.com/test_remote_ping setting 44.153.0.1 as destination for pings. System is an ubuntu 10.03 and jnos2.0i, locally pings returns ok. I made some traces that follows, some related autoexec.nos are at end. Same symptom happens with several 44 systems, pings from Internet don't return. As pings don't return any other tcp function doesn't work either. Any help/guidance/sugestion will be much appreciated. Best 73, lu7abf, Pedro Converso PD: Router: TL-MR3420 DMZ: 44.153.0.10 (IP of my jnos2) ================================================================ Trace of tun0 interfase made by jnos> trace tun0 211 Here can be seen that tun0 receives Echo request encapsulated thru amprgw and Reply with no encapsulation, which originating pinger doesn't receive Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 68 63 95 00 00 27 04 16 84 a9 e4 42 fb E..hc...'...)dB{ 0010 2c 99 00 01 45 00 00 54 33 75 40 00 26 01 5a 3a ,...E..T3u@.&.Z: 0020 b8 48 e2 17 2c 99 00 01 08 00 f1 bb e6 48 00 01 8Hb.,.....q;fH.. 0030 2e 5d 7a 53 00 00 00 00 ab 76 0d 00 00 00 00 00 .]zS....+v...... 0040 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0050 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0060 30 31 32 33 34 35 36 37 01234567 Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 68 63 95 00 00 27 04 16 84 a9 e4 42 fb E..hc...'...)dB{ 0010 2c 99 00 01 45 00 00 54 33 75 40 00 26 01 5a 3a ,...E..T3u@.&.Z: 0020 b8 48 e2 17 2c 99 00 01 08 00 f1 bb e6 48 00 01 8Hb.,.....q;fH.. 0030 2e 5d 7a 53 00 00 00 00 ab 76 0d 00 00 00 00 00 .]zS....+v...... 0040 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0050 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0060 30 31 32 33 34 35 36 37 01234567 Mon May 19 16:36:37 2014 - tun0 sent: IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP ICMP: type Echo Reply id 58952 seq 1 0000 45 00 00 54 71 c7 00 00 af 01 d2 e7 2c 99 00 01 E..TqG../.Rg,... 0010 b8 48 e2 17 00 00 f9 bb e6 48 00 01 2e 5d 7a 53 8Hb...y;fH...]zS 0020 00 00 00 00 ab 76 0d 00 00 00 00 00 10 11 12 13 ....+v.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 ======================================================================= Trace of encap interfase made by jnos> trace encap 211 Here can be seen that encap interfase receives echo req but don't answer Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 54 33 75 40 00 26 01 5a 3a b8 48 e2 17 E..T3u@.&.Z:8Hb. 0010 2c 99 00 01 08 00 f1 bb e6 48 00 01 2e 5d 7a 53 ,.....q;fH...]zS 0020 00 00 00 00 ab 76 0d 00 00 00 00 00 10 11 12 13 ....+v.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 2 0000 45 00 00 54 33 76 40 00 26 01 5a 39 b8 48 e2 17 E..T3v@.&.Z98Hb. 0010 2c 99 00 01 08 00 38 ce e6 48 00 02 2f 5d 7a 53 ,.....8NfH../]zS 0020 00 00 00 00 6f 63 01 00 00 00 00 00 10 11 12 13 ....oc.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 3 0000 45 00 00 54 33 77 40 00 26 01 5a 38 b8 48 e2 17 E..T3w@.&.Z88Hb. 0010 2c 99 00 01 08 00 c7 a0 e6 48 00 03 2f 5d 7a 53 ,.....G fH../]zS 0020 00 00 00 00 dd 8f 04 00 00 00 00 00 10 11 12 13 ....]........... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 ======================================================================= Related autoexec.nos commands to routes & interfaces hostname lu7abf.ampr.org. ip address 44.153.0.1 ax25 mycall lu7abf attach tun tun0 1500 0 ifconfig tun0 ipaddress 44.153.0.10 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 shell ifconfig tun0 44.153.0.3 pointopoint 44.153.0.10 mtu 1500 up shell route add 44.153.0.1 gw 44.153.0.3 tun0 shell sudo arp -sD 44.153.0.10 eth0 pub shell echo 0 > /proc/sys/net/ipv4/conf/tun0/rp_filter # disable arp_filter shell echo 1 > /proc/sys/net/ipv4/ip_forward # enable ip_forward shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 4 \-j DNAT --to 44.153.0.1 shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 94 \-j DNAT --to 44.153.0.1 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 94 shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 23 \-j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 6300 \-j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A PREROUTING -d lu7abf.org.ar -p tcp --dport 6300 \-j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -j MASQUERADE shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.10/32 -o eth0 -j MASQUERADE ifconfig encap ip 44.153.0.1 ifconfig encap mtu 1500 ifconfig encap netmask 0xffffffff ifconfig encap broadcast 255.255.255.255 ifc encap descript "IPIP Encapulation interface" arp eaves tun0 on arp eaves encap on arp poll tun0 on arp poll encap on arp maxq 20 route addprivate default tun0 44.153.0.3 route add 44.153.0.1 tun0 44.153.0.10 route add 44.153.0.2 tun0 44.153.0.10 route add 44.153.0.3 tun0 44.153.0.10 ========================================================

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net