Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

I have given a little more thought to my project involving getting my ZyXEL VMG 1312-B10A modems to be able to have some access to the internet. This would be done by going back through the Firebrick firewall-router, not accessing the internet independently as that would be a security disaster, so all access would be heavily restricted and behind the usual firewalling.

I managed to get DNS to work by the magic invocation
    dns config static 192.168.n.254
where n is 1, 2, 3, 4 as each modem is numbered. That IP address refers to the Firebrick itself. Because the Firebrick is a local relay DNS caching server, that is all that is needed to get DNS access working for the modems, and no internet access is even needed.

This command though is not persistent. Is there an alternative method that would survive a reboot? Or any way of adding scripts into the boot sequence? (Without reflashing the machine of course, which would be cheating.)

I was thinking once more about getting NTP access to work. I wondered if I could achieve this without getting real internet access going by using a similar strategy. I assign another address, say 192.168.n.250 and tell the modem that this address is the NTP server. I then get the Firebrick to redirect traffic going to that address to the ISP’s NTP server and the return path gets handled by the Firebrick’s NAT function. I don’t know what the magic runes required for the Firebrick are to set that up, but I can try my best guess, mention NAT to it and see if it gets the hint to do the right thing automagically. Does that sound feasible?

[hacktrix2006]

your DNS config command is that being done on the firebrick or the Zyxel modems?

[j0hn]

this method gets working ntp

https://forum.kitz.co.uk/index.php/topic,19966.msg358884.html#msg358884

This corrects the timing on the zyxel log

[Weaver]

@hacktrix2006 Apologies, that’s a modem CLI command.

@j0hn -that’s the missing link. Many thanks! Won’t work for me on its own, not until I get the router sorted out, so I’ll implement this and then work on the Firebrick next.

[Weaver]

I have cobbled together some Firebrick rules in its config and the Brick’s own self-analysis report in diagnostics gives an encouragingly positive opinion if my effort. But who knows. I’ve already configure a modem as suggested earlier ready to go.

Now the daft thing is: how do I test it, how do I tell that it’s working?

Do I frig the time to be wrong and see if it gets corrected at some point?

Or I reboot it and see what happens?

I could do a packet capture on it if I knew when.

I’m wondering what the least-hassle test is, because I’m lazy and also rather befuddled.

[Weaver]

Tada !   

I’ve cracked it. It works!

I suddenly had an idea about a way to force a test. I went into the web admin UI and fiddled around with the NTP servers and reserved the settings. I hoped that so doing would force it to restart or re-kick the NTP client to get it to query the new servers. Luckily the time was wrong before I started this. I hit save in the dialog box and the time updated to the correct value based off NTP addresses to the Firebrick itself, in this case 192.168.3.254 as that is the Firebrick on this subnet and no gateway is needed on that LAN as that is an on-link address within that LAN range.

The Brick had been told to specifically spot UDP dest_port=123 going to that address on that interface and redirect it to Andrews and Arnold’s NTP server and it performed NAT translation on the packets to make the src IP reasonable, set the UDP src port value to be distinctive for the NAT subsystem and entered the session to the outside world in the NAT translator’s session lookup table. So presumably when the reply came back, it identified the distinctive combination of protocol-UDP plus UDP unique dest port value and reverse mapped it, rewriting the packet as needed and redirected the reply back to the modem as the NAT translator table told it how.

[burakkucat]

   

[Weaver]

My remaining challenge from earlier is how to get DNS to work. Could not adapt the techniques used for NTP as I can’t see any way to configure a DNS client using the web UI and get it to query a DNS server via the modem’s LAN i/f. It’s not something they’ve thought about clearly as most of the web UI stuff only makes sense when the device is being a router and they would need to rethink it all for modem mode.

That CLI command works fine but is not persistent as I mentioned before. I could use that if I could get it into some on-startup shell script. Our very own Johnson did this, but he altered the firmware to make provision for such. I would need something that works via the config info.

I’m completely at a loss concerning this at the moment and am not sure it’s even possible. I don’t know anything about the general issue of persistence with the CLI commands. I wonder if there already is some general solution to make the effect of many of those CLI commands persist, where that makes sense, or else add them as actions at boot. That would be very worthwhile.

I wonder if one can use cron to help get things to persist? Can cron’s associated functions make things run at startup?

[burakkucat]

I wonder if one can use cron to help get things to persist? Can cron’s associated functions make things run at startup?

