Today I noticed that the log on our gateway lost some detail for IPIP traffic.
(now that everyone is discussing trouble with tunneled packets...)
In the past with Linux kernel 3.2 and 3.16, when some packet incoming over tunl0 was hitting a LOG target
in the iptables firewall, it would log a MAC address of the entire IP header as hex bytes (colon separated),
like this:
Apr 16 07:39:13 gw-44-137 kernel: [1266597.275238] Packet DROP: IN=tunl0 OUT=eth
1 MAC=45:00:00:44:10:f9:00:00:f9:04:e9:f9:54:6a:7e:b8:d5:de:1d:c2:45:00:00:30:64
:21:40:00:7e:06:29:1a:c0:a8:58:0a:2c:89:2a:51:e9:c0:14:66:1f:fa:64:c8:00:00:00:0
0:70:02:20:00:70:a9:00:00:02:04:05:b4:01:01:04:02:c8:78:03:6b:1a:74:bd:29:37:8d:
da:27:61:d7:2f:22:b0:b5:2b:b8:b4:61:3a:60:08:23:48:1b:26:15:57:80:00:00:85:ec:03
:32:df:df:85:46:bb:b3:40:e4:0f:df:4b:3d:93:e0:ed:f3:46:d4:e0:17:68:b6:dd:5d:f1:3
f:1b:1e:6f:a0:f0:69:5c:28:4a:3c:24:17:20:ff:e5:97 SRC=192.168.88.10 DST=44.137.4
2.81 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=25633 DF PROTO=TCP SPT=59840 DPT=5222
WINDOW=8192 RES=0x00 SYN URGP=0
(wrapped)
Ok, that was much too long, there was probably a bug somewhere and the intention was to show
only the outer IP header.
Recently I switched to kernel 4.9 but now the packets are logged with no info at all:
May 9 18:05:57 gw-44-137 kernel: [359091.001991] Packet DROP: IN=tunl0 OUT= MAC=
SRC=192.168.15.2 DST=44.137.75.242 LEN=243 TOS=0x00 PREC=0x00 TTL=123 ID=39243
PROTO=UDP SPT=5198 DPT=5198 LEN=223
The MAC field is now simply empty.
With the first format I had a small perl script that processed the log entries and showed the
tunnel endpoint that was sending the packet:
Apr 16 07:39:13 gw-44-137 kernel: [1266597.275238] Packet DROP: IN=tunl0 OUT=eth1
TUNL=84.106.126.184 SRC=192.168.88.10 DST=44.137.42.81 LEN=48 TOS=0x00 PREC=0x00
TTL=126 ID=25633 DF PROTO=TCP SPT=59840 DPT=5222 WINDOW=8192 RES=0x00 SYN URGP=0
However, now this is no longer possible.
I have tried finding info about it but no success yet.
Does anyone know if there is some parameter to tune this behaviour?
Rob
> In the past with Linux kernel 3.2 and 3.16
> Recently I switched to kernel 4.9
That was incorrect. The first behaviour was with kernel 3.2 and the 3.16
kernel does not log that long MAC address anymore. The 4.9 kernel is on
another system, it is not related to this.
Rob
If your gateway appears in the pkterrors.txt file, the packets which
caused that error to be logged and the packet to be dropped are now
available in a file you can retrieve with your web browser. They are
binary log files, so you'll need a program to interpret them. The URL
for a typical file is
https://gw.ampr.org/private/errors/67.164.64.8.bin
where of course the IP address part changes to whatever your gateway
address is. The files are removed and start fresh at midnight Pacific
time (GMT-7 or -8). For some error-prone sites, they get large-ish.
The format of each file is
/*
* 2 bytes error number (unsigned short)
* 2 bytes packet length (unsigned short)
* 4 bytes time (seconds since epoch)
* 4 bytes fractional seconds (microseconds)
* n bytes (packetlen) encapped IP packet in network byte order
*/
I have a 'C' program that will interpret the file, which you may have
if you're interested. It calls some library routines that you probably
don't have, so you'll have to modify it to get it to run on your system.
In particular, the error number and packet content interpreters are up
to you. I don't think the compiled code will run on Linux but you're
welcome to it if you have a FreeBSD system to run it on.
Or if you like, I'll run it on your gateway error log file and mail you
the output. That looks like this:
timestamp (GMT) len err error
-------------------- ---- ---- ----------
2017-05-08T19:04:32Z 40 [19] dropped: non-44 inner source address
ver=4 hl*4=20 tos=00 ip_len=40 id=d431 off=0000 ttl=244 proto=6 cksum=7d51 [TCP] 184.105.139.107:44864 -> 44.118.5.2:16992
2017-05-08T19:05:51Z 40 [19] dropped: non-44 inner source address
ver=4 hl*4=20 tos=00 ip_len=40 id=18f4 off=0000 ttl=43 proto=6 cksum=5b02 [TCP] 181.23.53.75:58147 -> 44.118.5.2:2222
etc.
So far, keeping these log files doesn't seem to burden the system
very much. If that changes, I'll have to discontinue them.
- Brian
The amprgw router is now periodically preparing a report of the bad
packets that it discards. You can retrieve a copy of this report right
next to the statistics report: <https://gw.ampr.org/private/pkterrors.txt>.
You'll need the same userid and password as for the stats.txt file
(same as the one you use to fetch the encap file from the portal.)
It's in gateway and source address order to make finding your own gateway
and host in the listing somewhat easier.
Current plan is to update the report every 15 minutes, and restart the
tally at midnight Pacific time.
Here are the first few lines (there are currently about 2,300).
Let me know if you have any problems or questions with this.
- Brian
Last update at Wed May 3 15:45:00 2017
gateway inner src #errs indx error type
---------------- ---------------- ----- ---- -------------------------------
2.84.96.101 44.154.0.1 9 [ 8] dropped: encap to encap
2.84.96.101 44.154.2.1 3 [ 8] dropped: encap to encap
2.84.96.101 44.154.3.1 3 [ 8] dropped: encap to encap
2.84.96.101 44.154.4.1 4 [ 8] dropped: encap to encap
2.84.96.101 44.165.2.3 106 [ 8] dropped: encap to encap
18.96.0.110 44.44.7.225 6 [ 8] dropped: encap to encap
18.96.0.110 44.44.7.232 8 [ 8] dropped: encap to encap
23.30.150.141 23.30.150.141 1326 [19] dropped: non-44 inner source address
All,
I was wondering if anyone is using pfSense as their gateway's router OS.
If so, have you been successful at compiling a running version of
ampr-ripd for it?
I'm very interested in pfSense's intrusion detection and prevention
using Snort. I may be willing to test a Gateway if someone has used a
compatible version of ampr-ripd (FreeBSD 10.3 64-bit).
Also, I've asked the LEDE developers to consider adding a blocking
feature to the Snort package available on the device
(https://bugs.lede-project.org/index.php?do=details&task_id=772).
73,
- Lynwood
KB3VWG
Is there any place that i can grab image for raspberry pi that will allow the following
1) ipip
2) option for TNC software with Net/ROM support and TCP/IP If there is Jnos its better for me as i know it from the past (to allow users from radio to gain access)
3) MMDVM support (to allow connect a DMR repeater based on MMDVM and Arduino)
I currently have a working set consist of PI and MMDVM software connected to the arduino running on the AMPRNET
but the Pi dont support IPIP
Is it more easy just to add the IPIP support for my Image ? (please dont tel me "get this and this and compile" as I dont know to compile But if it is only to install something with simple command i can do it )
any help / recommendation is welcome
Regards
Ronen/4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
Brian,
Since you are using Apache perhaps you can enable more client details
in your log verbosity by changing your LogFormat from the default settings to
the combinedio settings which will include more information about the client
software that is connecting to your web server.
Such details as these can be shown if you increase your LogFormat:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O"
combinedio
CustomLog "logs/access_log" combinedio
Client Agent (small sample)
"Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0"
"Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 (internal dummy
connection)"
"Googlebot/2.1 (+http://www.google.com/bot.html)"
"Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
"Mozilla/5.0 (compatible; Baiduspider/2.0;
+http://www.baidu.com/search/spider.html)"
"Mozilla/5.0 (compatible; MojeekBot/0.6;
+https://www.mojeek.com/bot.html)"
Tim Osburn
W7RSZ / JG1MBR
https://www.osburn.com
On Mon, 8 May 2017, Brian Kantor wrote:
> Date: Mon, 8 May 2017 23:27:14 -0700
> From: Brian Kantor <Brian(a)UCSD.Edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] gateway errors detail available
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Yes, the host 'hamradio.ucsd.edu' where the mailing list is hosted
> also archives all messages and makes them available via the web.
>
> It's amusing: despite not being real, from the following Apache
> log entries, no-such-file has been a popular target this evening:
>
> gw.ampr.org-ssl 70.39.157.194 - - [08/May/2017:17:56:38 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 66.85.73.59 - - [08/May/2017:17:58:59 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 220.233.167.221 - - [08/May/2017:17:59:43 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 4.79.123.0 - - [08/May/2017:18:09:35 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 68.40.58.30 - - [08/May/2017:18:56:26 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 4.79.123.0 - - [08/May/2017:21:42:57 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
> gw.ampr.org-ssl 165.225.80.161 - - [08/May/2017:21:48:27 -0700] "GET
> /private/no-such-file.txt HTTP/1.1" 401 381
>
> The first one above was logged just 19 seconds after I posted the message
> to the list. The others came later; they could be humans. Note that
> none of them logged in; they just tried to fetch the file and went
> away. Oh, I'm not concerned, I just was a bit surprised. And curious.
> - Brian
>
> On Tue, May 09, 2017 at 04:42:26AM +0000, Ruben ON3RVH wrote:
> > Is the content of the list posted on a website? Like for archiving
> > purposes?
> > Otherwise someone might have a mailbox from the list configured with a
> > scraper..
> > Can you see which is the source IP for the requests? Maybe this can lead
> > you to the correct person..
> > 73,
> > Ruben - ON3RVH
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
I'm not sure I made this clear: with the change from my homegrown
format to PCAP, the file names changed from <address>.bin to
<address>.pcap. So you'd fetch
https://gw.ampr.org/private/errors/62.147.189.164.pcap
for example.
- Brian
Hi,
I added a gateway to one of my servers and set up a packet capture
system on it. It is running a webserver inside a container with the
relevant gateway configuration. The prefix is using the "BGP routed
subnets" configuration whereby the gateway is inside the prefix, but
using a /31.
https://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2BoZH6yGO…
It should auto-detect the client IP and captures all packets to/from
that address. If the client IP is within 44/8 then it will check the
routing table for a gateway and if so include that IP as well. I am
not sure if there would be concerns with allowing the user to type an
IP address to capture to/from, given that it's a non-production
gateway.
I have the subnet 44.131.14.252/31 registered on the portal with a
gateway address of 44.131.14.253. 252 should send encapsulated packets
and 253 should send directly. Both addresses are on the same host.
I have removed my previous route for 44.131.14.0/24 because nested
gateways don't work properly. I have tested to several destinations
and it seems to work, but if anyone finds something I've missed let me
know!
If it works properly and is useful then a hostname under ampr.org
might be more appropriate, but for now I’m just using a hostname under
my domain.
Thanks,
Mike, M6XCV
Hi there
Is there a simple way to know when new encap file created ? beside downloading the file itself and looking on the file header ?
My ISP replace my IP an hour ago and i still dont have connection ..
in the portal there is no time stamp when looking on the gateways list when the new update made ....
Im using DYNDNS method and the portal still show my old IP of course that the DYNDNS new ip is already updated
Of course i can edit it by hand in the portal but that is not the intention
Regards
Ronen - 4Z4ZQ
