Hello Ray, On 8/20/17, Ray via luv-main <luv-main@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