Modify

Opened 4 years ago

Last modified 2 years ago

#15006 new defect

WAN port on WNDR3700v2 does not work

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: Cc:

Description

This one is really annoying: With genuine Netgear firmware the WAN port operates just fine. If I switch to any version of OpenWRT, WAN port does not work anymore.

eth1 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX

UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5

Log files show:

[ 22.960000] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready

And if I try to run the following command I get:

/etc/init.d/network restart
Command failed: Not found
'radio0' is disabled
'radio1' is disabled

Attachments (0)

Change History (25)

comment:1 follow-up: Changed 4 years ago by anonymous

User Error 101.

Wireless radios are disabled by default, you have to enable them and set them up.
IPV6 is disabled by default as well.
As far as ports you have to read the wiki about your hardware port 0 to 4 + cpu, you have to add WAN and LAN interfaces or config them to your network environment.
WNDR3700v2 I have the same hardware and have been using Attitude Adjustment (12.09 final) since release with 0 issues.

comment:2 in reply to: ↑ 1 Changed 4 years ago by anonymous

No user error. I'm using hnyman's community build (see forum), so everything is configured. A second WNDR3700v2 I own is *not* affected by this issue. I know very well that the radios are disabled. I was rather pointing to "Command failed: Not found".

comment:3 Changed 4 years ago by hnyman

The "Command failed: Not found" pops up also in a fully working system, so that is probably not the reason. (The "stop" command in the network restart script seems to cause it.)

Can you spot differences in the kernel boot log (dmesg) between the working wndr3700v2 and the non-working one? I am thinking if there is some subtle difference in the hardware, which causes the hardware to get detected differently.

comment:4 Changed 4 years ago by anonymous

Thank you hnyman for your answer. The working unit was acquired in the US (for now, running arokh's build). The unit with the non-functional WAN port was bought in Germany (running arokh's build, yours (AA and barrier breaker)).

Working unit dmesg:

Code highlighting:

  [    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] Memory: 61632k/65536k available (2193k kernel code, 3904k reserved, 416k data, 204k init, 0k highmem)
[    0.000000] SLUB: Genslabs=9, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:51
[    0.000000] Calibrating delay loop... 452.19 BogoMIPS (lpj=2260992)

non-functional unit starts with:

Code highlighting:

[    0.000000] Linux version 3.10.28 (perus@v1310) (gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2013.05 r39376) ) #2 Sat Feb 15 10:05:26 EET 2014
[    0.000000] MyLoader: sysp=aaaa5554, boardp=aaaa5554, parts=aaaa5554
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Atheros AR7161 rev 2
[    0.000000] Clocks: CPU:680.000MHz, DDR:340.000MHz, AHB:170.000MHz, Ref:40.000MHz
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x00000000-0x03ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00000000-0x03ffffff]
[    0.000000] On node 0 totalpages: 16384
[    0.000000] free_area_init_node: node 0, pgdat 803089b0, node_mem_map 81000000
[    0.000000]   Normal zone: 128 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 16384 pages, LIFO batch:3
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line:  board=WNDR3700 console=ttyS0,115200 mtdparts=spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,15872k(firmware),64k(art)ro rootfstype=squashfs,jffs2 noinitrd
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] Memory: 61272k/65536k available (2217k kernel code, 4264k reserved, 592k data, 260k init, 0k highmem)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:51

Working unit dmesg:

Code highlighting:

[    2.890000] 6 cmdlinepart partitions found on MTD device spi0.0
[    2.900000] Creating 6 MTD partitions on "spi0.0":
[    2.900000] 0x000000000000-0x000000050000 : "u-boot"
[    2.910000] 0x000000050000-0x000000070000 : "u-boot-env"
[    2.910000] 0x000000070000-0x000000160000 : "kernel"
[    2.920000] 0x000000160000-0x000000ff0000 : "rootfs"
[    2.930000] mtd: partition "rootfs" set to be root filesystem
[    2.930000] mtd: partition "rootfs_data" created automatically, ofs=980000, len=670000 
[    2.940000] 0x000000980000-0x000000ff0000 : "rootfs_data"
[    2.950000] 0x000000ff0000-0x000001000000 : "art"
[    2.950000] 0x000000070000-0x000000ff0000 : "firmware"
[    2.960000] Realtek RTL8366S ethernet switch driver version 0.2.2
[    2.970000] rtl8366s rtl8366s: using GPIO pins 5 (SDA) and 7 (SCK)
[    2.970000] rtl8366s rtl8366s: RTL8366 ver. 1 chip found
[    3.010000] rtl8366s: probed
[    3.010000] eth0: Atheros AG71xx at 0xb9000000, irq 4
[    3.320000] eth1: Atheros AG71xx at 0xba000000, irq 5
[    3.630000] ag71xx ag71xx.1: eth1: connected to PHY at rtl8366s:04 [uid=001cc960, driver=Generic PHY]

non-functional unit:

Code highlighting:

[    2.890000] 4 cmdlinepart partitions found on MTD device spi0.0
[    2.890000] Creating 4 MTD partitions on "spi0.0":
[    2.900000] 0x000000000000-0x000000050000 : "u-boot"
[    2.900000] 0x000000050000-0x000000070000 : "u-boot-env"
[    2.910000] 0x000000070000-0x000000ff0000 : "firmware"
[    2.920000] 2 netgear-fw partitions found on MTD device firmware
[    2.920000] 0x000000070000-0x00000016d440 : "kernel"
[    2.930000] mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    2.940000] 0x00000016d440-0x000000ff0000 : "rootfs"
[    2.950000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    2.960000] mtd: device 4 (rootfs) set to be root filesystem
[    2.970000] 1 squashfs-split partitions found on MTD device rootfs
[    2.970000] 0x000000610000-0x000000ff0000 : "rootfs_data"
[    2.980000] 0x000000ff0000-0x000001000000 : "art"
[    2.990000] Realtek RTL8366S ethernet switch driver version 0.2.2
[    2.990000] rtl8366s rtl8366s: using GPIO pins 5 (SDA) and 7 (SCK)
[    3.000000] rtl8366s rtl8366s: RTL8366 ver. 1 chip found
[    3.040000] libphy: rtl8366s: probed
[    3.350000] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:RGMII
[    3.650000] ag71xx ag71xx.1: connected to PHY at rtl8366s:04 [uid=001cc960, driver=Generic PHY]
[    3.660000] eth1: Atheros AG71xx at 0xba000000, irq 5, mode:RGMII

Working unit:

Code highlighting:

[   34.280000] PCI: Enabling device 0000:00:11.0 (0000 -> 0002)
[   34.290000] ath: EEPROM regdomain: 0x0
[   34.290000] ath: EEPROM indicates default country code should be used
[   34.290000] ath: doing EEPROM country->regdmn map search
[   34.290000] ath: country maps to regdmn code: 0x3a
[   34.290000] ath: Country alpha2 being used: US
[   34.290000] ath: Regpair used: 0x3a

non-functional unit:

Code highlighting:

[   13.760000] ath: phy0: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff
[   13.760000] ath: phy0: random mac address will be used: [normal MAC appears here]
[   13.770000] ath: EEPROM regdomain: 0x0
[   13.770000] ath: EEPROM indicates default country code should be used
[   13.770000] ath: doing EEPROM country->regdmn map search
[   13.770000] ath: country maps to regdmn code: 0x3a
[   13.770000] ath: Country alpha2 being used: US
[   13.770000] ath: Regpair used: 0x3a

For now, testing is done with the non-functional being connected to the working WNDR3700v2. If the stock firmware is used, an IP address is acquired and everything runs as expected. However, if I use any build of OpenWRT and try to achieve the same, the router does not even recognize the connected cable (at least, that is the way it appears to me).

comment:5 Changed 4 years ago by hnyman

a few comments:

  • section 1: probably the working unit has too short log buffer and the first lines have disappeared. I spot nothing strange there
  • section 2: the MTD part just shows a difference in creating the partitions, due to a change a few months ago. But the interesting part was actually where you cut off the log, maybe a few lines too short. In the working unit eth1 gets a proper connection:

ag71xx ag71xx.1: eth1: connected to PHY at rtl8366s:04 [uid=001cc960, driver=Generic PHY]

In the other unit, the line is in the log one line higher, after eth1 and looks different. The next few lines might have been interesting. (But Arokh's build is so old that this may be just normal code change.)

  • section 3: looks the most serious and might be the reason. phy0 etc. interfaces should get the MAC addresses from the "art" partition, where they should be stored. If they are missing, then Openwrt will probably fail.

You might check the contents from the correct /dev/mtdxxxxx device. There should be the mac adderss, router serial number, WPS pin code etc.

Use "cat /proc/mtd" to see, which mtdblock is the correct one. e.g. mtdblock6

mtd5: 009e0000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"
root@OpenWrt:~# hexdump -C /dev/mtdblock6 | head
00000000 74 44 01 55 55 e7 74 44 01 55 55 e8 74 44 01 55 |tD....tD....tD..|
00000010 55 e9 33 36 35 34 34 34 38 31 32 4d 39 33 32 43 |..365444812M932C|

My guess is that you have somehow been able to clear that partition. It is write-protected inside Openwrt, so either something else has deleted it or the manufacturer has deleted it for some reason?

More clear explanation for the expected contents in the art can be found at the mtd dir of my community build in dropbox.
https://www.dropbox.com/sh/t52c02rm20y8x9p/ooWlI23QzN/mtd

comment:6 Changed 4 years ago by anonymous

based on your suggestions I was searching for possible issues:

  • section 2: Here are the additional lines from the non-functional unit, hope this helps:
[    2.690000] bio: create slab <bio-0> at 0
[    2.690000] PCI host bridge to bus 0000:00
[    2.700000] pci_bus 0000:00: root bus resource [mem 0x10000000-0x16ffffff]
[    2.700000] pci_bus 0000:00: root bus resource [io  0x0000]
[    2.710000] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    2.710000] pci 0000:00:11.0: [168c:ff1d] type 00 class 0x020000
[    2.710000] pci 0000:00:11.0: fixup device configuration
[    2.720000] pci 0000:00:11.0: reg 10: [mem 0x00000000-0x0000ffff]
[    2.720000] pci 0000:00:11.0: PME# supported from D0 D3hot
[    2.720000] pci 0000:00:12.0: [168c:ff1d] type 00 class 0x020000
[    2.720000] pci 0000:00:12.0: fixup device configuration
[    2.720000] pci 0000:00:12.0: reg 10: [mem 0x00000000-0x0000ffff]
[    2.720000] pci 0000:00:12.0: PME# supported from D0 D3hot
[    2.720000] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    2.720000] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[    2.730000] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[    2.730000] pci 0000:00:11.0: using irq 40 for pin 1
[    2.740000] pci 0000:00:12.0: using irq 41 for pin 1
[    2.740000] Switching to clocksource MIPS
[    2.750000] NET: Registered protocol family 2
[    2.750000] TCP established hash table entries: 512 (order: 0, 4096 bytes)
[    2.750000] TCP bind hash table entries: 512 (order: -1, 2048 bytes)
[    2.760000] TCP: Hash tables configured (established 512 bind 512)
[    2.760000] TCP: reno registered
[    2.760000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    2.770000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    2.780000] NET: Registered protocol family 1
[    2.780000] PCI: CLS 0 bytes, default 32
[    2.790000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.800000] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    2.810000] msgmni has been set to 119
[    2.810000] io scheduler noop registered
[    2.820000] io scheduler deadline registered (default)
[    2.820000] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[    2.850000] serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A
[    2.860000] console [ttyS0] enabled, bootconsole disabled
[    2.870000] ath79-spi ath79-spi: master is unqueued, this is deprecated
[    2.880000] m25p80 spi0.0: found mx25l12805d, expected m25p80
[    2.880000] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
  • section 3: As far as I can tell, this should be correct:
root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00050000 00010000 "u-boot"
mtd1: 00020000 00010000 "u-boot-env"
mtd2: 00f80000 00010000 "firmware"
mtd3: 000fd440 00010000 "kernel"
mtd4: 00e82bc0 00010000 "rootfs"
mtd5: 009e0000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"

root@OpenWrt:~# hexdump -C /dev/mtdblock6 | head

XX XX XX XX XX X6 (normal MAC here)
XX XX XX XX XX X7 (normal MAC here)
XX XX XX XX XX X8 (normal MAC here)
YY YY YY YY YY YY YY YY (WPS PIN code)
SE RI AL SE RI AL NO NO (Serial number)

00  02

32 39 37 36 33 36 35 34 2b 31 36 2b 36 34 57

4e 44 52 33 37 30 30 76
32 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff

Perhaps there is something else?

comment:7 Changed 4 years ago by anonymous

Two more comments:

  • The only other line that includes eth1 can be found later on:
[   19.990000] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
  • One line from the previous dmesg might be a problem?
[    2.710000] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]

comment:8 follow-up: Changed 4 years ago by ameram@…

Anybody know how to fix this issue? I'm using Attitude Adjustment and can't get WAN working.

How do I get the WAN up and running on a wndr3800?

comment:9 in reply to: ↑ 8 Changed 4 years ago by hnyman

Replying to ameram@…:

How do I get the WAN up and running on a wndr3800?

In my WNDR3800 (and WNDR3700 and WNDR3700v2) the wan port works just fine with either Openwrt trunk or with AA12.09.

If yours does not, it is something strange/different in your unit.

comment:10 follow-up: Changed 4 years ago by ameram@…

Have you guys come across this before? Why would a Netgear wndr3800 be different from other wndr3800 units? Is there a way to find out how my unit is diff and get it working?

comment:11 in reply to: ↑ 10 Changed 4 years ago by hnyman

Replying to ameram@…:

Have you guys come across this before? Why would a Netgear wndr3800 be different from other wndr3800 units? Is there a way to find out how my unit is diff and get it working?

Yes, we have seen this earlier, mainly in this thread. Yours is either the second or third case that I have heard about (and has created most of the duplicate tickets).

It is probably a few individual units with marginally different timings, faulty chips, different EEPROM firmware country settings (or something...) than the most units. Or something similar that causes Openwrt's hardware detection/initialisation to fail in some conditions. The original reporter's working unit was from US, and non-working from Germany. Where is yours from?

Above (in comment 4) the original reporter's the MAC addresses were read wrongly from EEPROM, which suggests that something goes wrong with the hardware initialisation. There was a notice in kernel log / dmesg output about this:

13.760000 ath: phy0: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff

Is that true also for you?

Debugging this problem will be extremely hard, as the actual developers have no access to your device. And as everything works for most users, the issue is probably not that critical for devs.

Most likely the easiest thing would be to revert to the original firmware (or dd-wrt as based on #15703 it works for you).

comment:12 follow-up: Changed 4 years ago by ameram@…

How do I learn where my unit is from? On the unit itself it says it was made in China.

Can you please help me get the device back to Netgear Firmware? everything I've tried has not been successful.

Thanks for your help!

comment:13 in reply to: ↑ 12 Changed 4 years ago by hnyman

Replying to ameram@…:

Can you please help me get the device back to Netgear Firmware? everything I've tried has not been successful.

The recovery advice for wndr3700 given on Openwrt wiki (using Netgear's TFTP mode and flashing original Netgear firmware using that) has worked for me about a dozen times.

Advice originates from this forum message:
https://forum.openwrt.org/viewtopic.php?pid=103295#p103295

(I usually use a TFTP tool with GUI, as it makes it easy.)

comment:14 Changed 4 years ago by ameram@…

Thanks for the link.

Do you know how I can learn where my unit is from? I'd like to confirm it is one of the models that won't work. I will return it.

comment:15 follow-up: Changed 4 years ago by ameram@…

hnyman, I really appreciate your help with this.

unfortunately, performing the tftp method described in the link does not work. Everytime I try it I get this report:

usage: tftp host-name [port]
tftp>

Any idea what I can do to get this dang thing back to Netgear? This openwrt has been a nightmare experience.

comment:16 Changed 4 years ago by ameram@…

Sorry, pasted wrong part of message.

The tftp keeps "timing out". you prolly don't need to see the actual message it produces. It's timing out. How do I get it to work?

comment:17 in reply to: ↑ 15 Changed 4 years ago by hnyman

Replying to ameram@…:

Any idea what I can do to get this dang thing back to Netgear? This openwrt has been a nightmare experience.

The advice in wiki & forum:

  • plug the PC into LAN port 1
  • set the pc to a static IP of 192.168.1.2
  • power on the router
  • press and hold the RESET button as soon as the switch LEDs light up.
  • keep holding RESET until the power LED begins to flash orange and then green.
  • once the power LED is flashing green, release RESET and start TFTP transfer
  • TFTP transfer is quick, but flashing will take 5 minutes. After that the router should reboot automatically.

Follow the process exactly...

  • You really need to set a fixed IP address for your PC.
  • You need to push reset at the correct moment and keep it pushed until a certain moment, just like the advice says. Push the button located inside the hole in the router bottom with narrow pin (I use a paperclip). If you enter the Netgear recovery mode, the power led will start blinking rather slowly.
  • It is easier with a TFTP client with GUI. I use this TFTP2.EXE: http://www.dd-wrt.com/wiki/index.php/TFTP_flash#Windows
  • Download the most recent Netgear firmware and set it "ready to send" in the TFTP GUI. Then at the correct moment push the send/upgrade button.
  • The TFTP transfer will happen VERY quickly. This is because the image is stored in RAM before flashing. But automatic flashing will take 5 minutes. If the upload went ok, the power LED usually stops blinking and is either solidly on or off.

I have used the process well over dozen times, and it has worked always. I haven't always succeeded to enter the mode on the first try.

This is the most detailed advice that can be given to you.

comment:18 Changed 4 years ago by hnyman

One addendum: server address is naturally 192.168.1.1 and there is no password.

comment:19 Changed 4 years ago by ameram@…

Yes, I have followed the directions you posted EXACTLY and tried multiple times.

I held reset until the LED starts rapidly flashing green, then immediately started TFTP. I tried TFTP process using linux command line and I tried it using Windows OS with the TFTP2.exe app. Same result: time outs. I've have numerous times.

Do you know how I can find out where my wndr3800 model is from? I want to identify whether it is indeed in the "Bad" batch that won't work with openwrt.

comment:20 Changed 4 years ago by ameram@…

Got it!

I tried again, repeatedly and one of the tries finally worked. Maybe my router is defective and that's what explains all this trouble.

Guys, what router can I go out and buy today that runs OpenWrt awesomely? I want a router with best possible hardware performance (memory, etc).

Thanks for all your help hnyman!!!!!

comment:21 Changed 4 years ago by ameram@…

Anybody, what routers actually work with OpenWRT?

are there any routers that are guaranteed to work with this firmware? Is the firmware of any quality or just kind of a lower grade quality, explaining why it wouldn't work with a router it was supposed to work with.

comment:22 Changed 4 years ago by ameram@…

l

comment:23 Changed 3 years ago by mrtarei

Got the same issue with WNDR3800-100PES sold as EU version. Not working WAN port.

comment:24 Changed 3 years ago by i24

I can confirm this issue on a WNDR4300v1 (wndrnand r46541.) Related symptoms listed below.

  1. On the Status | Overview page under Leases for IPv4 the Hostname, IPv4-Address, MAC-Address, Leasetime were all shown correctly. However, for IPv6 one of the LAN clients was missing and another client hostname was displayed as "?"
  1. On the Interfaces page, the MAC address of the WAN interface was displayed as 00:00:00:00:00:00
  1. To obtain a WAN IP I had to force override the default (zero) MAC address with a spoofed address. Both v4 & v6 WAN address was then assigned correctly by DHCP, but could not ping anything beyond the ISP's gateway.
  1. To enable web browsing I did this:

WAN - Use builtin IPv6-management = disabled
WAN6 - Request IPv6-address = disabled
WAN6 - bring up on boot = disabled

(did not test each one individually, just rebooted)

  1. When I was able to browse the web, the indicators read as follows:

Status | Overview | Network

  • IPv4 WAN Status = CONNECTED
  • MWAN Interface Live Status wan (eth0.2) = DISABLED

Network | Interfaces | Overview

  • WAN eth0.2 = NOT CONNECTED (indicator is RED when working)
  • TOR = CONNECTED (is that the intended default?)


After several hours, all of the hardware traffic lights for the client devices began to blink rapidly & continuously in perfect sync. The problem has survived a reboot AND disconnecting the modem. All of the lights now blink continuously while power is applied. However, it did not affect browsing. When I changed the WAN MAC address again to see what would happen, web access was lost (but not the WAN connection.) Rebooting the modem did not restore internet connectivity as it normally would. At this point the device was taken offline and awaits a future update because it is unusable.

Notes:

There were 4 LAN clients in this test but after enabling WAN only 2 active leases were displayed on the Status page.

At some point the system & kernel log menu options quit working and the UI began to ask for a password on every page load. A reboot seemed to resolve this.

The Tor virtual interface cannot be disabled and I did not expect it to be brought up at boot by default. Was it accidentally swapped with the WAN interface?

Is the bug only present in Atheros builds?

If the MAC address override is changed in oWRT, it seems to take much longer for the ISP to restore connectivity than it took with the stock firmware and DD-WRT.


Default DNS forwardings are shown as:

 127.0.0.1#5300
 /0.openwrt.pool.ntp.org/8.8.8.8
 /1.openwrt.pool.ntp.org/8.8.8.8
 /2.openwrt.pool.ntp.org/8.8.8.8
 /3.openwrt.pool.ntp.org/8.8.8.8

Is this a bug? Other firmwares require only an IP address.


Before posting here, I attempted to discuss these issues in the appropriate section of the forum, but could not register because my email address was falsely detected as SPAM. (I did not use a disposable email address.) It makes me wonder how many potential contributors to this project might have simply walked away because they cannot get online OR join the forum.

comment:25 Changed 2 years ago by anonymous

REFERENCES

WNDR3400v1 Wan/switch port configuration wrong
/ticket/13000.html

WNDR3800 WAN port up status not updated to /var/state
/ticket/11952.html

Netgear WNDR3700v2 no WAN connection
/ticket/11800.html

TL-WR1043ND Ver 1.8 Board Rev 1.1 WAN PORT Issue->
/ticket/11898.html

WNDR3700v2 no internet on WAN port in specific enviroment.
/ticket/11041.html

  • Problems with wan port autoconfig on netgear WNDR3700V2

/ticket/10517.html

Config error in /e/c/wireless (wrong HTmode on ch161) makes LAN dead to the world (WNDR3700v2)
/ticket/10181.html

  • WNDR3700 (v1) switch issues.

/ticket/7980.html

  • WNDR4300: Adding a VLAN in the Web UI causes a loss of connectivity

/ticket/19391.html

  • WAN port on WNDR3700v2 does not work

/ticket/15006.html

WNDR3800 WAN port can't work on some situation
/ticket/19630.html

WNDR4300 - number of errors
/ticket/19377.html

broadcom
http://wiki.openwrt.org/toh/netgear/wndr3400

atheros
http://wiki.openwrt.org/toh/netgear/wndr3700
http://wiki.openwrt.org/toh/netgear/wndr3800
http://wiki.openwrt.org/toh/netgear/wndr4300

https://www.dd-wrt.com/site/support/router-database

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.