44net

44net@mailman.ampr.org

4 participants
3198 discussions

Gateway ip/netmask pair
by Marius Petrescu 23 Feb '12

23 Feb '12

Is it just me or we have a error in the gateway routing table? entry: 44.9.0.1/255.255.255.252 via 207.111.203.194 This gives a invalid subnet/netmak pair and gets ignored by rip44d. Should be either 44.9.0.1/255.255.255.255 or 44.9.0.0/255.255.255.252 73 de Marius, YO2LOJ

12 15

Re: [44net] Gateway ip/netmask pair
by William Lewis 22 Feb '12

22 Feb '12

Well, for starters, it looks like the address you posted here is: 44.9.0.1, and you state belongs to WA6NMF. However, I show no such address on the network. I do show an address for WA6NMF, but it is 44.4.9.1 not 44.9.0.1. wa6nmf IN A 44.4.9.1 wa6nmf-1 IN A 44.4.9.2 wa6nmf-2 IN A 44.4.9.3 wa6nmf-3 IN A 44.4.9.4 Now, I also show the 44.9.x.x as a discontinued range. I also DO NOT show any entries at Fullers for either WA6NMF or for any address starting with 44.9.x.x or any with 44.4.9.x So, I'm curious as to where your entry came from ?? At 02:49 PM 02/22/12, you wrote: >No, I never said it belons to me. >I just got an error regarding that address while checking my routing infos. >It belongs to wa6nmf and should be corrected because it is wrong. > Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

1 0

Re: [44net] Gateway ip/netmask pair
by Marius Petrescu 22 Feb '12

22 Feb '12

No, I never said it belons to me. I just got an error regarding that address while checking my routing infos. It belongs to wa6nmf and should be corrected because it is wrong. From: Daniel Curry [mailto:daniel@danielcurry.net] Sent: Thursday, February 23, 2012 00:41 To: Marius Petrescu Subject: Re: [44net] Gateway ip/netmask pair I found that you do not have 44.9.0.1 register to you. ftp://hamradio.ucsd.edu/pub/amprhosts On 02/22/2012 02:33 PM, Marius Petrescu wrote: Is it just me or we have a error in the gateway routing table? entry: 44.9.0.1/255.255.255.252 via 207.111.203.194 This gives a invalid subnet/netmak pair and gets ignored by rip44d. Should be either 44.9.0.1/255.255.255.255 or 44.9.0.0/255.255.255.252 73 de Marius, YO2LOJ _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net -- Daniel Curry PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92

1 0

strange traffic
by Rob Janssen 22 Feb '12

22 Feb '12

At the moment, I receive a continuous stream of packets like this: Frame 1: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) Arrival Time: Feb 22, 2012 18:05:47.069526000 CET Epoch Time: 1329930347.069526000 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: 118 bytes (944 bits) Capture Length: 118 bytes (944 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:ip:data] Ethernet II, Src: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca), Dst: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d) Destination: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d) Address: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca) Address: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 169.228.66.251 (169.228.66.251), Dst: 80.101.113.129 (80.101.113.129) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 104 Identification: 0x1924 (6436) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 49 Protocol: IPIP (4) Header checksum: 0xc1a8 [correct] [Good: True] [Bad: False] Source: 169.228.66.251 (169.228.66.251) Destination: 80.101.113.129 (80.101.113.129) Internet Protocol, Src: 76.114.219.34 (76.114.219.34), Dst: 169.228.66.251 (169.228.66.251) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 21504 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 512 Time to live: 43 Protocol: IPIP (4) Header checksum: 0x3b1e [incorrect, should be 0x2746] [Good: False] [Bad: True] [Expert Info (Error/Checksum): Bad checksum] [Message: Bad checksum] [Severity level: Error] [Group: Checksum] Source: 76.114.219.34 (76.114.219.34) Destination: 169.228.66.251 (169.228.66.251) Data (64 bytes) 0000 45 00 00 54 00 00 40 00 3e 01 8e 79 2c 3c 2c 0a E..T..@.>..y,<,. 0010 2c 89 29 61 08 00 3d 1d 27 45 41 f6 70 20 45 4f ,.)a..=.'EA.p EO 0020 af 34 02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 .4.............. 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# Data: 45000054000040003e018e792c3c2c0a2c89296108003d1d... [Length: 64] It appears to be an IPIP packet from the gateway, which then contains another IPIP packet sent by 76.114.219.34 to the gateway, which again has another IPIP packet that my trace tool no longer shows. I don't understand why the gateway delivers these packets to me. As it looks like 76.114.219.34 is indeed a valid gateway in the system, I assume a misconfiguration rather than malice for now. But probably it would be better when amprgw just rejected all IPIP traffic that includes another layer of IPIP within it. Rob

2 1

Linux tunnel gateway configuration?
by Brian Kantor 22 Feb '12

22 Feb '12

Does anyone have a step-by-step set of instructions for configuring a Linux host as a tunnel subnet gateway for AMPRNet? I'd like to have a proven list of all the commands that have to be entered to set one up. I think it would be very helpful and I don't have such a document in my archives. Thank you! - Brian (PS: this is the first message through the new mailing list setup; if you encounter any difficulties please let me know.)

7 7

Re: [44net] Linux tunnel gateway configuration? (minor correction in last paragraph)
by Jay Nugent 22 Feb '12

22 Feb '12

Greetings Brian, On Tue, 21 Feb 2012, Brian Kantor wrote: > Does anyone have a step-by-step set of instructions for configuring a > Linux host as a tunnel subnet gateway for AMPRNet? > > I'd like to have a proven list of all the commands that have to be > entered to set one up. > > I think it would be very helpful and I don't have such a document in > my archives. Here is the snippett from the /NOS/AUTOEXEC.NOS where it sets up the TUN0 interface. Below that, I show the output of IFCONFIG and ROUTE on the Linux box, for your reference. In this example, 192.168.0.5 is the address of the Linux ethernet card and 192.168.0.44 is the address of the JNOS application running on Linux. BOTH address "appear" to exist on your LAN as if they were two independent machines. # -------------------------- # - TUN0 Configuration - # -------------------------- # NOTE: Remember to turn on IPv4 Forwarding in the kernel !!!! # echo 1 > /proc/sys/net/ipv4/ip_forward # attach tun tun0 1500 0 # # Whenever any host on your ethernet sends an ARP asking "Who-Has # 192.168.0.44", the ethernet in the Linux box will respond that it knows how # to reach this address. This 'feature' negates the need to assign an Alias # address to the Linux box's Eth0 interface (eth0:44), nor the need to put # anything special in the Linux route table :) # ifconfig tun0 ipaddress 192.168.0.44 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 ifconfig tun0 description "TUN0 to Ethernet" # shell ifconfig tun0 192.168.0.5 pointopoint 192.168.0.44 mtu 1500 up # # Shouldn't be any need to ARP on a Point-to-Point link # so this has been commented out. # Note: The MAC addr would be that of the Linux eth card ##shell arp -s 192.168.0.44 00:11:43:c4:b3:48 pub # echo ***** TUN0 Configuration Complete ***** pause 2 # # All done! # ifconfig eth0 Link encap:Ethernet HWaddr 00:11:43:c4:b3:48 inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::211:43ff:fec4:b348/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:60 errors:0 dropped:0 overruns:0 frame:0 TX packets:54 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14669 (14.3 KB) TX bytes:7099 (6.9 KB) Interrupt:16 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.0.5 P-t-P:192.168.0.44 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:392 (392.0 B) TX bytes:526 (526.0 B) # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.6 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 eth0 On your gateway router remember to port forward (to 192.168.0.44) Telnet, Finger, and any other 'services' you want to reach on your JNOS application from the Internet. I do *not* recomend forwarding SMTP unless you have a solid way to prevent spam from the public Internet getting out onto your RF network. If your JNOS application is running the ENCAP.TXT route table and uses the 'encap' interface, DO NOT PORT FORWARD ANYTHING! Instead, define the 192.168.0.44 ip address of the JNOS application as your "DMZ Host" so that ALL protocols (TCP, IPIP Protocol-4, and others) will be automatically routed to the JNOS application where JNOS'es 'ip access' and 'tcp access' firewall rules will decide what gets through for processing/routing. Hope this helps! --- Jay Nugent WB8TKL o Chair, ARRL Michigan Section "Digital Radio Group" (DRG) [www.MI-DRG.org] () ascii ribbon campaign in /\ support of plain text e-mail +------------------------------------------------------------------------+ | Jay Nugent jjn(a)nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 02:01:01 up 170 days, 8:39, 3 users, load average: 0.07, 0.14, 0.06

1 0

my KA9Q NOS tunnel driver for OpenBSD on i386 and macppc is available
by Isao SEKI - JM1WBB 22 Feb '12

22 Feb '12

Hello gateway operators, A few days ago, I fixed a bug of my KA9Q NOS tunnel driver for OpenBSD for Little Endian CPU and my gateway, 44.129.192.1 returned into ampr.org. That is very light weight and running kernel land. My package is available at "Nostun Project" in my home page, http://gongon.com/JM1WBB/ but I'm sorry documents and patch file are very old... 73, Isao / JM1WBB

1 0

Welcome to the mailing list
by Brian Kantor 16 Feb '12

16 Feb '12

This is the "44Net" mailing list for use by the AMPRNet 44net working group.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net