My GPON ISP required that I obtain a commercial Fixed IP address as the only way to obtain a bridge ONU (for 20$/month).
However this is quite expensive and when I asked to just be put on DHCP but keep the bridge, this was no possible to do easily due to the GPON management software.
But they suggested an alternative that would cost only 5$/month as it would only burn one IP address instead. I love that option
@anon63541380 your example starts at port 1024 but I need the other inbound ports as well, especially for email and http reverse proxy running on my router device
Also do I not need to refer to the “lo” device or “br-lan” or the zones like LAN and WAN ?
You dont need to specify ports, that i added for completeness of syntax. Low ports need to be excluded for random as great half of games and cdns reject those.
Port 1 to 1024 are reserved for local services. The so called high ports are used for outgoing connections.
Iirc the default on Linux starts even with 32k or 16k
I have been using this, it works very well.
The arrangement with my ISP is that I have a /32 for a static IP address
Instead of a /30, so it costs me 5$/month, instead of 20$/month
The only little hiccup that I don't understand is that, very occasionnally, it stops working.
And the solution is simply to uncheck the "enable" checkbox, save and apply, and then re-enable it, as that fixes it every time. I don't know why, I suspect some bug.
I did it once casually while I had a ping running and tcpdump on the output, and there were apparently no outgoing packets on WAN until I did the disable/enable routine. Sorry I don't have more details than that. It is a rare intermittent problem that I can't reproduce on purpose and when it happens it is more of an emergency to restore the internet than an opportunity to figure out why it is happenning.
Note, in this situation I have masquerade on br-lan and snat on wan.
Also, they asked me to create a lo interface with my outside world IP address, I think so that my router responds to pings or something ? Don't know if this has anything to do with the routing bug.
Anyway it works good enough for me and I'll probably make a script to automatically detect when internet stops working and run the uci commands to disable/enable the snat rules and auto-resolve the problem, but I mean, while you're working in there, maybe you'll stumble on the reason why this bug occurs so that's why I'm telling you about this.
Just a gut feeling but maybe the neighbor entry in the ISP side times out or they have hiccups with their routing....
If it's "only" their neighbor cache you could simple send regular unsolicited arp to update their fdb entries... But maybe it's something totally different. Hard to impossible to check from the customer side without internals from the ISP network and setup.
I don't know yet how I am going to make this permanent.
There are occasionnal loss of power so I need something that will autorestart the process. I also need to setup external network storage as this will probably fill the small amount of nvram I have left (my router doesn't have a usb port).
So I will need to make a init process to start and restart these processes, mount a cifs share over the network and pipe all output to files on that mount and handle the cifs share not always being reachable (reboots) without dropping data or hanging on a stale cifs link.
I would it start within a screen or tmux session...
And I think you do not need to monitor the whole arp shizzle. You want to spot for instance incomplete and failed. So grep/filter the ip monitor to exclude the boring shit, and then the write to flash is not that expensive, if there are no other ways for now. You will not run it for like 3 years.... so I would assume its not an issue to write a few kB in the next days....
As I said: YOU can't not spot these kind of issues on the ISP side!
Edit: That's why I said, you could test it by sending regular GARP, like very minute.
If you then do not see the issue any longer you would know its ARP on the ISP side. If it continues to be a problem then you would know, that the issue is probably somewhere else.