Unstable R7000 with DDWRT, solid with Stock Firmware

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3  Next
Author Message
dale_gribble39
DD-WRT Guru


Joined: 11 Jun 2022
Posts: 1899

PostPosted: Tue Jun 21, 2022 21:37    Post subject: Reply with quote
Did you test 49268? You should share every bit of detailed information to reproduce the crash. If you haven't ruled out a faulty power adapter, that would also be a good idea.
_________________
"The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost

"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio

<fact>code knows no gender</fact>

This is me, knowing I've ruffled your feathers, and not giving a ****
Some people are still hard-headed.

--------------------------------------
Mac Pro (Mid 2012) - Two 2.4GHz 6-Core Intel Xeon E5645 processors 64GB 1333MHz DDR3 ECC SDRAM OpenSUSE Leap 15.5
Sponsor
Duxa
DD-WRT User


Joined: 16 Aug 2013
Posts: 191

PostPosted: Tue Jun 21, 2022 22:33    Post subject: Reply with quote
got myself r7000 today, about to flash 06-19-2022-r49268 to it. I have serial hooked up to it and will be dumping it. Will report back if I notice anything.

I have a feeling its not hardware issue for him as I have been having really funky stuff with r6300v1on ddwrt as well. Maybe some bug snuck in lately.

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=332368
eolo
DD-WRT Novice


Joined: 04 Dec 2016
Posts: 24

PostPosted: Sun Jun 26, 2022 16:20    Post subject: Reply with quote
dale_gribble39 wrote:
Did you test 49268? You should share every bit of detailed information to reproduce the crash. If you haven't ruled out a faulty power adapter, that would also be a good idea.


After the update that triggered the problem (r44715 --> r48432), I tried several versions (r48305, r43334, r48646) with no success. Inspired by Duxa I'm testing now the last r49326, with CTF / SFE disabled.
I swapped the power supply with the other R7000 in my possession, which has no problems, so I rule out power supply problems.
eolo
DD-WRT Novice


Joined: 04 Dec 2016
Posts: 24

PostPosted: Sun Jun 26, 2022 16:25    Post subject: Reply with quote
Duxa wrote:
got myself r7000 today, about to flash 06-19-2022-r49268 to it. I have serial hooked up to it and will be dumping it. Will report back if I notice anything.

I have a feeling its not hardware issue for him as I have been having really funky stuff with r6300v1on ddwrt as well. Maybe some bug snuck in lately.

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=332368


Thank you so much for your reply. The problem you reported on your r6300v1 appears identical to what happens on my r7000. I recovered the r7000 from the waste bin, installed the r49326 and DISABLED SFE / CTF. I really hope it will resolve.
eolo
DD-WRT Novice


Joined: 04 Dec 2016
Posts: 24

PostPosted: Sun Jul 03, 2022 13:14    Post subject: Workaround identified, thanks to Duxa Reply with quote
Thanks to Duxa's valuable information, I saved my router from being scrapped. With SFE disabled, the uptime is now 7 days (I had never exceeded 4 days before) and now I can put it back in the production environment.
Thanks, thanks and thanks to Duxa!
the-joker
DD-WRT Developer/Maintainer


Joined: 31 Jul 2021
Posts: 2146
Location: All over YOUR webs

PostPosted: Sun Jul 03, 2022 14:23    Post subject: Reply with quote
The R7000 is identically HW wise to my RT-AC68U

There has never been any issue with SFE enabled as what default is, and some Shortcut forwarding optimizations are needed to improve performance. Disabling this is not any kind of decent solution.

When you come from ancient builds and specially KONG which implemented features that may in some cases didn't actually make it into DD-WRT and from general flashing from really old builds to new/current builds. its a must to nvram reset after upgrade and reconfigure from scratch.

This is to ensure that values in nvram variables are reset to defaults or whatever currently is supported and that stale nvram variables and values are removed.

DD-WRT changed a great deal both bakend/front end and to ensure a gremlin free experience its necessary nvram erase every so often especially when weird stuff happens.

You should be able in this case with a clean nvram and latest DD-WRT build to run with SFE enabled and in a stable manner, if you cant, its just down to you if you follow advice or not. Duxa has had his r7000 for two minutes, others here had theirs for years and dont have your issues, so consider that.

In the end if you're happy carry on.

_________________
Saving your retinas from the burn!🔥
DD-WRT Inspired themes for routers
DD-WRT Inspired themes for the phpBB Forum
DD-WRT Inspired themes for the SVN Trac & FTP site
Join in for a chat @ #style_it_themes_public:matrix.org or #style_it_themes:discord

DD-WRT UI Themes Bug Reporting and Discussion thread

