What's new

Padavan's Custom Firmware

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

So far I am liking the newest firmware (RT-N56U_1.1.2.3-010). But for the life of me I can't find the IPv6 settings. :confused: Where did it go? I've cleared my browser cache but I can't find it.
 
So far I am liking the newest firmware (RT-N56U_1.1.2.3-010). But for the life of me I can't find the IPv6 settings. :confused: Where did it go? I've cleared my browser cache but I can't find it.

Yes, I asked the same question in the article review thread some ago, I couldn't find them, either. Maybe there's a secret mode switch somewhere, or they just haven't put them into the new GUI yet. After looking at the new Padavan GUI, I switched to the new Asus Beta firmware, the IPv6 settings are obvious in the GUI there *smile*. And both versions of firmware are functional for my use of the router.
 
Last edited:
Actually, I just need IPv6 on the LAN side for right now. My ISP hasn't implemented IPv6 on the WAN side, yet. :rolleyes:
 
I noticed the longest DHCP lease time I can select is 7 days. I don't know if this has always been the case. I'm only noticing this recently because my new EA-N66 AP, when it gets a new lease, drops all it's wireless clients and they switch over to my RT-N56.(I'm using 2.4GHz on the Rt-N56u and 5Ghz with the EA-N66)

So I was going to increase the lease time to 30 days or something longer and found out that the max time I can input is 604800 seconds.
I never had this issue with my Dlink APs so I'm not sure why the EA-N66 would drop it's wireless clients when the lease is renewed.

But why is there such a short restriction on the lease time with this firmware for the RT-N56U?
Why can't it be made longer?
 
Last edited:
Have you tried setting it to 0? On many firmwares this means "never expire". This might be more appropriate for your specific usage.
 
Have you tried setting it to 0? On many firmwares this means "never expire". This might be more appropriate for your specific usage.

I'll give that a try, thanks.

EDIT: the minimum value is 120. It won't let me input anything below 120 or above 604800.
 
I only just noticed the donate button on the custom firmware website. I just donated a few bucks. Maybe that can help with getting a longer lease time in the firmware.:D

Anyway I've been using the last few versions of this custom firmware. It has been much better than the couple of official Asus firmwares and the Asus Beta firmware I tried.
 
Last edited:
I only just noticed the donate button on the custom firmware website. I just donated a few bucks. Maybe that can help with getting a longer lease time in the firmware.:D

Anyway I've been using the last few versions of this custom firmware. It has been much better than the couple of official Asus firmwares and the Asus Beta firmware I tried.

There's a chance you might be able to manually set it over telnet. Unfortunately I'm not familiar with this firmware, so I have no idea what's the command to manipulate the nvram content, or the name of the field that contains those static leases.
 
If you want indefinite DHCP leases, just reserve the IP's by MAC address. Or set your devices with static IP's, and adjust your DHCP range.

Example:
Set your DHCP range to 192.168.1.100-254
Statically assign your devices in the 192.168.1.2-99 range.

Setting your DHCP to indefinite leases, somewhat defeats the idea of DHCP. IHMO

Oh, I found out that Pavadan pulled IPv6 out of the current builds for technical reasons. I'm not sure of the actual reasons (language translation software doesn't work for all topics), but he does plan on putting it back in when he figures it out.
 
If you want indefinite DHCP leases, just reserve the IP's by MAC address. Or set your devices with static IP's, and adjust your DHCP range.

Example:
Set your DHCP range to 192.168.1.100-254
Statically assign your devices in the 192.168.1.2-99 range.

Setting your DHCP to indefinite leases, somewhat defeats the idea of DHCP. IHMO

Oh, I found out that Pavadan pulled IPv6 out of the current builds for technical reasons. I'm not sure of the actual reasons (language translation software doesn't work for all topics), but he does plan on putting it back in when he figures it out.
If I understand what you are writing, it is not pulled out, and just adds support for Ipv6.
 
aaronwt
As Guz properly noted, setting indefinite DHCP leases defeats the purpose of DHCP. It is much better to use dynamic leases with static leases in conjunction, e.g. you have a host, which MAC address is known to you. Assign an IP to that specific MAC address manually through the router's WebGUI, so whenever that host enters the LAN, it will get the predefined IP automatically.