Most recent implementations of cron will allow usage of an @reboot string --

       These special time specification "nicknames" are supported, which replace the 5 initial time and date fields, and are prefixed by the ’@’ character:

       @reboot    :    Run once after reboot.
       @yearly    :    Run once a year, ie.  "0 0 1 1 *".
       @annually  :    Run once a year, ie.  "0 0 1 1 *".
       @monthly   :    Run once a month, ie. "0 0 1 * *".
       @weekly    :    Run once a week, ie.  "0 0 * * 0".
       @daily     :    Run once a day, ie.   "0 0 * * *".
       @hourly    :    Run once an hour, ie. "0 * * * *".

[j0hn]

A heads up on the static route method used above for ntp, it seems to stop working randomly for no apparent reason. I've had to apply this a couple of times in the past 12-18 months.

Haven't got round to trying to work out why. It might be as simple as a reboot breaks it but as I only reboot the modem a few times a year I can't say for certain.

I think reapplying the static route (simply hitting the "save" button on the relevant webui page) gets it going again.
The time going bad on the Zyxel log is a giveaway it breaks.

Unfortunately this can't really be tested easy without the device being connected and the FTTC DLM can apply a horribly sticky banding/cap for too many resyncs in a short period.

It's the only method I'm aware of that gets working ntp on the zyxel in bridge mode without giving other access to the WAN which I do not want.

[Weaver]

@j0hn I didn’t add a route or anything. I just told the modem that the NTP server was at 192.168.n.254 where n is the modem an address which is the Firebrick according to my setup, the Firebrick’s own address that it has configured for itself on that Firebrick ‘subnet’ object in an ‘interface’ object which is associated with the Ethernet link to the modem. That address is in the modem’s own LAN subnet IP range so it can just be ARPed fine by the modem, and the modem doesn’t need to know a gateway address value to be able to talk to it, as I have been unable to work out how to set up a gateway value at all, never mind persistently. The Firebrick is configured to spot stuff going to UDP, port 123 at that address, set NAT translation going, NAT-rewrite/adjust the packet and redirect it to the ISP’s NTP server. The return from the ISP’s NTP server gets reverse-NATed and comes back to the modem. There is a Firebrick rewrite rule anyway that rewrites everything coming in to the modem so that it has an source address of 192.168.n.254 and luckily that is ok with what we’re doing here. That is to make the modem able to reply to all stuff coming in to it as it is an address that as a ‘return address’ is something that the modem can cope with. Here it fits in with its expectation for the source address for a reply from the ‘NTP server’ it talked to, so it all works out. The way this is all set up, the modem can only ever talk to one address anyway. It’s all a bit weird. It’s as if the view of the entire internet that I’m giving it is compressed down into a view one address wide. The only thing it can vary is protocol and port value. So this very limited setup is just enough, barely, to allow a few special cases to work.

[Weaver]

@burakkucat : that is superb. I need to find out whether that will work or fail on the modem because of lack of write access to some appropriate storage location.

[<off-topic> Oh and before I forget, on a private note the Kuro Neko was kind enough to send me some C source code - many thanks, that was good of you.</off-topic>]

[Weaver]

I logged in as ‘supervisor’, and tried the following

Code: [Select]

# ls /etc/cron
ls: /etc/cron: No such file or directory
~ # ls /etc/crontab
ls: /etc/crontab: No such file or directory
~ # md /etc/crontab
sh: md: not found
~ # mkdir /etc/crontab
mkdir: can't create directory '/etc/crontab': Read-only file system
~ # ls /var/spool/cron
ls: /var/spool/cron: No such file or directory
~ # mkdir /var/spool/cronmkdir: can't create directory '/var/spool/cron': No such file or directory
~ # mkdir /var/spool
~ # mkdir /var/spool/cron
~ # crond
sh: crond: not found
~ #
So no write access to some of the expected directories. Even though I can create the directory /var/spool/cron, so at least there is write access, it did not exist before, so that is not encouraging and I don’t know if it will persist anyway, or whether it is just a ram disk? Even if cron exists [?] and works it’s pointless unless things stored will persist, so setting up a crontab file somewhere and even demonstrating that it works isn’t enough. I’m a bit lost now as to where to go.

[Weaver]

Apol for repeated posts, but they are separate topics, so perhaps easier to read that way?

It would be a bit cheeky to ask Johnson for a feature request to add a user-configurable system startup script feature to the customer firmware project, after he has done so much already, incredibly generous. Even with that, where would one store the requested value in the config? Wherever the config XML gets stored, presumably that is the answer?

[Weaver]

About the Firebrick NTP redirection config : I seem to remember reading something that suggested that RevK, who is working on Firebrick development, is writing a local NTP server process for the Firebrick. So that would be superb. More reliable, as the local machines can still NTP-sync to something, just over the LAN, even if internet access goes down or if the internet link is really busy so that time sync fails. And it slightly reduces the amount of traffic over your internet link.