Router: ANus RT-AC68U E1 (recognized as C1)
eolo
DD-WRT Novice


Joined: 04 Dec 2016
Posts: 24

PostPosted: Mon Jul 04, 2022 20:18    Post subject: clarification for the-joker Reply with quote
the-joker wrote:
The R7000 is identically HW wise to my RT-AC68U

There has never been any issue with SFE enabled as what default is, and some Shortcut forwarding optimizations are needed to improve performance. Disabling this is not any kind of decent solution.

When you come from ancient builds and specially KONG which implemented features that may in some cases didn't actually make it into DD-WRT and from general flashing from really old builds to new/current builds. its a must to nvram reset after upgrade and reconfigure from scratch.

This is to ensure that values in nvram variables are reset to defaults or whatever currently is supported and that stale nvram variables and values are removed.

DD-WRT changed a great deal both bakend/front end and to ensure a gremlin free experience its necessary nvram erase every so often especially when weird stuff happens.

You should be able in this case with a clean nvram and latest DD-WRT build to run with SFE enabled and in a stable manner, if you cant, its just down to you if you follow advice or not. Duxa has had his r7000 for two minutes, others here had theirs for years and dont have your issues, so consider that.

In the end if you're happy carry on.


Hello the-joker,
If You read my previous post of march, 27, I explained that I have two identical Netgear R7000 router, same CFE and same country of production.

Both router are configured the same, AP ONLY, 2.4GHz with 3 SSID (2 VAP), 5GHz with no VAP, mac filter on the main SSIDs, no QOS, no WAN, no DHCP, no IPv6, no DDNS, no telnet, no tor, no ttraff, no vnc, no zabbix, no freeradius.
Enabled only SNMP, SSH, remote syslog. They differ only in the IP address.

Both were running r44715 from november 2020, and I upgraded to r48432 after discovering mac-filter broken on r44715.

R7000-1 r44715 --> r48432, upgrade from webgui, no configuration reset --> all OK, it's running flawlessy (now uptime over 3 months)

R7000-2 r44715 --> r48432, upgrade from webgui, no configuration reset --> router unresponsive --> reset from button --> manual configuration from gui --> router unresponsive after about 1 day, need power restart --> router reset, reflash with r48432, reconfig from gui --> router unresponsive after about 1 day, need power restart --> router reset, reflash with r48305 --> router unresponsive after about 1 day, need power restart --> changed power supply --> router unresponsive after about 1 day, need power restart --> upgrade from webgui to r48567, router unresponsive after about 1 day, and all attempts detailed in subsequent post.

In the last ten attempts I do "erase nvram && reboot" before and after dd-wrt upgrade.

Only reverting to stock firmware make the router free from sudden failures, so I'm not convinced it's a hardware failure.

Now, with r49326 and SFE disabled, the router is free from failure.

So, I agree with you on "There has never been any issue with SFE enabled as what default is" until now. My problem is not random but reproducible at will.

I have both my R7000 for years, first release was r35244. And I'm using dd-wrt on other routers without problems.

I am not happy that I disabled SFE, and I hope the problem is recognized and solved, I am just glad that I have not scrapped the router.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Mon Jul 04, 2022 21:16    Post subject: Reply with quote
SFE only works for LAN <> WAN troughput.
You have WAN disabled so there is no use for SFE.

You are using VAP's, SFE should disable when using VAP's because it can play tricks on the routing and connection tracking, it does disable on Atheros but not always on Broadcom.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Duxa
DD-WRT User


Joined: 16 Aug 2013
Posts: 191

PostPosted: Tue Jul 05, 2022 7:23    Post subject: Reply with quote
the-joker wrote:
Duxa has had his r7000 for two minutes, others here had theirs for years and dont have your issues, so consider that.

In the end if you're happy carry on.


Appreciate baseless dismissal of my post even though it solved his problem.

I said it before and Ill say it again, ddwrt is a buggy mess as is shown by posts from different people from different parts of the world having the same issues. Just because the router is routing data and their phone connects to wifi does not mean everything is peachy. serial often surfaces really fishy stuff. And Im willing to bet people's routers are crashing and they dont even know it, unless they check uptime, wifi disappearing for 2 minutes is not that easy to catch.

Over the last 2 months Ive tried running ddwrt on 2 different routers, r6300v1, which was prior to that running on FreshTomato for over a year without reboots (solid). It couldnt stay up more than a week on ddwrt without kernel panics. I then got the r7000 as mentioned in previous post. Again, within a week get random crashes.

