4 Aug
2015
4 Aug
'15
2:08 a.m.
Subject:
Re: [44net] New Linux Boot Scripts for Testing
From:
"Marius Petrescu" <marius(a)yo2loj.ro>
Date:
08/03/2015 01:45 PM
To:
"'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
Ok. It seems I got that wrong.
Actually there is no reply via tunnel. I can ping your system only via the
public internet.
Marius
Same for me, Marius!
I did (just as for N1URO) detailed tracing of the network traffic and although there is
outgoing encapsulated IPIP
traffic to his advertised gateway, there is no reply whatsoever.
It is still unclear to me if there is some problem with the operation of the network, or a
systematic bug in the
scripts that some people use. This time I thought I could download a script and have a
look, maybe I see
some problem, but I cannot access the site from any address I tried... :-(
Rob
4 Aug
4 Aug
2:33 a.m.
New subject: New Linux Boot Scripts for Testing
For what it's worth I had a similar issue.
A station was sending data to mine and mine was replying and seemingly upon
deaf ears.
What I found out after watching and staring at the trace screen for a while
was that the station had an ip address change and was sending data to mine
using the new address and mine was replying with the old address. Once I
figured it out and made the change all went well again..
73, Don
On Mon, Aug 3, 2015 at 3:08 PM, Rob Janssen <pe1chl(a)amsat.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
>
>> Subject:
>> Re: [44net] New Linux Boot Scripts for Testing
>> From:
>> "Marius Petrescu" <marius(a)yo2loj.ro>
>> Date:
>> 08/03/2015 01:45 PM
>>
>> To:
>> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>>
>>
>> Ok. It seems I got that wrong.
>> Actually there is no reply via tunnel. I can ping your system only via the
>> public internet.
>>
>> Marius
>>
>
> Same for me, Marius!
> I did (just as for N1URO) detailed tracing of the network traffic and
> although there is outgoing encapsulated IPIP
> traffic to his advertised gateway, there is no reply whatsoever.
>
> It is still unclear to me if there is some problem with the operation of
> the network, or a systematic bug in the
> scripts that some people use. This time I thought I could download a
> script and have a look, maybe I see
> some problem, but I cannot access the site from any address I tried... :-(
>
> Rob
>
2:46 a.m.
New subject: New Linux Boot Scripts for Testing
Rob;
n1uro@n1uro.ampr.org:/uronode$ ping pe1chl
ICMP Echo request sent to: 44.137.40.1
ICMP Echo reply received from: 44.137.40.1
Ping completed in: 113ms (ttl=62)
n1uro@n1uro.ampr.org:/uronode$ tra
Executing command...
what IP or HOSTName do you wish to trace? pe1chl
Please wait while we trace to pe1chl...
traceroute to pe1chl (44.137.40.1), 30 hops max, 60 byte packets
1 gw.ct.ampr.org (44.88.0.1) 7.411 ms 7.762 ms 7.758 ms
2 sys2.pe1chl.ampr.org (44.137.40.2) 115.385 ms 116.427 ms 122.728
ms
3 pe1chl.ampr.org (44.137.40.1) 126.044 ms 128.015 ms 129.829 ms
Tracing complete.
URONode tracer v1.3 - TraceRoute utility by N1URO.
Goodbye.
Returning you to the shell...
n1uro@n1uro.ampr.org:/uronode$
Seems to work for me fine.
On Mon, 2015-08-03 at 21:08 +0200, Rob Janssen wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> > Subject:
> > Re: [44net] New Linux Boot Scripts for Testing
> > From:
> > "Marius Petrescu" <marius(a)yo2loj.ro>
> > Date:
> > 08/03/2015 01:45 PM
> >
> > To:
> > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
> >
> >
> > Ok. It seems I got that wrong.
> > Actually there is no reply via tunnel. I can ping your system only via the
> > public internet.
> >
> > Marius
>
> Same for me, Marius!
> I did (just as for N1URO) detailed tracing of the network traffic and although there
is outgoing encapsulated IPIP
> traffic to his advertised gateway, there is no reply whatsoever.
>
> It is still unclear to me if there is some problem with the operation of the network,
or a systematic bug in the
> scripts that some people use. This time I thought I could download a script and
have a look, maybe I see
> some problem, but I cannot access the site from any address I tried... :-(
>
> Rob
>
2:59 a.m.
New subject: New Linux Boot Scripts for Testing
Brian wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Rob;
n1uro@n1uro.ampr.org:/uronode$ ping pe1chl
ICMP Echo request sent to: 44.137.40.1
ICMP Echo reply received from: 44.137.40.1
Ping completed in: 113ms (ttl=62)
n1uro@n1uro.ampr.org:/uronode$ tra
Executing command...
what IP or HOSTName do you wish to trace? pe1chl
Please wait while we trace to pe1chl...
traceroute to pe1chl (44.137.40.1), 30 hops max, 60 byte packets
1 gw.ct.ampr.org (44.88.0.1) 7.411 ms 7.762 ms 7.758 ms
2 sys2.pe1chl.ampr.org (44.137.40.2) 115.385 ms 116.427 ms 122.728
ms
3 pe1chl.ampr.org (44.137.40.1) 126.044 ms 128.015 ms 129.829 ms
Tracing complete.
URONode tracer v1.3 - TraceRoute utility by N1URO.
Goodbye.
Returning you to the shell...
n1uro@n1uro.ampr.org:/uronode$
Seems to work for me fine.
Yes, that one works. It is on a tunnel for only that address.
But other hosts in 44.137.0.0/16 that should use the route for that entire /16 do not
work.
E.g. 44.137.0.1 or 44.137.41.97
How do you route 44.137.0.0/16 ?
Rob
3:07 a.m.
New subject: New Linux Boot Scripts for Testing
Rob;
How do you route 44.137.0.0/16 ?
However it's received via the Portal/RIP system. Currently its:
44.137.0.0/16 via 213.222.29.194 dev tunl0
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.net
http://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
3:12 a.m.
New subject: New Linux Boot Scripts for Testing
Brian wrote:
Rob;
That is correct, but it does not actually route the reply traffic to there.
Or at least, it is not received at our end of the tunnel.
Can you ping the public address?
I now have a ping running from 44.137.0.1, please observe what is happening.
Rob
How do you route 44.137.0.0/16 ?
However
it's received via the Portal/RIP system. Currently its:
44.137.0.0/16 via 213.222.29.194 dev tunl0
3:30 a.m.
New subject: New Linux Boot Scripts for Testing
Rob;
On Mon, 2015-08-03 at 22:12 +0200, Rob Janssen wrote:
That is correct, but it does not actually route the
reply traffic to there.
Or at least, it is not received at our end of the tunnel.
Can you ping the public address?
I now have a ping running from 44.137.0.1, please observe what is happening.
n1uro@n1uro:~$ fping 213.222.29.194
213.222.29.194 is alive
n1uro@n1uro:~$ fping 44.137.0.1
44.137.0.1 is alive
n1uro@n1uro:~$
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.net
http://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
3:32 a.m.
New subject: New Linux Boot Scripts for Testing
Brian wrote:
Rob;
On Mon, 2015-08-03 at 22:12 +0200, Rob Janssen wrote:
Now it suddenly starts to work!
--- 44.88.0.9 ping statistics ---
1117 packets transmitted, 106 received, 90% packet loss, time 1122044ms
rtt min/avg/max/mdev = 116.516/119.247/130.393/2.411 ms
Is there some stateful firewall e.g. in a router that you have set to "forward a
protocol" or "dmz"?
I have seen before that such forwardings sometimes are not transparent and only work when
the
first traffic is from inside.
Rob
That is correct, but it does not actually route
the reply traffic to there.
Or at least, it is not received at our end of the tunnel.
Can you ping the public address?
I now have a ping running from 44.137.0.1, please observe what is happening.
n1uro@n1uro:~$ fping 213.222.29.194
213.222.29.194 is alive
n1uro@n1uro:~$ fping 44.137.0.1
44.137.0.1 is alive
n1uro@n1uro:~$
7:21 a.m.
New subject: New Linux Boot Scripts for Testing
On Mon, 2015-08-03 at 22:32 +0200, Rob Janssen wrote:
Now it suddenly starts to work!
--- 44.88.0.9 ping statistics ---
1117 packets transmitted, 106 received, 90% packet loss, time 1122044ms
rtt min/avg/max/mdev = 116.516/119.247/130.393/2.411 ms
I wouldn't consider 90% packet loss working.
Is there some stateful firewall e.g. in a router that
you have set to "forward a protocol" or "dmz"?
Not at all.
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.net
http://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
2:11 p.m.
New subject: New Linux Boot Scripts for Testing
Brian wrote:
At any rate, it looks like there is some stateful firewall inbetween that blocks IPIP
packets from me to you until you
"open" it by sending packets from you to me.
I tried an hour or so later and again there was no reply. When I ping now, no reply.
However, from the other gateway
I can still ping you (and deliver these mails).
Do you have some script that causes regular traffic, e.g. pinging or otherwise, to my
personal gateway?
(external address 89.18.172.156, serving 44.137.40.1 and 44.137.40.2, the one you pinged
first yesterday)
When trying from our 44.137.0.0/16 gateway that has external address 213.222.29.194 I get
no replies.
But when I ping your external IP from there, no problem.
Both these systems are in (different) ISP datacenters with their ethernet interface
directly connected to a switch
on a subnet routed by an ISP-grade router. No consumer NAT routers involved at all.
Recently, I assisted a local ham who had set up a gateway and had a similar problem. When
he pinged outward from
his system he could reach many others, but when he asked others to access his system from
the outside it did not
work, or sometimes it worked and sometimes not.
It turned out he was using some cable modem/router where he had set up 1 system to receive
the IPIP traffic, I think
by declaring it a "dmz host", and it did not receive IPIP traffic until he sent
outward IPIP traffic to the tunnel he wanted
to receive traffic from.
He switched from IPIP tunnel mesh to a VPN to our gateway because he could not find any
user configurable item in
his router that would remove this unwanted stateful firewall item.
It may well be that some people on this list suffer the same problem, maybe even without
knowing.
(because when they connect outward from their own system there never is a problem)
Rob
On Mon, 2015-08-03 at 22:32 +0200, Rob Janssen wrote:
As I mentioned: it suddenly starts working. I had started that ping to allow you to trace
what comes in and
what goes out. At my end I see encapsulated IPIP packets going out to your gateway, but
no replies.
After sending 1011 packets without reply, suddenly replies started coming back.
I interrupted the ping after 106 replies.
At that time, a mail from you came in stating that you could ping me.
Apparently once you did that, the tunnel started to work from my side as well.
Now it suddenly starts to work!
--- 44.88.0.9 ping statistics ---
1117 packets transmitted, 106 received, 90% packet loss, time 1122044ms
rtt min/avg/max/mdev = 116.516/119.247/130.393/2.411 ms
I wouldn't consider
90% packet loss working. Is there some stateful firewall e.g. in a router
that you have set to "forward a protocol" or "dmz"?
Not at
all.
7:10 p.m.
New subject: New Linux Boot Scripts for Testing
As per the 44.88.0.9:
As per my tests since this morning (local time) for the first time
I can ping and connect the http and ftp facilities at 44.88.0.9 and
downloaded some files... never happened since years to now!!!
Hope that Brian will share his actual GW setup, TNX.
As per the 44.137.0.1 and subnets:
Report is that the 44.137.0.1 GW is promptly pingable, but regarding
their subnet only the following are *correctly* pingable, namely:
44.137.24.5
44.137.40.1
44.137.40.10
44.137.40.2
44.137.40.20
all the other not.
As per the 44.60.44.10:
Remain not pingable
The hamwan.org remain unreachable
It is strongly necessary to reach the *standard* GW setup by
publishing that giving positive results.
gus
Brian wrote:
At any rate, it looks like there is some stateful firewall inbetween
that blocks IPIP packets from me to you until you
"open" it by sending packets from you to me.
I tried an hour or so later and again there was no reply. When I
ping now, no reply. However, from the other gateway
I can still ping you (and deliver these mails).
Do you have some script that causes regular traffic, e.g. pinging or
otherwise, to my personal gateway?
(external address 89.18.172.156, serving 44.137.40.1 and 44.137.40.2,
the one you pinged first yesterday)
When trying from our 44.137.0.0/16 gateway that has external address
213.222.29.194 I get no replies.
But when I ping your external IP from there, no problem.
Both these systems are in (different) ISP datacenters with their
ethernet interface directly connected to a switch
on a subnet routed by an ISP-grade router. No consumer NAT routers
involved at all.
Recently, I assisted a local ham who had set up a gateway and had a
similar problem. When he pinged outward from
his system he could reach many others, but when he asked others to
access his system from the outside it did not
work, or sometimes it worked and sometimes not.
It turned out he was using some cable modem/router where he had set up
1 system to receive the IPIP traffic, I think
by declaring it a "dmz host", and it did not receive IPIP traffic
until he sent outward IPIP traffic to the tunnel he wanted
to receive traffic from.
He switched from IPIP tunnel mesh to a VPN to our gateway because he
could not find any user configurable item in
his router that would remove this unwanted stateful firewall item.
It may well be that some people on this list suffer the same problem,
maybe even without knowing.
(because when they connect outward from their own system there never
is a problem)
Rob
On Mon, 2015-08-03 at 22:32 +0200, Rob Janssen
wrote:
As I mentioned: it suddenly starts working. I had started that ping
to allow you to trace what comes in and
what goes out. At my end I see encapsulated IPIP packets going out
to your gateway, but no replies.
After sending 1011 packets without reply, suddenly replies started
coming back.
I interrupted the ping after 106 replies.
At that time, a mail from you came in stating that you could ping me.
Apparently once you did that, the tunnel started to work from my side
as well.
Now it suddenly starts to work!
--- 44.88.0.9 ping statistics ---
1117 packets transmitted, 106 received, 90% packet loss, time 1122044ms
rtt min/avg/max/mdev = 116.516/119.247/130.393/2.411 ms
I wouldn't consider
90% packet loss working. Is there some stateful firewall e.g. in a router
that you have set
to "forward a protocol" or "dmz"?
Not at all.
3429
days inactive
3430
days old
10 comments
4 participants
participants (4)
-
Brian -
Don Moore -
Gustavo Ponza -
Rob Janssen