Thank you for all what you do for us ...

My router finally dont appear in the error list ....

________________________________

I don't know. I'll alter the code in new amprgw so that

Ooops.

Maybe that was a little premature. Remember that you're now sending through new amprgw and the pkterrors.txt file is on old amprgw. You wouldn't show up on old amprgw because you're not sending through it.

Unfortunately, there is no way for you to look at the web pages on new amprgw yet, so you can't see the pkterrors.txt and the pcap files that are generated there.

However, I looked at the pkterrors.txt file on new amprgw and you still have one problem:

gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 5.29.18.144 0.0.0.0 811 [16] dropped: zero inner source address

Looking at the pcap file, those are all MNDP - MicroTik Neighbor Discovery Protocol, which apparently you still have turned on. Turn that off and you're good. - Brian

On Wed, May 31, 2017 at 01:39:05PM -0700, Brian Kantor wrote:

Yay! Congratulations!

• Brian

Ronen, Let me suggest you leave it off. It doesn't serve any purpose in the AMPRNet and it runs up your error count. - Brian

On Wed, May 31, 2017 at 09:03:17PM +0000, R P wrote:

Im aware about the Zero address i had no way to check it i waited that the change there will be complete then ill be able to see what is the zero addresses But you did the job for me so at least i know whats the problem ill turn it off for the moment

Well, damn. I restarted the ipip daemon and they went away.

Looks like it's time to debug the routing table maintenance routing.

The log shows a new route being added but it appears to have been loaded on top of your route, thus misdirecting traffic. I'll work on it. Sorry for the bug. - Brian

On Wed, May 31, 2017 at 05:14:13PM -0400, lleachii--- via 44Net wrote:

Odd...they're still being received (Eastern Daylight Time). Just a few moments ago:

What's happening is that your route is moving to the next one in the routing table. Now all I have to do is find out why!

It would be helpful to know if ALL your traffic switches to the other person's address, or whether you still get some traffic for your proper subnet. There are two routing tables, one indexed by individual address and one indexed by subnet, and knowing which is being mis-indexed would help me find the problem.

In the meantime, I've restarted the daemon and you should be good again. - Brian

On Fri, Jun 02, 2017 at 09:46:29AM -0400, lleachii--- via 44Net wrote:

Brian,

Yep, debugging may be necessary, I'm receiving someone else's traffic again:

2017-06-02 08:04:44.392 0.000 TCP 1.34.202.215:24351 -> 44.62.1.81:16165 1 552 1 2017-06-02 08:05:49.494 0.000 TCP 195.88.209.24:41058 -> 44.62.1.81:3388 1 40 1

• Lynwood

KB3VWG

...

I restarted the ipip daemon and they went away.

Looks like it's time to debug the routing table maintenance routing.

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Ronen,

I see a number of packets being sent to your gateway 5.29.18.144 for destinations 44.138.1.x from old amprgw, including RIP, DNS responses, NTP traffic, and pings that I'm sending.

I also see outgoing traffic coming from your gateway from those hosts on new amprgw.

So I don't think there is a problem on this end. Could it be a problem with your new firewall rules? - Brian

On Fri, Jun 02, 2017 at 05:01:17PM +0000, R P wrote:

I stopped getting any tunnel traffic from UCSD old gateway no packet arrive here and of course i have lost connectivity

Yes, I can ping your router from both old and new amprgw.

I can't ping hosts on your subnet that I see traffic from, but I do see the encapsulated pings being sent to your gateway.

You should be seeing RIP from both old and new amprgw because I see it being sent to you. - Brian

On Fri, Jun 02, 2017 at 05:32:07PM +0000, R P wrote:

i have connectivity from the router to the old amprgw ping and traceroute May you check if you can ping my router ?

I just checked, and connectivity to both N1URO and KB3VWG-010 is working fine, so both old and new amprgw seem to be working. - Brian

On Fri, Jun 02, 2017 at 05:47:53PM +0000, R P wrote:

wonder if there is someone on the list that running on ipip and have connectivity problems ....

On Fri, Jun 02, 2017 at 02:03:56PM -0400, lleachii--- via 44Net wrote:

From my perspective, I stop seeing all inbound Internet traffic from AMPRGW to 44.60.44.0/24, except for the intermittent data to another subnet (now 44.62.1.81). I transmit, and never receive replies. Although, I'm still able to send and receive traffic to/from the other 44 GWs.

Thanks, that helps. I checked, and the on-disk copy of the routing table is still correct even when this is happening, so I'm beginning to suspect memory corruption in the router software itself.

As you know, that's difficult to find, but I'm looking through the code to make sure I haven't done any of the usual errors. The next time it happens, I'll take a core dump of the running process and see if that tells me anything. Be sure to let me know. - Brian

Brian,

Is everything OK at AMPRGW, I just received some VERY odd traffic (and I've been having interment connectivity):

2017-05-31 14:59:57.803 0.000 TCP 104.236.151.76:48212 -> 44.62.1.10:143 1 40 1 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> 44.62.1.14:22 1 48 1 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> 44.62.1.12:22 1 48 1 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> 44.62.1.10:22 1 48 1 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> 44.62.1.9:22 1 48 1 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> 44.62.1.11:22 1 48 1 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> 44.62.1.13:22 1 48 1 2017-05-31 15:00:36.520 0.000 TCP 213.32.7.73:44191 -> 44.62.1.10:22 1 40 1 2017-05-31 15:02:45.210 0.000 TCP 181.113.163.24:59150 -> 44.62.1.10:22 1 40 1 2017-05-31 15:03:08.697 0.000 TCP 186.134.5.194:51377 -> 44.62.1.12:22 1 40 1 2017-05-31 15:03:26.190 0.000 TCP 104.236.151.76:48281 -> 44.62.1.12:143 1 40 1 2017-05-31 15:03:28.222 0.000 TCP 117.9.45.58:47360 -> 44.62.1.11:22 1 40 1 2017-05-31 15:03:31.438 6.996 TCP 187.199.54.149:43075 -> 44.62.1.9:81 4 240 1

73,

- Lynwood KB3VWG

44.62.1.8 / 29 Southern Virginia Gateway AB4MW