I've reported enough, none of it got taken seriously. Because some dude has some router somewhere who is having no issues. Good for him. Does that dude have even 180 day uptime on it? Doubtful. ddwrt makes a build every 3 to 4 days. So you have a dozen people reflashing their router (resulting in reboot and refresh) every 3 to 4 days and if not 3 to 4 days then a few weeks. All this data gives you is that the particular router boots with new build. Thats it. Zero data on stability over 3 months, 6 months, a year, 2 years...

Anyways, ill be lurking around here to help those in need (big lack of that around here). But I switched both my routers back to FreshTomato. At least r7000 has full (and stable) CTF support on FreshTomato. Been up longer than ddwrt could manage, and zero errors in logs or on serial, no crashes, no weirdness, it just works.

Alright rant over. But I seriously get the vibes that people on here number one objective is to deflect all blame from ddwrt and find ways to blame the power supply, or config, or person at the keyboard. Its never an issue with the software. Kind of blasphemous for you Joker after quoting 99 little bugs in the code (its been hanging on my wall for years now in a frame with the grumpy cat.)

Why am I still here? Because I wish ddwrt was better.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Tue Jul 05, 2022 7:44    Post subject: Reply with quote
I run my EA8500 and R7800 for weeks and sometimes for months without problems. EA8500 is the OpenVPN and WireGuard server with NAS, the R7800 is the main gateway

I administer many R6400v1, v2 and R7000 which runs for weeks/months without problems, but these are mostly simple setup as gateway sometimes as WAP and do provide routing and wifi/VAP.

I personally use CTF, but I use my R6400v1 for development so it is not up longer than a week, during that time I have no stability problems.
The other routers have bandwiths below 300 Mb/s so are not using CTF (or SFE) so I cannot vouch for CTF

Not saying there are no bugs, the ones I have found are very fast resolved after I send (serial) log.

But I am sorry to hear you have other experiences

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Duxa
DD-WRT User


Joined: 16 Aug 2013
Posts: 191

PostPosted: Tue Jul 05, 2022 8:12    Post subject: Reply with quote
egc wrote:
I run my EA8500 and R7800 for weeks and sometimes for months without problems. EA8500 is the OpenVPN and WireGuard server with NAS, the R7800 is the main gateway

I administer many R6400v1, v2 and R7000 which runs for weeks/months without problems, but these are mostly simple setup as gateway sometimes as WAP and do provide routing and wifi/VAP.

I personally use CTF, but I use my R6400v1 for development so it is not up longer than a week, during that time I have no stability problems.
The other routers have bandwiths below 300 Mb/s so are not using CTF (or SFE) so I cannot vouch for CTF

Not saying there are no bugs, the ones I have found are very fast resolved after I send (serial) log.

But I am sorry to hear you have other experiences


I am sure there are configurations that are completely fine and stable (for instance no SFE/CTF usage). Your config couldnt be more different from mine, I dont use WireGuard, or NAS, or VAPs. Maybe for those things its super stable. I dont know. But at the same time I wouldnt just be sitting here and make up stories about my routers crashing while running ddwrt. Its happening. I could pull down the repo and start reading through the code, but I dont have the time for that. So best I can do is report it. But those efforts have just been dismissed.

For my use cases I must have CTF or SFE (r6300v1 is not fast enough for 300Megabit WAN without them). I need OpenVPN, I need access restrictions (for blocking devices during certain times), I need static IPs. Most importantly I need it to be rock solid, I have whole family constantly using wifi and even when they dont use it, wifi going down will often break devices like Amazon Alexa (needs power cycle to reconnect), or security cameras etc.

To be honest I was shocked when I was out of the house and got a call "internet is down", this was 7 days after installing ddwrt and it having been running flawlessly for those 7 days. Culprit of internet down, kernel panic. Followed by some other racing condition during boot (only present with ddwrt), which hangs the router on boot (reboot 10 times and it will happen, reboot 100 times with non ddwrt, wont happen). So router crashed, rebooted and was stuck on boot. I was out of the house for hours, so no internet for hours.

On both routers Ive looked at serial output and there are a ton of driver errors, eth errors. Errors that simply should not be there. All that stuff needs major cleanup. And like I said race condition with vlan creation that should be fixed. The thing is, it could be an issue specific to r6300v1, which is old and hardly used, so may never get fixed.

I used ddwrt for a decade, maybe longer mid 2000's to late 2010's, and it was always super solid. So yeah, I am a bit disappointed with my recent experience.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Tue Jul 05, 2022 8:45    Post subject: Reply with quote
Indeed the R6300v1 is a totally different beast then the routers I was referring to.
Single core MIPS 600 MHz versus Broadcom Arm Northstar dual core 800 MHz (and more)

