Strange issue with Arris TM1602AP2 and R7800

[kamoj]

The same issue you noticed, exist in both net-wan and net-br
That can be patched like this:

sed -i 's/h $DHCPNAME/h $u_hostname/g' /etc/init.d/net-br
sed -i 's/h $DHCPNAME/h $u_hostname/g' /etc/init.d/net-wan

and a reboot.
PS
Patches will not survive a FW update.
PPS
To uninstall these patches:

\cp -p /rom/etc/init.d/net-br  /etc/init.d/net-br
\cp -p /rom/etc/init.d/net-wan  /etc/init.d/net-wan

I have not given up yet, been trying things all week and learning alot about this little box.
I am currently pursuing udhcpc and I used echo into a temp file to save the command line used.
I am talking about the line which starts "udhcpc -b -i $WAN_IF -h $DHCPNAME -r $($CONFIG get wan_dhcp_ipaddr)"
in setup_interface_dhcp().

grabbing that line reveals:
udhcpc -b -i brwan -h /tmp/dhcp_name.conf -r xxx.xxx.xxx.236 -N xxx.xxx.xxx.236

in other words the host name passed in is "/tmp/dhcp_name.conf" instead of it's contents "R7800"
doesn't really affect the connection per-se, but seems wrong none the less.

Really puzzles me that .62 works fine and .63 and later don't. Without re-flashing my box is it possible to get net-wan from .62?

Also - i expected I would see two passes through this setup_interface_dhcp().
1 ) for initial boot
2) after I unplug-count 5-plug the WAN wire

 

[NetBytes]

Thanks for your reply and info kamoj.
In the net-wan for the 7800, in the setup_interface_dhcp() the variable which is misused is u_hostname.
This variable is actually set correctly to R7800 (just not used), so I have modified my net-wan to use it instead.
Does not fix my original issue, but a correction none the less.
These changes wont last a firmware update I know, but for those interested:

