Hello Ray,
On 8/20/17, Ray via luv-main <luv-main(a)luv.asn.au> wrote:
On 19.08.2017 20:23, Erik Christiansen via luv-main
wrote:
On 19.08.17 19:23, Ray via luv-main wrote:
I am doing some testing on this set up and I am
unable to talk to the
Dlink
4G router, IT is connected by a short cat5 cable to the eth0.
Of the firewall host mentioned upthread? (It is the only one described
as having two ethernet ports, IIRC.)
Yes
I think that the firewall machine may also fall into the category of a
bridge because it bridges two networks together. That may give you
some reference and a search term when looking to the configuration.
This port is
setup with an address of 192.168.1.6 and is the default
route for the machine.
Sounds like the firewall. We'll keep guessing on this track. But that
IP
will only be seen by the modem (i.e. inward traffic), and the default
route is for outward traffic, i.e. all the world's IPs other than your
inboard subnet.
Eth1 is connected to my switch connected to my
other machine, this
port has an address of 192.168.1.1 (ie my gateway machine)
Now you have the 192.168.1.0/24 subnet on both sides of the firewall.
Can you please post e.g. the output of "netstat -rn", to show how
you're
routing traffic through the firewall? (It can be split finer, but is
it?)
Both interfaces are up. THe IP address of the
Dlink 4G router is
192.168.0.1, when I point a browser at this address (either Firefox of
links2) there is no response, ifconfig shows some data is excahanged
(around 200 bytes tranmsited and 50 received, so the connection
appears to work.
A forward route is only half the story. What do ping and traceroute
report? Here, my modem is on the same subnet:
This test shows that there is only a connection in one direction, ie no
return path.
To me, without actual hands on experience, but an interest in reading
around the matter that it is an issue of the routing and iptables
setup on the firewall, that it is currently set to drop all the
incoming packets (or almost all), even when they are replies to
outgoing packets. The firewall mostly needs to prevent incoming
connection initiation, but needs to let in the returns from outgoing
connection initiation.
> $ ping router
> PING router (192.168.1.1) 56(84) bytes of data.
> 64 bytes from router (192.168.1.1): icmp_req=1 ttl=64 time=0.599 ms
>
> That tells me that there is a return path.
>
> $ traceroute router
> traceroute to router (192.168.1.1), 30 hops max, 60 byte packets
> 1 router (192.168.1.1) 0.548 ms 0.644 ms 0.836 ms
>
> If I had a firewall in between, that'd tell me whether I'm reaching the
> near port or the far one, IIRC.
>
>> What am I doing wrong, everyone makes out it is simple to communicate
>> with these things.
>
> It's not so simple that it can be done for the first time, without
> looking. And it's only simple after you've cancelled out the false
> assumptions, and done it right. E.g. a missing return route will stymie
> a
> ping, despite the forward path being peachy.
>
>> What config is required to talk to one of these self contained routers
>> connected to an ethernet port.
These self contained routers and modems often have a web interface for
administration, commonly something like www://home or www://m.home the
latter being what is mine
Is the
assumption that the router can't reply supported by a failed
ping
from the firewall host? If so, the long description above isn't part of
the problem. If the router isn't trusted, temporarily substitute
another
host, using the same IP, and test your hops from both ends - as one
might test the links of a chain. Assumptions tend to fall like
dandruff,
then.
Happy hunting. :-)
Erik
I do a bit of experimenting designing and building electronics, AM
recievers, both using valves and transistors (no IC's) servo circuits
etc, one thing this has shown me is do NOT assume ANY new components
actually meet there spec's, you have to test ALL components for there
spec's. Once I started to do this my success rate went way up, It
appears this needs to be treated the same. I will shift the machine to
one of my work benchs where I can get easy access to all parts, to allow
proper testing to be done.
A second point is I am going to have to find out (again!!, I have done
it once before, quite some time ago) the "nuts and bolts" or the
configuration of Debian's IFUPDOWN system. Sadly I have found Debian's
reference manual is not to clear on this. It does make a point that,
packages like the Network Manager should NOT be used for anything other
than a desk top system with a single connection and the IFUPDOWN system
to be used for anything complex.
Network Manager can do more complex things, but it is a pain. I too am
having troubles getting my head around it all. It is well written and
clear, once you know and understand the terminology and context.
Getting that step is the issue for me. Were I close enough for the
beginners workshops, I would pick up a lot quickly, trying on my own
with a lot else to do is another matter.
Many hanks again for your help, I will let all know
how I am getting on.
The situation is not critical as I do have internet access (from
WIndows) via an isolated machine dual booting Linux and Windows XP. Its
something of a pain to swap data via a USB thumb drive, but it DOES give
me access.
I know and understand, these days I am running one PC which is Debian
GNU Linux only, although I do have a second available for some tasks,
it too is Linux, but an out of date Ubuntu. It does not have the RAM
or processor or HDD space for an upgrade, just use as it is, but not
networked.
Lindsay
Regards,
Mark Trickett