Internal switching fabric is also different so, I think, only CTF and no CTF + FA (which is preferred and gives almost full gig speed)

As stated earlier/elsewhere SFE can play tricks on routing and connection tracking which can led to problems when running OpenVPN and VAP's. So be careful with that

Edit: it does not mean that it should not work on older MIPS but they are less used and tested so presumably have more bugs Sad

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
the-joker
DD-WRT Developer/Maintainer


Joined: 31 Jul 2021
Posts: 2146
Location: All over YOUR webs

PostPosted: Tue Jul 05, 2022 9:34    Post subject: Reply with quote
Duxa wrote:
Appreciate baseless dismissal of my post even though it solved his problem

Disabling SFE is not any kind of acceptable solution, even if in this cased it helped.

Allow me to clarify my statements from a perspective of over 30 years of experience in many opensource projects as a developer, user or support provider.

Also allow me to clarify the reality of development and associated issues that are pertinent to this clarification. Most of what I will type, anyone who actually does any development will likely find to be an echo of sorts to issues faced as a developer/support provider in a general sense.

Based on any random bug reports on forums or trac in any project and DD-WRT specifically, most users do not have a solid understanding what DD-WRT is and what 3rd party components are which the later is everything that is developed and currently maintained by 3rd parties and simply used as a component within DD-WRT to give a specific functionality.

It is crucial to clarify the above, without this understanding, users cannot help make a project better if they so truly desire.

Examples of some 3rd party components specifically SFE / CTF / CTF & FA or any Broadcom drivers and others are closed source and very hard to maintain/patch.

Even the opensource stuff like SFE is not maintained by DD-WRT (the project) even if at times patches go into these to fix some issues in specific components, its not DD-WRTS responsibility/job to patch currently maintained 3rd party projects (in an ideal world said patches would be submitted upstream to fix an issue but this presents other challenges that I wont get into here because its not a simple open and shut case neither opensource or closed source wise), its their respective developers/maintainers and they dont know often that a specific issue exists, these 3rd party developers dont come reading every project like DD-WRT forums/trac or other projects that uses their library or component to find bugs in their stuff. Would anyone? (some do but its really rare)

So, reporting some bugs/instability and issues that only become obvious in certain setups where any of these 3rd party projects may be at fault is nothing todo with DD-WRT, it appears so to the untrained eye and it triggers remarks like yours about DD-WRT bugs because it was found in DD-WRT so it must be DD-WRT! Not really that simple.

Some issues are caused by conflicting settings and user error, when asking for support, rare are the users who provide serial outputs or screenshots of their setups, and thus hard to know what and where the issue maybe. An issue which is slowly being resolved is the fact DD-WRT allows users to configure things with conflicting/incompatible settings, this cant be solved simply, requires much development time and intimate understanding of how things interlink. Like Any project DD-WRT needs experienced developers, not everyone is willing to work for free but those are other issues not relevant specifically in this case.

Some bug/issues reports clearly belong upstream in the relevant 3rd party projects, yet none are reported there and no one associated with project is going to use their personal time to report the issues upstream and thus some issues will linger in DD-WRT as a whole and in addition said project developers like I already mentioned will remain unaware and bugs will remain also in their projects.

So I wasn't being dismissive without any actual basis in facts (it may appear like that to you on the surface, but its not correct and quoting something out of context just prompts me to clarify the situation as its been for years and years and years and will remain so for years to come).

Pointing out that disabling a crucial portion to workaround some issue (is not any kind of solution) where still no concrete evidence by reporter (we dont have a single screenshot of setups just text and description of symptoms) and a workaround.

To determine where issue actually is and where the bug lies we need actual actionable information, and in the absence of this, any complaints are moot, no one is going to go though lines and lines of code and blindly fix stuff, developers need a starting point and actionable information is a must. I'll give you several examples of bugs that were fixed recently with R7000P 5Ghz radio, or where R9000 was left practically unusable because of simply activating the 60Ghz option where users without this enabled saw any issues at all, both were fixed because actionable information was available (eventually) and the developer was able to duplicate. Without either actionable information and reliable duplication both issues would still exist.

Now I hope that these facts offered as a rationale to the open discussion have helped clear up why some issues exist and why some go unfixed for a long time and why workarounds are not any kind of solution that will have any affect on fixing any real underlying problems, neither DD-WRT side directly or 3rd party components/libraries.

And to end, go see all R7000 reports in build threads. As members of the community that provide support to other users we need help from said users in order to help them better.

_________________
Saving your retinas from the burn!🔥
DD-WRT Inspired themes for routers
DD-WRT Inspired themes for the phpBB Forum
DD-WRT Inspired themes for the SVN Trac & FTP site
Join in for a chat @ #style_it_themes_public:matrix.org or #style_it_themes:discord

