Strange issue with Arris TM1602AP2 and R7800

[Sizzlechest]

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?

 

[Gallo]

same problem, different arris modem, same thing to resolve it. never figured it out.

 

[NetBytes]

This is a very good description of the same issue I have had ever since Voxel .63.
If i downgrade to Voxel .62 the reboot will successfully auto-reconnect.
Any Voxel firmware since and I have to pull the WAN wire, count to five, then re-plug in.

Voxel - any way in your firmware to auto (turn off/power off/disconnect) the WAN connection for five seconds at the end of startup?

I volunteer for beta testing if you should pursue such a thing.

 

[Voxel]

Voxel - any way in your firmware to auto (turn off/power off/disconnect) the WAN connection for five seconds at the end of startup?

Interesting. First try the following test: modify the file /etc/init.d/modem (after your explanation I supposes that exactly script helps to recover the connection is WAN cable if plugged off).

From

. . .
start() {
    # Check: is router mode, exit if "no"
    if [ "$AP_MODE" != "0" ] || [ "$BRIDGE_MODE" != "0" ] || [ "$EXTENDER_MODE" != "0" ]; then
        exit 0;
    fi
    # Check: is cable attached to WAN port, exit if "yes"
    detcable show | grep "WAN  : Plug in" > /dev/null
    if [ $? -eq 0 ]; then
        exit 0;
    fi
. . .

to

. . .
start() {
    # Check: is router mode, exit if "no"
    if [ "$AP_MODE" != "0" ] || [ "$BRIDGE_MODE" != "0" ] || [ "$EXTENDER_MODE" != "0" ]; then
        exit 0;
    fi
    # Check: is cable attached to WAN port, exit if "yes"
    sleep 10
    detcable show | grep "WAN  : Plug in" > /dev/null
    if [ $? -eq 0 ]; then
        exit 0;
    fi
. . .

i.e. to add "sleep 10" command before script checks that WAN cable is connected.

Voxel.

 

[Sizzlechest]

It didn't make a difference for me. I rebooted, but there was no Internet connection. (The second light stayed amber.) I still had to manually unplug the Ethernet cable and plug it back in.

 

[Voxel]

It didn't make a difference for me. I rebooted, but there was no Internet connection. (The second light stayed amber.) I still had to manually unplug the Ethernet cable and plug it back in.

But check when you have amber of this WAN LED, not touching the cable. Two experiments from telnet. Waiting e.g. 20 sec. after boot.

1.

/etc/init.d/net-wan restart

if does not help

2.

net-wall rule
net-wall start

Voxel.

 

[Sizzlechest]

But check when you have amber of this WAN LED, not touching the cable. Two experiments from telnet. Waiting e.g. 20 sec. after boot.

1.

/etc/init.d/net-wan restart

This didn't help. I can provide you with the output, but it came back to a command prompt, but there was still output being sent. I guess it forks and runs in the background. At the end, it kept showing "Sending discover..." over and over.

if does not help

2.

net-wall rule
net-wall start

Voxel.

I tried this after I did the net-wan restart. When that didn't have any effect, I rebooted the router and tried just the net-wall commands. It made no difference. Unplugging the cable worked.

 

[NetBytes]

These tests did not help me either, but I like the ideas/attempts. Thank you.

 

[kamoj]

About net-wan:
The net-wan för R7800 is very old.
Many improvement and bug fixes are done in the same file for R9000 and XR500.
The last XR500 release was almost only for net-wan and other iptv fixes, option 60 & 61 a.o.
I had an idea to merge these files for R7800 but never got the time.

 

[Sizzlechest]

I found this block in net-wan:

start_stage0() # $1: boot/start, $2: manually
{
[ "x$1" = "xmanually" ] && echo "***** The net-wan command is called manually!!! *****"

mac_value=$(wanmac)
$CONFIG set cur_wanmac="$mac_value"

bond_enabled=`ifconfig |grep bond0`
if [ "x$bond_enabled" != "x" ]; then
ifconfig eth0 hw ether $mac_value
ifconfig eth1 hw ether $mac_value
ifconfig bond0 hw ether $mac_value
ifconfig ethlan hw ether $mac_value
fi
ifconfig ethwan hw ether $mac_value
ifconfig $WAN_IF hw ether $mac_value
ifconfig ethwan up
ifconfig $WAN_IF up

/etc/init.d/dni-qos $1
check_qca_nss

# Bring up the wan interface first time when sytem is Rebooted, it needs to wait
# for a moment after executing the command `ifconfig ethwan up`, then ethwan
# PHY is up. 3 seconds MAY be acceptable, and it works.
# If not wait, the `udhcpc` CAN'T obtain IP address in its selecting time.
[ "$changing_mode" = "1" ] && sleep 5
setup_wan_interface $2

/etc/init.d/upnp $1 & # upnp daemon
/etc/init.d/ddns $1 & # DDNS daemon
restart_ipv6 $1 &
}

Would increasing the sleep duration help?

 

[NetBytes]

So I tried a few things.
1) made the 'sleep 5' into 'sleep 15' - nope
2) added a 'sleep 10' just before the '/etc/init.d/upnp' line - nope
3) i placed another sleep 5 which will always execute just before setup_wan_interface (like in the detwan routine) -nope

Something in here might need to be changed or perhaps an appropriate wait inserted, good catch.
kamoj - can u post a copy of your improved net-wan? might be some insight in there for us

 

[Voxel]

It is difficult to trace such problems. After you reboot your router when WAN port LED is amber it is interesting:
1. What is an output for a command

detcable show

Especially what is the WAN port status.

2. What is recorded in the file /tmp/port_status

cat /tmp/port_status

Note: there are no line feed symbol in this file so output could be a bit spoiled, so check with attention. “1” or “0”

3. What is the status for brwan in ifconfig command

ifconfg

4. Attempt to down brwan interfac then up it and restart net-wan

ifconfig brwan down
ifconfig brwan up
/etc/init.d/net-wan restart

In general there is something specific of your modem <----> router’s WAN communications as I guess. E.g. modem does not power on the cable attached to WAN port or so. I.e. does it with delay.

There are several commands yet to reset WAN port. But it is I,possible to run them step-by-step. Because you should lose your telnet connection...
They probably could be stored in script and it could be executed (continued running even when you lose your telnet session):

#!/bin/sh

/etc/init.d/net-wan stop
/etc/init.d/detcable stop
/etc/init.d/watchdog stop
/etc/init.d/ntpclient stop
sleep 20
echo -n 1 > /tmp/port_status
/etc/init.d/net-wan start
net-wall restart

Voxel.

 

[NetBytes]

I can try these tonight (around 7:00 pm EST).

I was thinking I could put a forceful full restart script into my rc.local to try to find something that worked.

I can even save the output of Points 1, 2 and 3 into a file first.
I will try your Point 4 and/or your 'sleep 20' script there.

 

[Voxel]

I can even save the output of Points 1, 2 and 3 into a file first.

rc.local: please avoid its use here.

Yes. 1, 2, 3 - output is interesting. From telnet. After you see this amber LED.

4 - no output is needed, just a result. Is there WAN connection or not.

'sleep 20; script. Just manual start from telnet. No rc.local. Something like:

./mytest.sh &

and see the result (is WAN connected now or not).

Voxel.

 

[NetBytes]

rc.local: please avoid its use here.

Yes. 1, 2, 3 - output is interesting. From telnet. After you see this amber LED.

4 - no output is needed, just a result. Is there WAN connection or not.

'sleep 20; script. Just manual start from telnet. No rc.local. Something like:

./mytest.sh &

and see the result (is WAN connected now or not).

Voxel.

using rc.local is the sledgehammer to ensure the router is fully booted and in it's confused state.
if a better location can be found once I see success then it can be moved appropriately.
I agree rc.local is a 'last-resort' location.
I am testing with rc.local because the router is also un-responsive to web-requests in this state and I cannot access it to turn on telnet.

 

[kamoj]

Have you checked the dmesg and syslog ?

The system logs are in: /var/log/
You can find e.g. /var/log/messages and /var/log/log-message
/var/log/ is not erased at reboot, so you can put your log file copies there.

If you want to write log-files to USB (mounted as /mnt/sda1):

dmesg
=====

echo "Y" >/sys/module/printk/parameters/time; # Add time stamp to dmesg log
while true; do dmesg -c | awk -v d="$(date +"%F %T")" '{printf d" "$0"\n"'} | tee -a /mnt/sda1/dmesg.txt;sync;usleep 100000; done & echo $!

syslog
======

tail -f /var/log/messages >>/mnt/sda1/messages.txt & echo $!
tail -f /var/log/log-message >>/mnt/sda1/log-message.txt & echo $!

P.S.
These commands (to save dmesg and syslog) can be added to /etc/profile or /etc/rc.local

PPS
My net-wan is of no use for you.
It only contains fixes for iptv options 60 and 61, plus a fix for openvpn.
The other "merges" I have not tried yet.

So I tried a few things.
1) made the 'sleep 5' into 'sleep 15' - nope
2) added a 'sleep 10' just before the '/etc/init.d/upnp' line - nope
3) i placed another sleep 5 which will always execute just before setup_wan_interface (like in the detwan routine) -nope

Something in here might need to be changed or perhaps an appropriate wait inserted, good catch.
kamoj - can u post a copy of your improved net-wan? might be some insight in there for us

 

[NetBytes]

Hello. I put 1,2, and 3 into the rc.local and saved the output into a file.

LAN3 : Plug in, 1000M, Full duplex
LAN2 : Plug in, 1000M, Full duplex
LAN1 : Plug in, 100M, Full duplex
LAN0 : Plug off
WAN : Plug in, 1000M, Full duplex

1

br0 Link encap:Ethernet HWaddr
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:474 errors:0 dropped:0 overruns:0 frame:0
TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:58800 (57.4 KiB) TX bytes:15005 (14.6 KiB)

brwan Link encap:Ethernet HWaddr
inet6 addr:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:598 (598.0 B) TX bytes:384 (384.0 B)

ethlan Link encap:Ethernet HWaddr
inet6 addr:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:480 errors:0 dropped:0 overruns:0 frame:0
TX packets:173 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66080 (64.5 KiB) TX bytes:18133 (17.7 KiB)
Interrupt:2

ethwan Link encap:Ethernet HWaddr
inet6 addr:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:780 (780.0 B) TX bytes:1206 (1.1 KiB)
Interrupt:255

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3194 errors:0 dropped:0 overruns:0 frame:0
TX packets:3194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:176849 (172.7 KiB) TX bytes:176849 (172.7 KiB)

 

[NetBytes]

I tried the script (4) as the last steps of my rc.local and the router never connected, still needed physical wire disconnect

 

[NetBytes]

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

 

[kamoj]

You are right, of course. Netgear has done it again...
Last night I worked with the new add-on and implemented dhcp options 60 and 61.

I then noted some strange bad code in net-wan...
Was too tired to fix it, but I can post a patch for you to try out.
(Seems to be the same error in the R9000 code, but not for the XR500 that instead has another bug...)