> Approximately two echo-requests are received every 2-5 minutes.
I would not notice them in the 2 megabits/second of crap coming in all day...
And certainly not worry.
Rob
Hello,
I'm trying to configure my gateway to 44 net on my pfsense FW.
I configure GRE tunnel:
Remote tunnel endpoint IP address:169.228.66.251
Local tunnel IP address: 44.138.2.254 (my segment is 44.138.2.0 )
Remote tunnel IP address: 44.0.0.0/8
Mobile encapsulation: check (also try to unchecked)
The firewall is open but i cannot ping any address on 44 net.
any idea?
Best Regards,
Tal
4z7tal
Since we are trying to tackle connectivity problems a lot of times, could you please enable ICMP replies on your gateways, at least for other 44net requestors?
It will certainly not ruin the gateway’s safety and security and would help a lot other OMs.
Tnx,
Marius, YO2LOJ
Hi,
I have tried to put my gateway in a new box - my tp-link 1043 nd router.
I used to use an old pc with Debian for this purpose. I followed this
wiki article
http://wiki.ampr.org/index.php/Setting_up_a_gateway_on_OpenWRT and i can
ping to different 44net IPs from the router's console. The gateway's IP
is 44.185.22.1 аnd I would someone to test if it is reachable.
I am also a little bit confused how my other devices will connect to the
gateway. There was a pptpd server on the pc and it was easy. Now there
is another VLAN on the router and I assume that I need to configure some
of the lan ports (the switch) to use this new VLAN. This is good for the
local connections. Can I use again pptpd and connect to my gateway from
Internet like I used to do?
--
73! Daftcho, LZ1DAF
Arno Verhoeven wrote:
> I just want to add 44.137.24.0/22 to a gateway but noticed that it had
> been deleted from my list of allocations.
Please don't route regional subnets this way anymore.
because then it can be reached both over radio and via the gateway.
It is now routed with BGP to PE1RDP who will route it to the access point until
arrangements have been made for a more direct routing.
IPIP is still available for user subnets when you wish to route a network.
> In its place I now have 44.137.27.193/32 in my allocation list. Which is
> strange because I never requested it and it is a single host assigned to
> someone who has his own gateway.
This was probably a copy/paste error made when updating the portal entry.
I have corrected it (it belongs to PE5YES)
Rob
> Prior to flaming me, perhaps you should get your facts straight?
> I have done several maintenance jobs and bug fixes on the Portal over the past couple of years, as and when they are reported to me. I’m working on a new feature right now that was requested.
> If you have a problem you only need to contact me and ask for assistance, but I am not good at reading minds I’m afraid.
> As for the DNS code in the Portal, it has been ready for over a year now, but Brian wanted me to hold off making it live until the current DNS can be cleaned up - hence this push to do just that.
> As to your other comments regarding how the portal operates, that’s your opinion, which you are entitled to, but I originally wrote the code based on requirements and input from other folk, I didn’t just “make it up” myself.
> Of course, if you want to offer your time re-write some of the code, or add new functionality then please lets talk, I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And before anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need to be, if you want access to the code repository you only need to ask and it will be provided.
Chris,
I have brought up the topic of (impossibility of) editing subnets a long time ago.
I have also reported the problem with registration of existing allocations (the user cannot specify what they want to register, only request a new allocation), and requested a way to delete open requests that cannot be completed.
And a few months ago I requested that, facing the impossibility to delete a subnet without also deleting all its children and realizing that adding this may be nontrivial, you manually delete the 44.137.24.0/22 subnet that was erroneously created long ago, without deleting the subnets that are now under it.
Apparently in the requirements and input you received the migration of existing allocations was not included. I seem to remember that this has been discussed and apparently it was downplayed as not important, but I don't agree with that.
In my opinion, it should be possible to migrate existing allocations to the portal system when the holder desires to do that.
Without such functionality, we cannot request all the existing users to register themselves and find out what to do next.
I am doing a lot for the local amateur digital network here, and I have to select what other projects I join. I cannot be active in all of them.
You have to understand that, contrary to some other areas, we are actively developing and using the network, and we require a system that works for us.
So until now we have chosen to not register all the IP allocations via the portal, but only the required minimum that is the IPIP tunneled space, waiting for suitable functionality.
In the DL/OE HAMNET the situation is the same, and there they developed their own system, HamnetDB.
I understand that it is a spare time effort and other activities have priority, but we cannot live with a system part that keeps us back from progress forever.
When there are problems or changes, there has to be some outlook that they will be fixed some day. Does not need to be tomorrow.
Maybe you should join efforts with the HamnetDB people to merge the part that now handles the IPIP tunnel system with their system, which in other areas is much much more flexible and more like what we require.
(although of course there always are wishlist items, e.g. because of things that are incompatible with our local license system)
Rob
> Subject:
> Re: [44net] ICMP: A small request
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 02/19/2016 06:37 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Especially as we are all running tunnels, you (well your systems) really want to receive ICMP 3:4 (Fragmentation required, and DF flag set) messages.
>
> The "Ping of death" is not an issue anymore, and ICMP Flooding isn't really frequent anymore either. Nowadays neither of both require rejecting all kind of ICMP messages. Usually a fair rate limiting in the INPUT chain does the trick.
>
> 73 de Marc, LX1UDC
Unfortunately people like Steve Gibson have done a lot of damage by misinformation - likely more than the damage ever caused by replying to a PING.
It is still hard to convince some people they should not block all ICMP. At work I am currently trying to solve a problem caused by dropping the above ICMP packet
combined with the "blackhole detect" misfeature that means the connection is not just completely breaking down (and the bad firewall operator noticing
his mistake), but becoming much slower. As bad as a site that has IPv6 in DNS but not actually working...
Rob
Daftcho,
Your configuration appears to be correct; but you performed traceroute on your WAN IP address, and not the 44net IP.
Attempt to perform traceroute using the interface argument:
'traceroute whatismyip.ampr.org -i br-amprlan'
73,
- Lynwood
KB3VWG