DD-WRT UI Themes Bug Reporting and Discussion thread

Router: ANus RT-AC68U E1 (recognized as C1)
Duxa
DD-WRT User


Joined: 16 Aug 2013
Posts: 191

PostPosted: Tue Jul 05, 2022 18:14    Post subject: Reply with quote
Joker, you are echoing what I would assume most people interested in ddwrt already know. Nothing revelatory here.

My issue with how things are being handled is not that everyone doesn’t drop everything and fixes the bugs specific to me. No I would never expect that. I also understand very well that some bugs are unfixable (binary blobs) and some need to be fixed in upstream projects. That’s all understood.

The issue (and I think this is where the misunderstanding between you and I is) is that there is refusal to acknowledge that there is an issue in the first place. The first reaction is “no it can’t be, it’s an issue with you, not ddwrt”. (By the way if an issue is caused by broken upstream project and breaks ddwrt in my book it’s an issue with ddwrt (as well as upstream project). If I sell someone a car and the windshield is blurry I can’t just say, car is totally fine, it’s a problem with glass manufacturer. No it’s a problem with the car.

For example with r6300v1. I was having major stability problems, kept testing various settings and posting about it, eventually figuring out that CTF on that router causes kernel panics. The issue is that all meanwhile I was posting my findings the echo chamber here was saying “there is no issue”. While there clearly was.

I don’t expect any fixes for it (binary blob and all, but I do expect acknowledgement of the issue, that way it can get documented and be useful to others that may experience it).

So to be clear. When I post “yo there is an issue” I don’t expect everyone to drop everything and fix it. I expect it to at least be considered a real issue instead of “oh it can’t be guy x has similar hardware and has no issues”, there isn’t big enough sample size of ddwrt users and even data from current users is lacking to be able to claim anything regarding stability.

Tomato actually implemented a very smart thing way back when they started, you can volunteer router data (build, model, uptime) so you can always pull up their site, find your router and see uptime on specific builds. This gives a greater degree of confidence in stability. By no means I am saying that ddwrt needs to do something similar. I am just saying those kind of stats on stability are completely missing from ddwrt.
the-joker
DD-WRT Developer/Maintainer


Joined: 31 Jul 2021
Posts: 2146
Location: All over YOUR webs

PostPosted: Tue Jul 05, 2022 18:48    Post subject: Reply with quote
I dont represent or am in any way associated with DD-WRT beyond being a user and contributor and my opinions and views expressed are my own, valid or not and beyond this, I have no say in which direction the project goes or what is fixed or not or how that is handled post reporting.

@Duxa.

Thanks for coming back, its always nice to have a open and respectful discussion of different points. However, all your latest post is 99% offtopic in this thread, nothing about any of the discussions until then are pertinent to your issues specifically, while some latitude is understood and accepted, it wasn't about you duxa, my mistake for directing my previous reply to you, it was meant for the community as a whole, it really really was.

We can indeed have a open discussion about what your feelings are on how things could have been better handled in respects to your issues in your relevant thread, so we dont just hijack this thread in such a manner that we both are being rude to the OP in a small way, at least, I feel a little guilty of hijacking per each keystroke furthering this post.

I hope however my long reply to you and meant for all. in specific was educational to the community at large, because unfortunately we cant compare DD-WRT to a car with a faulty windshield, would be nice however and many projects and users wouldn't face the issues they continue facing and have faced for years and wont change easily, to improve both sides have to meet in the middle, easier said than done.

As for the OP issue, in order to get to the bottom of it, we need data, screenshots of the setup up to the time issues are noticed, so we start building a bigger picture and try to narrow down where the issue is or how to fix it. A workaround is great to stop the immediate problem but stops the actual real issue from being hunted down cornered hunted killed and fixed into a lovely soup.

Personalty I'm equally OK with OP accepting workaround and moving on, there are always bigger fish to fry.

Respectfully signing out and @duxa feel free to ping me on your thread

Thanks to all for understanding and apologies for interruptions.

_________________
Saving your retinas from the burn!🔥
DD-WRT Inspired themes for routers
DD-WRT Inspired themes for the phpBB Forum
DD-WRT Inspired themes for the SVN Trac & FTP site
Join in for a chat @ #style_it_themes_public:matrix.org or #style_it_themes:discord

DD-WRT UI Themes Bug Reporting and Discussion thread

Router: ANus RT-AC68U E1 (recognized as C1)
Goto page Previous  1, 2, 3  Next Display posts from previous:    Page 2 of 3
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum