[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[followmsi]

The Apple support has always been a bit hit or miss. But I remember seeing a post similar to this in another thread (it might have actually been from you) with the exact same experience. For V15, I backported some more avahi changes from 378.55 with the hopes that it might help. Unfortunately, I'm not an Apple user so can't test/debug anything there.

V15 will be coming shortly....we can keep our fingers crossed

Thanks .. Yes, that was me.
At this time I was happy to have a solution at all - using 378.55 on the media bridge only.

But I would love to run both boxes, main router and media bridge, on the same version - on your fork.

I have played with avahi-daemon.conf in /jffs/configs.
No success so far.

Looking forward to V15 !

If you have a test build for me, please let me know.

Thanks for all your work.

 

[followmsi]

Thanks .. Yes, that was me.
At this time I was happy to have a solution at all - using 378.55 on the media bridge only.

But I would love to run both boxes, main router and media bridge, on the same version - on your fork.

I have played with avahi-daemon.conf in /jffs/configs.
No success so far.

Looking forward to V15 !

If you have a test build for me, please let me know.

Thanks for all your work.

For test purposes I have activated minidlna on the RT-AC68 in media bridge mode.
And this service is also not visible/browseable from devices connected to main router.

Maybe it's a general problem for multicast traffic crossing the media bridge ?

 

[john9527]

For test purposes I have activated minidlna on the RT-AC68 in media bridge mode.
And this service is also not visible/browseable from devices connected to main router.

For the minidlna not showing the DLNA server, telnet/ssh to the router and enter

echo 0 > /sys/class/net/br0/bridge/multicast_snooping

I don't have any experience with media bridge mode, so try first on the main router, then the bridge router.

 

[followmsi]

For the minidlna not showing the DLNA server, telnet/ssh to the router and enter

echo 0 > /sys/class/net/br0/bridge/multicast_snooping

I don't have any experience with media bridge mode, so try first on the main router, then the bridge router.

Thanks for your help.

I have disabled mutilcast_snooping first on the main router and then on the media bridge.
no changes at all - still not visible.

the way from pc -> media bridge -> main router seems to work.
I can "see" the dlna on the main router and on the media bridge.

mobile devices -> main router -> media bridge seems not to work.
devices connected to the main router can only "see" the dlna on the main router, not the other one.

multicast_snooping and multicast_router options, on both devices, did not solve the problem.

Maybe I will install 378.55 on the media bridge to test DLNA only.
If it´s working like Air print (both ways) the root cause may has been fixed in 376/378 asus/merlin code.

Still looking forward for V15 !

 

[followmsi]

Thanks for your help.

I have disabled mutilcast_snooping first on the main router and then on the media bridge.
no changes at all - still not visible.

the way from pc -> media bridge -> main router seems to work.
I can "see" the dlna on the main router and on the media bridge.

mobile devices -> main router -> media bridge seems not to work.
devices connected to the main router can only "see" the dlna on the main router, not the other one.

multicast_snooping and multicast_router options, on both devices, did not solve the problem.

Maybe I will install 378.55 on the media bridge to test DLNA only.
If it´s working like Air print (both ways) the root cause may has been fixed in 376/378 asus/merlin code.

Still looking forward for V15 !

I did the test installation of 378.55 on the media bridge only.

DLNA works directly - visible from the complete subnet - crossing the bridge without problems.
Air Print works too, like tested before.

Seems really to be some general multicast problem in 374 code ?

 

[ualdrivr]

Hey John, just updated to your latest Merlin Fork and I get 'Unauthorized DDNS request" popup window, when the router is trying to log into the ASUS.COM DDNS and a little yellow exclamation mark next to my DDNS name, anyone else gets this problem?

 

[john9527]

Hey John, just updated to your latest Merlin Fork and I get 'Unauthorized DDNS request" popup window, when the router is trying to log into the ASUS.COM DDNS and a little yellow exclamation mark next to my DDNS name, anyone else gets this problem?

You're the first to report a problem. I just tried my ASUS DDNS and it worked fine. Have you tried going to the WAN > DDNS tab, double check things and try to Apply from there?

 

[ualdrivr]

You're the first to report a problem. I just tried my ASUS DDNS and it worked fine. Have you tried going to the WAN > DDNS tab, double check things and try to Apply from there?

Yes everything looks normal, the way always does, it just shows unauthorized registration request...! I downgraded to the previous version 13E1 and now it shows it on that as well.

 

[john9527]

@ualdrivr - You should have a syslog entry for the ddns update...anything there? Also, for ASUS DDNS, the registration is tied to the mac address of the router. Did you change anything with mac cloning or are trying to run an account that was registered on another router? Also, do the tried and true reboot?

 

[ualdrivr]

@ualdrivr - You should have a syslog entry for the ddns update...anything there? Also, for ASUS DDNS, the registration is tied to the mac address of the router. Did you change anything with mac cloning or are trying to run an account that was registered on another router? Also, do the tried and true reboot?

None of the above. When I log on to the AiCloud app on my iPhone, it shows the router and everything.

this is something from the system log:

ov 4 13:23:22 rc_service: httpd 549:notify_rc restart_ddns
Nov 4 13:23:22 ddns: clear ddns cache file for server/hostname change
Nov 4 13:23:22 ddns update: ez-ipupdate: starting...
Nov 4 13:23:22 ddns update: connected to ns1.asuscomm.com (103.10.4.108) on port 80.
Nov 4 13:23:24 ddns update: Asus update entry:: return: HTTP/1.1 401 |Authorization failed^M Date: Wed, 04 Nov 2015 18:23:22 GMT^M Server: Apache/2.4.9 (Unix) PHP/5.5.14 OpenSSL/1.0.1h^M X-Powered-By: PHP/5.5.14^M Content-Length: 0^M Content-Type: text/html^M ^M
Nov 4 13:23:24 ddns update: retval= 2, ddns_return_code (,401)
Nov 4 13:23:24 ddns update: asusddns_update: 2
Nov 4 13:28:46 dnsmasq-dhcp[543]: DHCPREQUEST(br0) 192.168.1.208 e0:b9:ba:3e:3f:b3
Nov 4 13:28:46 dnsmasq-dhcp[543]: DHCPACK(br0) 192.168.1.208 e0:b9:ba:3e:3f:b3 Family-iPad-2
Nov 4 13:29:50 rc_service: httpd 549:notify_rc restart_ddns
Nov 4 13:29:50 ddns: clear ddns cache file for server/hostname change

 

[RMerlin]

Did you do any tinkering with your router's MAC address or its bootloader? That could break any existing Asus DDNS account.

 

[john9527]

I'm out of ideas....the syslog shows you're not having any trouble connecting to Asus for the update. Since it now also fails on V13E1 and there were no DDNS changes going to V14E1, I'm inclined to think that Asus is having a problem. If Asus went down in between updates on V13 you wouldn't know it....then V14 forced the update during the reboot. It wouldn't be the first time for an Asus problem. Give it a bit of time and try again.

 

[ualdrivr]

Did you do any tinkering with your router's MAC address or its bootloader? That could break any existing Asus DDNS account.

@RMerlin I don't think so, all I did was upgrade the Firmware today, to 14E1. The router showed the new firmware after the upload, but it never asked to be manually rebooted as it usually does. That was the only unusual thing I noticed, I haven't changed settings in a long time.

I'm out of ideas....the syslog shows you're not having any trouble connecting to Asus for the update. Since it now also fails on V13E1 and there were no DDNS changes going to V14E1, I'm inclined to think that Asus is having a problem. If Asus went down in between updates on V13 you wouldn't know it....then V14 forced the update during the reboot. It wouldn't be the first time for an Asus problem. Give it a bit of time and try again.

Will do. I'll go back to 14E1 as well.

OK this is a huge Doh moment. I upgraded to 14E1 and I also took my Router's manual out, where I keep some notes about my setup and I realized that the name that was appearing on the DDNS was the wrong one. I changed it to the one from my notes and presto, DDNS was alive and well.

Thank you @john9527 and @RMerlin , it was operator error!!!

 

[RMerlin]

Thank you @john9527 and @RMerlin , it was operator error!!!

I lost 90 seconds of my life and I want them back!!!

 

[L&LD]

I lost 90 seconds of my life and I want them back!!!

Sorry, but you roll the dice and take your chances.

 

[ualdrivr]

I lost 90 seconds of my life and I want them back!!!

hahaha how about a beer @RMerlin

 

[john9527]

I lost 90 seconds of my life and I want them back!!!

Thanks for giving me a good laugh!

@ualdrivr - Just glad to hear you got it figured out. Thanks for taking the time to double check things.

 

[john9527]

DLNA works directly - visible from the complete subnet - crossing the bridge without problems.
Air Print works too, like tested before.
Seems really to be some general multicast problem in 374 code ?

Unfortunately, we can't make that statement with certainty. The minidlna level in the fork is different from that in Merlin's code. (1.1.3+ vs 1.1.5) The last time I tried to update to a later level it ended up with a boot-loop on the MIPS based routers, so minidlna is pretty much on hold for now.

I do try and look for potentially large impact commits I can backport (hence the 1.1.3+ level). I just pulled in an additional 3 commits related to SSDP processing which may help out. But overall, DLNA has been quiet on the fork with respect to problems and actually avoided some of the problems encountered on the Merlin builds.

I also double checked if Merlin had done any specific commits relating to media bridge or multicast that I didn't have and couldn't find any. So, if there is a change, it's buried in the big ASUS merges that Merlin does...which unfortunately means it's going to be a bit like looking for a needle in a haystack.

 

[followmsi]

Unfortunately, we can't make that statement with certainty. The minidlna level in the fork is different from that in Merlin's code. (1.1.3+ vs 1.1.5) The last time I tried to update to a later level it ended up with a boot-loop on the MIPS based routers, so minidlna is pretty much on hold for now.

I do try and look for potentially large impact commits I can backport (hence the 1.1.3+ level). I just pulled in an additional 3 commits related to SSDP processing which may help out. But overall, DLNA has been quiet on the fork with respect to problems and actually avoided some of the problems encountered on the Merlin builds.

I also double checked if Merlin had done any specific commits relating to media bridge or multicast that I didn't have and couldn't find any. So, if there is a change, it's buried in the big ASUS merges that Merlin does...which unfortunately means it's going to be a bit like looking for a needle in a haystack.

Thanks for the info.

I will keep testing with the next builds.

Let's wait for V15.

 

[tester]

lol i downgraded from 378.55 to this and now it's blasting wifi into previous areas with no coverage
I've donated to merlin, do you also accept donations?