All the new MAC address simply get a random IP from specific pool (e.g. 192.168.1.100-192.168.1.254

Also, thank you for your support!

Now to the IPv6 support. Actually nobody pulled out IPv6 from this firmware and there's no secret switch. It was never here in the first place. Right now it's a work in progress. This firmware is notably different form current official 3.x.x.x ASUS builds, hence no IPv6 as of now. It uses different kernel, it has no redundant code, HW_NAT function of the Router was optimized and user has way more control over it. There are much more differences including web interface, other features and so on. You can familiarize yourself with some of them reading changenotes.

You may follow the project closely on google code. Specifically here: https://code.google.com/p/rt-n56u/source/list

Don't mind the broken English. We're working on improving it. ;) You also may expect newer builds with corrected English in WebGUI.

Also please note that as of yesterday it is not advised to compile builds after the 7a0296492b08 commit, since the project is undergoing an active phase of IPv6 integration and the IPv6 release is extremely close.

You can ask your questions about this firmware here and I'll try to answer them or redirect them to the devs if that would be necessary.

And yeah, there's this page here: https://code.google.com/p/rt-n56u/issues/list , although it is not checked as regularly as it should be :)
 
Last edited:
Now to the IPv6 support. Actually nobody pulled out IPv6 from this firmware and there's no secret switch. It was never here in the first place.
Oops. My bad. I could have sworn there was a build with IPv6 at one time. But my excuse is that I've been trying every firmware and I sometimes get confused as to what is in what. :p

Also, I've been trying to keep up on the Russian discussion forum. But using Google and Bing language translations isn't perfect, as it really messed up the discussion on IPv6. (Now that I look back, Google and Bing really SUCK at trying to translate from one language to another)

Example, your original post:
Ок, простыня выстлана. Постараюсь следить за темой и в меру своих способностей (и пользуясь этой веткой) разрешать всякие проблемы, вроде бесконечного лизинга IP по DHCP

Добавление от 03.09.2012 14:58:

И вообще надо бы раскрутить это дело. Я чуть позже попробую связаться с топикстартером и попросить его украсить первый псто. А также можно будет сунуть фрагмент на английском в шаблон первого псто нашей ветки с ссылкой туда.
Translated:
OK, is lined with a bed sheet. Will try to follow the theme and to the best of my ability (and taking advantage of this branch line) to allow all sorts of problems, like an infinite lease IP via DHCP

Addendum dated 03.09.2012 14:58:

And in general it is necessary to untwist it. I'll try later to contact topikstarterom and ask him to decorate the first psto. And also you can shove a piece in English in the first template of our branches with reference psto there.

Weird, huh?

BTW, I don't post there, since I'm not fluent in Russian. But I do lurk, so please extend my apologies to Pavadan for the IPv6 confusion.
And yeah, there's this page here: https://code.google.com/p/rt-n56u/issues/list , although it is not checked as regularly as it should be :)
I noticed that. Hopefully that will improve.
 
Last edited:
Fully acknowledged :) The printing issue described there (ID: 222) exists at least since build 1.1.1.8e-b3 and has been reportet first in April... Hope the flaw will be adjusted soon.


Yeah, well as you understand, that's a matter of printer model<->driver<->OS compatibility. It's not even remotely possible to test every printer model. There's also not much to fix since all printers are expected to work similarly using the same protocols, talking in the same way, etc.

I can confirm that this feature works since I'm using Epson Stylus Photo TX650 and have no problems whatsoever. So we need to troubleshoot your specific case. As I see, you're the one who has Kyocera FS-1300 D, right? Looking at the pictures that's a simple laser printer, not an 'all-in-one' device. That means you can avoid using proprietary USB-over-Ethernet thing, which Asus has licensed from a third party, and resort to using of TCP/IP printing:

1. Disconnect (or simply disable) your printer from the router and remove the printer from the host OS.
2. Connect (enable) the printer. Now, assuming you're on the Padavan's firmware, go here: http://my.router/Advanced_Printer_others.asp and disable 'USB-over-Ethernet'. Also check that LPR port is enabled. Hit apply.
3. Now (again, assuming you're running Windows 7) go to Control Panel\Hardware and Sound\Devices and Printers and press 'add a printer'.
4. Choose 'Add a local printer'
5. Choose 'Create a new port' and in drop-down menu select 'standard TCP/IP port', then hit next.
6. In the 'Hostname or IP address' enter the router's IP address and untick 'Query the printer and automatically select the driver to use'. Hit next.
7. Wait a bit. Windows might not find the printer. That's expected.
8. On the next step leave the drop-down menu on the 'Generic Network Card' and hit next.
9. Choose proper driver. If you had your printer drivers installed previously, you'll find them in the list. If not then proceed as usual (have disk -> bhah blah)
10. If the installation wizard asks you which version of driver to use, you may select the first option. It is ok to use installed driver. Press next.
11. Give this printer desired name and press next.
12. Do not share the printer (why would you want to do it anyway, it's on Router, duh :) )
13. After this process is finished, you'll see your printer in the device list. Right click it and select 'Printer properties' -> 'Ports' tab -> Press 'configure port' button. Change it from RAW to LPR.
14. Try to print a test page.

If it works ok, you might want to experiment with RAW protocol. You may also fiddle with bi-directional RAW port in router settings. I don't remember for sure what it will give you but AFAIK it's better than LPR protocol. It has something to do with printer drivers having more control over the device or something like that.

Hope this helped you.

Guz,

Haha, no worries. No harm done!

As I've noticed, Google is more adept with translations. It spitted out almost readable variant excluding puns :) Also, spoken language is rather a headache for automated translation systems so no wonder google and bing 'fudged' up big time.
 
Last edited:
aaronwt
As Guz properly noted, setting indefinite DHCP leases defeats the purpose of DHCP. It is much better to use dynamic leases with static leases in conjunction, e.g. you have a host, which MAC address is known to you. Assign an IP to that specific MAC address manually through the router's WebGUI, so whenever that host enters the LAN, it will get the predefined IP automatically.

All the new MAC address simply get a random IP from specific pool (e.g. 192.168.1.100-192.168.1.254

Also, thank you for your support!

................

Is there still a 24 device limit? My problem is I have over sixty devices on my network so I have to be stingy with my reservations. I haven't tried with the recent firmware but with the previous one it said the limit was 24.

My EA-N66 is the first network device out of hundreds I've used over the last 15 years that will not accept my internal 221.214.xx.xxx IP address range if assigning a static IP in the device. So I have to assign it by DHCP reservation in my RT-N56U. So I had to remove another reservation to make room for the EA-N66.
Although I've never used any ASUS network devices before, until this Summer.
 
Last edited:
Yeah, well as you understand, that's a matter of printer model<->driver<->OS compatibility. It's not even remotely possible to test every printer model. There's also not much to fix since all printers are expected to work similarly using the same protocols, talking in the same way, etc.

Tx vmi for your elaborate response... BUT (;)) ...:

I guess it would be too easy to attribute the existing issue only to single printers that are handling processes in a different (wrong) way. Issue 222 is reported by other users too who use different printers. The explanation of wolfgang.griech@... who assumes that the printer driver keeps sending instead of doing some handshake with the printer although the internal buffer of the printer is filled really sounds cogently as it describes what is happening in realiter (only the first few pages of a larger print volume are printed, then printing stops with an error message).

Taking that granted this would suggest that the printer driver implemented by Padavans builds should be compared with the stock FW driver of Asus as the issue doesn't occur when using the original Asus firmware - here the printer works as it should...

That means you can avoid using proprietary USB-over-Ethernet thing, which Asus has licensed from a third party, and resort to using of TCP/IP printing:

1. Disconnect (or simply disable) your printer from the router and remove the printer from the host OS.
2. ...

Hope this helped you.

Sorry to say not really... I've tried all this variations earlier and didn't succeed. The only workaround till now is to re-flash stock firmware :(

But nevertheless tx for trying to help and for your readiness to invest your valuable time in my problem...
 
You see, I'm not trying to brush aside that problem. It's just majority of the users reported back that the printing is working well with current firmware. Padavan himself has a printer and uses proprietary Usb-over-ethernet drivers and it also works fine. I'm going to repeat myself but I as I said I too have printer and I assure you I print much more than two pages per day.

There was some widespread issue with HP printers but we narrowed it down to specific line of products which require additional tweaking with them.

Could you please elaborate more on what connections exactly have you tried (specifically have you tried TCP/IP bi-directional RAW. Was the printer working in this mode?). Was the printer's behavior the same in all cases?

Could you please also attach the full log of the latest firmware with the unsuccessful printing attempt (not an extract of it)? It will also help to troubleshoot that case.
 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top