Your ISP is a Cable-based ISP and you've been on the amprnet for quite some time now without any issues. All of a sudden you find you're not getting RIP broadcasts and others can not connect to you even if you manually add routes. You think you've been "dropped" off of amprgate by ARDC, or something may be wrong with amprgate itself. Chances are most likely that if it was, everyone would be hammering away via emails wondering what is going on. With that said it's most likely NOT amprgate, the portal, or RIP broadcasts and in reality it most likely isn't you either. What gives?
Most ISPs these days deploy out, or install at your location when they turn up your circuit, a device typically known as a CPE. This stands for Customer Premise Equipment and usually consists of some sort of a modem, bridge, or router that's designed for use on their network, while allowing you the priviledge of running your own in-home LAN on RFC-1918 space, natted to the global internet through this CPE.
Out of pure frustration now and being informed that RIP broadcasts are indeed being sent to your IP you decide to phone your ISP's tech support to find out if you're somehow being filtered by them. The person at the other end of the line, who is most likely reading off of a script, tells you that they don't filter your LAN. While technically this may be a true and somewhat honest answer to your question keep in mind that you have a lan and a wan interface and a filter of sorts on your WAN interface (the interface directly facing the ISP) most likely would filter your LAN interface depending on how it's configured. Having been on both sides of this coin I can tell you that this is a situation where is the glass half empty or is it half full?
Keep in mind, your ISP is in business to make money and you're someone they see as one to feed their bank. At the same token they're going to do what they can to protect their own network while keeping queries/issues from you to a minimum. Part of how they do this is to try and configure the CPE to deliver what the ISP thinks is maximum preformance with the least amount of maintenance required by their own support staff. This is typical business and a very logical decision. If the CPE can somewhat maintain itself why not program it to do such.
There's a great chance that your LAN/WLAN (wireless network) is forced to use RFC-1918 space (ip blocks set aside as non-routable on the global internet mainly for use on LANs). These IPs to get out to the global internet are network address translated (NAT) as to appear sourced as the public IP on your CPE's ISP facing interface. This makes perfect sense for them to do especially since we're officially out of IPv4 space. One problem however is for each NAT session, a segment of ram is used. If you have a good number of axip/axudp links, this can fill your CPE up pretty quickly.
Using NAT is also a way for the ISP to get more out of a fairly inexpensive piece of gear while making a bigger profit margin off of the consumer. There are some benefits the end user (you) get out of it such as a layer of security, tech support from your ISP, and also the possibility of having your ISP "manage" this device for you. Sometimes when the firmware requires upgrading this management of your CPE happens in your sleep by robot programs.
You were fine to the global 44-net mesh yesterday and anyone within amprnet was able to connect to you without issue but today you wake up and find your links are spotty at best, and you find you've lost some links, rip routing, and other weirdness. You think to yourself that you didn't change a thing so it must be amprgate or the portal - after all it's 44-net related so what else could there be? You look around at your configs and files and see they all look "normal" so it can't be you at all. You have all your ducks in a row so...
You finally call your ISP and they insist they're *not* filtering your lan at all. Now you're beginning to go from concerned to mad - someone is lying to me and I don't know who it is but I'll find out! - you think to yourself. Remember, your ISP can and usually will deploy policy changes to things on their network while you sleep most of the time so there's a 98% chance it is them. Since this change was placed into your CPE (which they own most likely) you have about a 0% chance in getting them to reverse it.
Before we can come up with a fix, we must first understand what's going on so we can somehow either reverse engineer this or engineer around the cause so we get back our original effect. The biggest factor plaguing your ipencap (ip protocol 4) is socket related inside your CPE. But how? The ISP insists they're not filtering me. ARDC hasn't blocked me. What's going on here? The answer really is quite simple. As more bots and worms probe IPs across the internet, and with the limited ram of these inexpensive CPE devices such evil entities can take these devices down and cause ISP call centers to get over worked unnecessarily.
What your ISP does is either turns on or shortens the interval the CPE's internal socket watchdog timer activates. This is an internal routine that causes the CPE to monitor your IP sockets and if it feels it's inactive or invalid to close/block them thus keeping your CPE's ram as clean as possible. It also prohibits any and all inbound traffic to devices on the LAN side of the CPE device. Again this is really for the consumer's benefit. Most consumers aren't on amprnet, and most consumers aren't running ip protocol 4 (ipencap). The downside of this is that this internal watchdog is on the ISP facing interface, it's preset into the firmware, and end users along with the ISP tech support center folks are prohibited from even seeing this within the configuration menus.
Ok so you may see a situation and still don't understand the full scenario here. The watchdog affects inbound not outbound connects whether they be pings, telnet sessions or receiving RIP. If you have axip/axudp links, since you send outbound netrom broadcasts (obs) then that's outbound and you'll have created a temporary link into you from just those sites. The rest of 44/8 can not get to you still via telnet or ping. They can via your direct netrom neighbor for a short time inbetween obs broadcasts.
A way to test this would be for example would be to connect to someone you may have link with and then from them connect to someone on their nodes list and try to ping or telnet back to yourself. If you're "bitten", then the try will fail. This would be because there is no socket being allowed to create within your CPE for ip protocol 4 (ipencap) due to the watchdog prohibiting the inbound request.
Here's a sample test:
Here I try to telnet to VE7ASS from W4MLB-1: n1uro-15@n1uro.ampr.org:/uronode$ c melbrn Trying MELBRN:W4MLB-3...aborts. Virtual circuit established to MELBRN:W4MLB-3 t ve7ass 23 As you see, it's failing. Now I'll get into ve7ass and connect to w4mlb: YVRASS:VE7ASS-7 Area: n1uro Current msg# 0. ?,A,B,C,CONV,D,E,F,H,I,IH,IP,J,K,L,M,N,NR,O,P,PI,R,S,T,U,V,W,X,Z > telnet w4mlb.ampr.org 3694 dns_query: querying server 204.194.232.200 for w4mlb.ampr.org. dns_query: received message length 48, errno 0 response id 31061 (rtt 328 ms) qr 1 opcode 0 aa 0 tc 0 rd 1 ra 1 rcode 0 1 questions: w4mlb.ampr.org. type A class 1 1 answers: w4mlb.ampr.org. 3600 IN A 44.98.16.2 0 authority: 0 additional: Trying... The escape character is: CTRL-T *** connected to 44.98.16.2:3694 (w4mlb.ampr.org:uronode) login: n1uro [URONode v2.6] Welcome n1uro to the w4mlb.ampr.org packet shell. This copy of URONode is located in Melbourne, Brevard Cty, Florida [EL98qb]. Type "?" for commands or H for more detailed help on a command. n1uro@w4mlb.ampr.org:/uronode$ As you see, it works fine because it's an OUTBOUND request. Now I'll try to telnet to ve7ass again: MELBRN:W4MLB-3} Failure with 44.135.160.40: connection timed out t ve7ass 23 MELBRN:W4MLB-3} Socket established to 44.135.160.40:telnet JNOS (ve7ass.ampr.org) Login=call Pass=call login: and it works. Watchdog test verified active. Solutions need to be engaged.
Yes there is hope! Of course there's always more than one way to achieve your goals when dealing with amprnet and/or IP in general. I've tested positively two potential resolutions to this problem when a station is "bitten" by a watchdog. This almost brings us back in some cases where we parallel configs when we were SAFEd (Source Address FilterEd) by our ISPs. The first solution I'll go over is a hardware based solution and may be more efficient for you long term as you will have much better control over your block.
You may have kicking around the house a spare consumer-grade wifi router such as a linksys, netgear, etc that can take a firmware such as DD-WRT/OpenWRT/etc. If you don't, you can find some somewhat decent inexpensive devices on Ebay for under $20 U.S. Dollars that can handle these 3rd party firmwares. Check with these 3rd parties for suggestions they may have. I've had good luck with Cisco/Linksys e2000. They handle 802.11a/b/g/n and it handles DD-WRT and OpenWRT. Others have had success using other devices such as Ubiquity and MicroTik however since I don't use either it'd be unfair of me to report configurations of such to you.
Even though you may be denied access to your CPE device to shut the socket watchdog timer off, most if not all CPEs allow you to put the router into bridge mode. By doing this, you'll bypass the internal watchdog on the ISPs CPE. Keep your consumer-grade device in DHCP mode facing your CPE bridge and you should get a new IP from your ISP. Note: Hopefully you're running some sort of dyndns service! I use ddns.net and for a backup I have a no-ip.org hostname. Configure your wifi as you had it in your CPE so your clients on wifi don't have to change their config. Remember this is your issue not theirs so no need to make them change their configs. Now, reconfigure yourself to be the DMZ within your second router and typically somewhere under the Administration tab is a sub-tab called something like "KeepAlive". This is where the watchdog lives. Simply disable ALL watchdog timers unless you need one to auto-reboot your device.
Log into the amprnet portal and verify your gateway's IP settings. Insure that you get this done prior to the top of the hour or else you may need to wait for the next cycle of the portal to verify your settings and add you to rip. I've seen this take anywhere from 15 minutes to well over an hour. Keep watch on your route table you use for amprnet policy routing to insure you receive RIP. Once you do then you should be all set and others should be able to reach you once again.
Ions ago, we used to be able to simply push our 44-net IP through our ISP almost as a secondary address to our ISP facing interface. Unfortunately human nature is to see something positive and powerful such as the internet and use it for evil purposes such as cracking passwords on large sites or financial institutions for example. They did this by spoofing IPs so to counter act that, ISPs as a rule of thumb made source-address filtering policy on their networks.
Many of the "village elders" on amprnet called this being SAFEd and it forced us to find a solution. K2MF came up with a system later called dgipip by Terry Dawson and a client/server system was developed where the client would send an ID frame to a static host server with a coordinated password and when authenticated the server would allow the client to forward encap frames through it using the client's assigned amprnet block. The client would also have to re-authenticate periodically to let the server know it's still alive and/or if the client's IP changed so it knew how to allow amprnet routing to go to. Unfortunately now with us using policy routing, this solution somewhat is broken but there is a work-around.
If you can find a static amprnet host that would be willing to host your block for you, release your block in the amprnet portal and have your new host append it to his portal settings. You, the client then can default route your amprnet policy routing via your tunnel interface to the server hosting you, and set a cron job to ping them every so often. I'd start at 5 minutes and if that doesn't appear to work out keep lowering it. Some ISP CPEs have excessively aggressive watchdogs which kill sockets under 30 seconds. If you find this is true, then you'll be forced to use the hardware fix solution. The nice thing about using this solution however is that you don't need to worry about RIP, that will be on your host to insure his RIP is working. Of course, if your host goes down for any reason, you'll be dropped from the amprnet as well. Things do happen so patience is a virtue! Also, since chances are your host is doing this free of charge, you really aren't losing anything.
As I mentioned earlier, there's more than one way to achieve your goals with amprnet and here alone we took a situation and found at least 2 solutions for the same problem. There may be more and if so feel free to email me and I'll be most happy to append the solution to this document.