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


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.

$ 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.

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.

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.

Lindsay

_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Reply via email to