I was quick to blame myself for having made a mistake, but it seems my mistake was not observing what didn't work. All of my routes now work except for the one with a different net mask. I can put it back on with an ip route add in putty, but it doesn't work from the gui, so it's not solved.
The startup script is probably executed before the network is up so it can't find the network. But this is speculation, because we still don't know how you get acces to the 192.168.50.0 network - @dave14305 assumed it's the WAN IP via DHCP?
That said, it's still not a good idea to put stuff into a startup script that really belongs to a config file.
2 Likes
I still don't understand your network topology and the actual expected routes, but it is clear to me that your configuration had (maybe still has?) errors.
I really seemed more like you were quick to blame OpenWrt and the volunteer community for the problems.
Add it to the configuration file and remove it from your startup script.... if you need help, you need to provide us with more information about the topology.
2 Likes
So, I was once running into a somewhat non-intuitive issue where I added entries to a list and thought that was it, only to have the entries disappear later and not work at all. In my case that was a simple oversight on my part, I forgot to click the 'save & apply' button after composing my list. Not saying this is what happened to you....
1 Like
I cleaned up that topic title. Be happy the mods are kind enough to tolerate your shenanigans, it's a weird way to ask for help.
2 Likes
"Thank you for the free software, but it sucks balls!
No wait, it wasn't the sw that sucked ..."
3 Likes
so you dissolve it in grease and swallow it instead? Yes, that works well too, just not as rapid or easy.
if it wasn't buggy, you'd have nothing to do here on the forum. I only bought the router because openwrt offered free software without me asking for anything. And there are clearly bugs in the routing. If you haven't noticed them I'd guess that you're not doing much with it.
Otherwise you'd be offering an answer to why my route wouldn't work until I made a second identical entry. I won't waste my time repeating that just so you can be rude. I would if I had a second device.
I think it is a significant stretch to call OpenWrt buggy. Yes, there are bugs, but most of the activity on the forum is about people learning how to use the firmware, especially in the context of more advanced features and networking concepts that may be entirely new to many users.
We did establish that the route entered via the web interface happened to be incorrect. Human mistake - we all do this from time to time - but not a bug.
You are mistaken. My route was fine, as proven by the fact that my command line copy and paste of exactly the same thing worked perfectly. All that had happened is that I'd moved faster than the forum, and could no longer copy the configuration because I'd already changed it. so I edited to answer your request. The only place I made a mistake was in reconstructing an answer to your question.
Otherwise, propose a hypothesis for why my command lines always worked when the gui didn't?
What I know is that there were inconsistencies in what had been presented, as discussed here.
And there were also a few things wrong with the details (like the use of anycast, the source field, etc.).
I know that static routes work properly in OpenWrt, so it was more than likely a typo or other detail that was incorrect in your initial attempt to get it working.
1 Like
perhaps, but that doesn't explain to me why it always worked when I entered the commands myself in an ssh session. Zero problems in ssh, many problems in g.u.i.
It is a bit perplexing to me that you believe that the GUI is buggy because of this. I can tell you that the GUI works perfectly (certainly for simple/basic static routing configs). Occam's razor would suggest that human error for data entry is more likely to be the cause of the problem than a bug in the GUI that only seems to affect your config. Understand that nobody is calling you stupid or incompetent. Mistakes are a human thing, and we as individuals are often too close to our own silly data-entry/typo mistakes to notice them at times, thus making a second set of eyes so valuable in troubleshooting. Maybe you can accept that there was a human error as you setup the static route in the GUI.
Or, if you really believe that you could not have made such a mistake, reset your router (or delete the route) and re-enter it using the GUI to test again and prove that there is a bug. If you do this, make sure you're documenting extensively as you go so that others can reproduce it.... I'll be happy to try. And, if I can repro your issue, I'll have some egg on my face, but I'll own up to it (I almost always leave my errors in view for others, but I will add a note, strikethrough and clarification to make it clear what was wrong and the new info/corrections as necessary)
4 Likes
Too much arguments here!!
Your problem is solved, However I see that you want to know the reason why it did not work through GUI at first place!
To tie-break this dilemma (and if you are really keen to know the reason), then:
-
revert back your environment to first situation where you had the problem, meaning return all configurations as they were when you had the problem.
-
establish Wireshark (downloadable here) monitoring between your router and your browser and analyze the packets (I assume you are technical enough to read, understand and analyze the output of Wireshark).
-
Analyze the logs on your router too to see what happen when you apply the configurations
As pointed out by others there is a reason to use network file instead of startup script and someone even gave to you a reason by speculation. But you want an answer and here you have.
Startup script is run once, after kmod load and when procd signal the boot done. (it written in the comments in the script) This is O.K. for running commands or setup stuff.... Might be NOT ok for network stuff. Due to the fact of late probing, port setup or any other thing, network device might be setup after the procd signal the boot done, resulting in your interface not present and your command not working. Any error from your command is muted so if you want to notice the error I would suggest to redirect it or redirect the output to a file in /tmp. Should give you an error.
Using the network config will take care of creating the route on a network restart and doesn't suffer by this problem.
There is no error in the GUI, this is just using the wrong tool for the task. If you wanted to go maccheroni and implement an overkill solution creating an hotplug script was your choice of combat.
Also my 2 cent... I totally didn't understand how you were angry about not being able to login in a forum... there is nothing special here... it's a plain website with login and signup. 99.999999999999999% of the times it's user fault not being able to login to a website out of angriness.
But anyway happy you solved the problem.
4 Likes
I am pretty sure there would be lots of work to do in this forum, even if OpenWrt was completely bug-free... You just could not imagine the amount of people that comes here asking for help, people who make mistakes with their configuration, and need our assistance.
1 Like
Wow! You guys are super tolerant and helpful. Especially with someone who comes over as pretty damn arrogant. Then again English may not be their first language? Even so it's no excuse really.
Here's how any enquiry should start [by default]
Hi, I have come across this problem and was wondering if anyone can help me?
This is what I tried, this is what happened, and this isn't working for me.
Thanks in advance of you time in replying.
You shouldn't have to but maybe you could add a 'posting etiquette' section to the sign up process?
1 Like
I had exactly same issue described last month. Tried logging in today - worked. Bugs?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.