setup_interface_dhcp()
{
local mtu
local u_hostname
local u_wan_domain=$($CONFIG get wan_domain)

mtu=$($CONFIG get wan_dhcp_mtu)
ifconfig $WAN_IF mtu ${mtu:-1500}

if [ "x$($CONFIG get wan_hostname)" != "x" ];then
u_hostname=$($CONFIG get wan_hostname)
else
u_hostname=$($CONFIG get Device_name)
fi
echo $u_hostname > $DHCPNAME

#echo "udhcpc -b -i $WAN_IF -h $DHCPNAME -r $($CONFIG get wan_dhcp_ipadd
echo "udhcpc -b -i $WAN_IF -h $u_hostname -r $($CONFIG get wan_dhcp_ipad

if [ "$changing_mode" = "1" ]; then
#udhcpc -b -i $WAN_IF -h $DHCPNAME -r $($CONFIG get wan_dhcp_ipa
udhcpc -b -i $WAN_IF -h $u_hostname -r $($CONFIG get wan_dhcp_ip
else
#udhcpc -b -i $WAN_IF -h $DHCPNAME -r $($CONFIG get wan_dhcp_ipa
udhcpc -b -i $WAN_IF -h $u_hostname -r $($CONFIG get wan_dhcp_ip
fi
}

 

[NetBytes]

I've done the hard thing I really didn't want to do, but I decided must be done. I reverted back to 62SF.
It's a damn painful process because of the password encryption changes and the router tried to lock me out.
HOWEVER that said - I can absolutely confirm the router running 62SF auto-reconnects.
So it's not a hardware issue, at least for me.
I have saved images of both versions filesystems and am starting comparisons to hopefully find
the 'magic' to get a 72SF to auto-reconnect. stay tuned...

 

[NetBytes]

I am glad I did the experiment. I was hoping that dropping the 62SF net-wan into a 72SF router would solve the issue.
It does not. So I have learned the problem in not in net-wan.

 

[NetBytes]

Last bit for tonight. I tried swapping the 72SF versions with the 62SF versions of
net-wan, enet, net-br, wlan-common and udhcpc - all no fix problem.

I can place nearly any 62SF file onto my running 72SF system now to see if it helps.
Any ideas where to stab?

 

[kamoj]

Have you looked in the dmesg and syslogs yet?
It's probably easier to to analyze the problem than doing a brute-force approach.

To your question:
I would start to look at the difference between 62SF to 63SF.
Since you have a problem at boot, try to look first in /etc/init.d, where e.g. these files are changed from 62SF to 63SF:
/etc/init.d/boot
/etc/init.d/dnsmasq
/etc/init.d/done
/etc/init.d/net-lan

Other files that changed are e.g.:
/sbin/net-util

The file normally responsible for new problems is the binary blob /usr/sbin/net-cgi.
Changing this file is not recommended since it will probably "soft-brick" your router -
and you have to restore router using tftp.
(I have tried many times )

 

[Voxel]

I've done the hard thing I really didn't want to do, but I decided must be done. I reverted back to 62SF.
It's a damn painful process because of the password encryption changes and the router tried to lock me out.
HOWEVER that said - I can absolutely confirm the router running 62SF auto-reconnects.
So it's not a hardware issue, at least for me.
I have saved images of both versions filesystems and am starting comparisons to hopefully find
the 'magic' to get a 72SF to auto-reconnect. stay tuned...

Try to disable /etc/init.d/modem script (one more experiment):

/etc/init.d/modem disable

Voxel.

 

[MikeRS]

Ever since I switched from Verizon (fiber) to Optimum (cable modem), I need to physically unplug the Ethernet connection between the cable modem and the router whenever I reboot the router to successfully connect to the Internet. I never had this issue with the Ethernet connection to the ONT.

Is there a setting on either the cable modem or router that might fix this issue?

I had the same issue with my with Optimum issued Arris modem and the R7800. I would randomly have the ethernet ports on the router not work, while wifi was just fine. I had to constantly physically unplug my router AND modem to get my ethernet ports working again. If i just unplugged/restarted the router, they still didn't work. This was a huge pain because my entire house is wired so everything possible was hardwired in. The drops got to a point where they were happening every 36-48 hours. I originally assumed it was a router issue and flashed all different kinds of firmware and updates but nothing helped.

I finally decided to buy a NETGEAR CM600 to replace my Arris to see if a different modem did the trick (as well as to get rid of the $10 month modem rental fee) and then the issue completely went away as soon as I registered it. I can't remember the last I had my network go down or require a restart/reboot. Long story short, try replacing your modem (I'd recommend the CM600 if you are looking for recommendations as it works flawlessly with Optimum 300) and hopefully that solves your issues as well.

 

[NetBytes]

I am 1000% sure this is a software issue and not hardware, as you can see by my testing.
While new hardware might solve the problem on an individual basis, iff (big if) I can find
why .62SF connects with no problems, but subsequent ones do not, I might help Voxel/everyone.
I am beginning to think it is a compiled program and not a script but more testing required.

I've got Voxel's suggestion above pending.
The going has been slow, but I hope I can find it.

BTW - thanks for confirming a modem which does work should I finally give in and replace the cable modem.

 

[pec]

I would randomly have the ethernet ports on the router not work, while wifi was just fine.

Do you have an Xbox connected to an Ethernet port on the R7800? If so, connecting the XBox via Wi-Fi or putting an Ethernet switch between the XBox and the R7800 fixes the problem of the Ethernet ports periodically not working. For some, disabling "Instant On" in the XBox works as well.

 

[NetBytes]

Do you have an Xbox connected to an Ethernet port on the R7800? If so, connecting the XBox via Wi-Fi or putting an Ethernet switch between the XBox and the R7800 fixes the problem of the Ethernet ports periodically not working. For some, disabling "Instant On" in the XBox works as well.

No Xbox involved.
With all devices attached the reboot works on .62SF and fails on newer Firmware.

 

[NetBytes]

sad to report that "/etc/init.d/modem disable" does not help.

Edit: also full replacement of the modem script with the .62 version also does not help.

 

[NetBytes]

In /etc/init.d the following are the only files with variations from .62 to .72.
Any help where else I should look would be appreciated.
Short of putting all .62 init.d files into my .72 box don't know what else to do.
I've been looking at the complete filesystems for both versions. Open to nearly all suggestions.
It's clearly software, flash & boot .62 and it works perfectly, anything else - no auto reconnect.


dnscrypt-proxy-2 ==> mostly to create a symlink to .toml file
dnsmasq ==> start moved from 61 to 60
done ==> security enhancement
modem ==> lots (but no help as using the .62 version doesn't fix the issue)
net-br ==> lots
net-lan ==> funjsq.sh referenced but ultimately not used (I commented the line out)
net-wan ==> lots (been over this a lot)
openvpn ==> lots
openvpn-client
powerctl ==> start moved to 98 from 99
wlan-common

 

[Bichon]

I am pretty sure I figured out what is causing this problem. For the first 30 seconds or so after rebooting the router with Voxel 72F firmware, while the leftmost light on the router is still amber, the WAN port is acting as another LAN port.

More specifically, I powered off the router, then connected a laptop running Wireshark to the WAN port of my R7800, and started a capture. Much to my surprise, as soon as I powered on the router, I started seeing traffic from the INSIDE of my network. For example my main desktop sending ARP packets looking for the inside address of the router, among others. As soon as the leftmost light on the router turned white, traffic from inside the network ceased. From that point on, the communications were all from the WAN MAC address of the router, as expected.

I reverted the router back to Voxel's 62F, and found that the older version of firmware does not do this. No traffic is seen at the WAN port until the router has finished booting.

If I recall correctly, my cable company (Altice Optimum) implements logic to ensure that only a single device (i.e., one MAC address) is connected to modem. With 72F firmware, the cable modem is seeing multiple MAC addresses from devices inside my network during the boot phase, and is likely locking out due to that one-device-per-account limitation.

I'm hoping my troubleshooting will be helpful to Voxel in fixing this issue. In addition to being an inconvenience to have to unplug/reconnect the cable every time the router is rebooted, having inside traffic bypass the firewall during boot time is probably a security issue too.

Oh, and before I hit "Post Reply", I want to take a second to thank Voxel for all of his hard work!!

 

[kamoj]

Excellent!
That was a good finding!

Maybe you can make a "soft reset" by changing something in LAN Setup - Address Reservation !?
Just change a device name e.g. - and press both Apply buttons.

When I do this, the router seems to disconnect the ports and closes telnet sessions when doing this.
It's worth a try to see what happens.

I am pretty sure I figured out what is causing this problem. For the first 30 seconds or so after rebooting the router with Voxel 72F firmware, while the leftmost light on the router is still amber, the WAN port is acting as another LAN port.

More specifically, I powered off the router, then connected a laptop running Wireshark to the WAN port of my R7800, and started a capture. Much to my surprise, as soon as I powered on the router, I started seeing traffic from the INSIDE of my network. For example my main desktop sending ARP packets looking for the inside address of the router, among others. As soon as the leftmost light on the router turned white, traffic from inside the network ceased. From that point on, the communications were all from the WAN MAC address of the router, as expected.

I reverted the router back to Voxel's 62F, and found that the older version of firmware does not do this. No traffic is seen at the WAN port until the router has finished booting.

If I recall correctly, my cable company (Altice Optimum) implements logic to ensure that only a single device (i.e., one MAC address) is connected to modem. With 72F firmware, the cable modem is seeing multiple MAC addresses from devices inside my network during the boot phase, and is likely locking out due to that one-device-per-account limitation.

I'm hoping my troubleshooting will be helpful to Voxel in fixing this issue. In addition to being an inconvenience to have to unplug/reconnect the cable every time the router is rebooted, having inside traffic bypass the firewall during boot time is probably a security issue too.

Oh, and before I hit "Post Reply", I want to take a second to thank Voxel for all of his hard work!!

 

[NetBytes]

Based on comparisons and @Bichon's really helpful post above.
I have tried all I can think of to get around this problem.
I have even tried 'ifconfig $WAN_IF down;sleep 10' type changes to the boot sequences in net-wan.

I don't think this is solvable in the script realm unless it's far earlier than in init.d scripts.

Is this a busybox bug/version issue?

Any other suggestions accepted.

 

[Voxel]

To say true it is difficult to debug this specific issue in the mind not having real access to devices... I do not have ideas yet, sorry.

Voxel.

 

[Voxel]

Better to continue in this thread.

Voxel,
I did tests using ifconfig $WAN_IF down; sleep 10; ifconfig $WAN_IF up
which did not seem to do anything?
Is 'ifconfig $WAN_IF down' the right thing to try to bring down the wan port power/connection?
And $WAN_IF was set to eth0.

I do not quite understand how did you test it. From the init script? Or from command line?

From command line should be "ifconfig brwan down"

root@R7800:~$ nvram get wan_ifname
brwan

Maybe it has a sense to block it (brwan) by iptables...

Voxel.

 

[NetBytes]

Better to continue in this thread.



I do not quite understand how did you test it. From the init script? Or from command line?

From command line should be "ifconfig brwan down"

root@R7800:~$ nvram get wan_ifname
brwan

Maybe it has a sense to block it (brwan) by iptables...

Voxel.

Yes, I was modifying init scripts like net-wan to perform this upon startup in a few places that seemed appropriate.
I saw brwan being used in there as an alias. In the 62SF version of some of the init scripts WAN_IF is set to eth0 if it's not set,
but in 72SF this is not done. When I say I have tried a large number of modifications which seemed appropriate,
I mean it. If brwan is an alias can't I use brwan or eth0 interchangeably?

I will use brwan next time I test. I would like to find a fix which works and is simple to implement if possible.

 

[kamoj]

Just an interesting post about another modem problem, giving some insight to Arris modem startup.
I think it's good to keep all info in this thread!
https://community.netgear.com/t5/Ni...-connection-in-bridge-mode/m-p/1641596#M41611