Firmware v1.9.2.7 CR6, updated to CR6a ... now CR6b [Oleg]

[iog]

I have been chasing a solution to my Bigpond dropout problem for months. Every 28 minutes, there are time-outs on email send/receive and browsing and complete dropouts on VPN (client end via router with either ethernet or wireless) or VoiP. Casual users might not notice these problems. Every new FW I hope it is fixed. Asus 1.9.2.7 did not drop out but lost connection completely every couple of days and had to be manually reconnected. Since then, all FW versions have not needed to be reconnected manually, but all have had the same dropout problem (every 28 minutes). This includes Oleg's 1.9.2.7-4 (installed 21 March 05), Asus 1.9.4.0, 1.9.4.6, 1.9.5.0 and Oleg's 1.9.2.7-6b (using FW restoration tool; what a hassle!). Please help! Surely I am not the only one with this problem. Or have all Bigpond users given up on the Asus routers or Bigpond (I don't have the latter option). Surely there is a solution to this.

[Oleg]

Have you checked lease time, provided by BigPond? Perhaps, it's about 1 hour, which is too low.

[iog]

Oleg,
Thanks for replying. Lease time requested by the router is the default, 86400. The lease time indicated in the router log as granted by Bigpond is nearly always 21600. The dropouts occur in multiples of about 27 1/2 minutes after the last lease is granted from Bigpond (i.e., 27.5 mnutes, 55 minutes, 82.5 minutes, etc.). The dropout lasts for about a minute or more. If using a VPN client, it drops out. Likewise with VoiP. This is *very* frustrating. I find it hard to believe that I am the only one with this problem.

[iog]

I've solved the ongoing problems with dropouts with VPN and VoiP (every 27-28 minutes). I've got a Netgear WGR614 router! Setup was a breeze and it works rock solid with Bigpond cable. It's Bigpond client actually works the way it is supposed to. On several forums re the WL500g, no one has told me that they have no dropout problems with VPN or VoiP with Bigpond. I take it that 'successful' WL500g + Bigpond users (are there any?) only use it casually and so do not notice the dropouts. I have been unable to get either Oleg or Asus firmware to give a stable connection with Bigpond. No one seems to be listening, so I give up. I am returning the unit. It's a pity; the router is such a nice concept, but it does not do the basics, so it is useless to me.

[Oleg]

I've solved the ongoing problems with dropouts with VPN and VoiP (every 27-28 minutes). I've got a Netgear WGR614 router! Setup was a breeze and it works rock solid with Bigpond cable. It's Bigpond client actually works the way it is supposed to. On several forums re the WL500g, no one has told me that they have no dropout problems with VPN or VoiP with Bigpond. I take it that 'successful' WL500g + Bigpond users (are there any?) only use it casually and so do not notice the dropouts. I have been unable to get either Oleg or Asus firmware to give a stable connection with Bigpond. No one seems to be listening, so I give up. I am returning the unit. It's a pity; the router is such a nice concept, but it does not do the basics, so it is useless to me.

This is really offtopic. I'm very happy, that you've bought netgear and it works. I'm a Russia citizen, so I've no idea why BigPond does not work in Australia. I've done my best, but as seems nobody in Australia interested in your problems. I'm not a "Technical Support", and not an ASUS affiliate, sorry.

[iog]

I'm a Russia citizen, so I've no idea why BigPond does not work in Australia. I've done my best, but as seems nobody in Australia interested in your problems. I'm not a "Technical Support", and not an ASUS affiliate, sorry.

Oleg, thanks for your replies and all the (unpaid) work you do to develop FW for the Asus routers. Many are benefiting from that, I'm sure. The Bigpond client is not your responsibility; it is Asus'. But they do not seem to be interested. Their technical support is virtually non-existent. Thanks again.

[Adverse]

On several forums re the WL500g, no one has told me that they have no dropout problems with VPN or VoiP with Bigpond. I take it that 'successful' WL500g + Bigpond users (are there any?) only use it casually and so do not notice the dropouts.

Well I am in Brizzy QLD AU on the BPA cable network
I run a 14 system network here at home with dedicated systems for mail server , FTP server , WEB server both HTTP and HTTPS , I have a system set up so I can remote administer about 160 networks world wide for clients

I have used Oleg FW since day one when I found out the default FW BPA login wont work.

in the last year that I have been installing WL-500g's (over 80 in QLD) all with Oleg's FW not one has had a problem after being flashed.

I am by no means a "casual user"

I would be looking at your other hardware for faults or misconfiguration

Oleg I thank you for your hard work as you have saved me much time and stress.

SB4200 (TCN-ISO SIGMA 1.5 Firmware Base: 0.4.4.5 )<-not TEL$TRA's buggy FW
WL-500G (1.9.2.7-Oleg)
11 systems (all ASUS motherboards and AGP/PCI cards) WIN2K
1 system win98 (see above)
1 system WIN2K3 (see above)
1 system Linux (see above)

Adverse Effects

[fabiosantos]

Something is going on! Any thoughts?
I came from 1.9.2.7-3c and didnt reseted to factory defaults, could it be the problem???

Jan  1 00:00:05 syslogd started: BusyBox v1.00 (2005.05.11-18:29+0000)
Jan  1 00:00:05 kernel: 0x003e0000-0x003f0000 : "config"
Jan  1 00:00:05 kernel: sflash: chipcommon not found
Jan  1 00:00:05 kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jan  1 00:00:05 kernel: IP Protocols: ICMP, UDP, TCP
Jan  1 00:00:05 kernel: IP: routing cache hash table of 512 buckets, 4Kbytes
Jan  1 00:00:05 kernel: TCP: Hash tables configured (established 1024 bind 2048)
Jan  1 00:00:05 kernel: ip_conntrack version 2.1 (128 buckets, 1024 max) - 344 bytes per conntrack
Jan  1 00:00:05 kernel: ip_conntrack_pptp version 1.9 loaded
Jan  1 00:00:05 kernel: ip_nat_pptp version 1.5 loaded
Jan  1 00:00:05 kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jan  1 00:00:05 kernel: ipt_time loading
Jan  1 00:00:05 dnsmasq[49]: read /etc/hosts - 5 addresses
Jan  1 00:00:05 dnsmasq[49]: read /etc/ethers - 3 addresses
Jan  1 00:00:05 dnsmasq[49]: reading /tmp/resolv.conf
Jan  1 00:00:05 kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Jan  1 00:00:05 kernel: IPv6 v0.8 for NET4.0
Jan  1 00:00:05 kernel: IPv6 over IPv4 tunneling driver
Jan  1 00:00:05 kernel: NET4: Ethernet Bridge 008 for NET4.0
Jan  1 00:00:05 kernel: 802.1Q VLAN Support v1.7 Ben Greear <greearb@candelatech.com>
Jan  1 00:00:05 kernel: All bugs added by David S. Miller <davem@redhat.com>
Jan  1 00:00:05 kernel: FAT: bogus logical sector size 47872
Jan  1 00:00:05 kernel: FAT: bogus logical sector size 47872
Jan  1 00:00:05 kernel: NTFS: Unable to set blocksize 512.
Jan  1 00:00:05 kernel: VFS: Mounted root (squashfs filesystem) readonly.
Jan  1 00:00:05 kernel: Mounted devfs on /dev
Jan  1 00:00:05 kernel: Freeing unused kernel memory: 72k freed
Jan  1 00:00:05 kernel: Warning: unable to open an initial console.
Jan  1 00:00:05 kernel: Algorithmics/MIPS FPU Emulator v1.5
Jan  1 00:00:05 kernel: eth0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
Jan  1 00:00:05 kernel: eth1: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
Jan  1 00:00:05 kernel: PCI: Enabling device 01:02.0 (0004 -> 0006)
Jan  1 00:00:05 kernel: eth2: Broadcom BCM4320 802.11 Wireless Controller 3.90.23.0
Jan  1 00:00:05 kernel: device eth0 entered promiscuous mode
Jan  1 00:00:05 kernel: device eth2 entered promiscuous mode
Jan  1 00:00:05 kernel: br0: port 2(eth2) entering listening state
Jan  1 00:00:05 kernel: br0: port 1(eth0) entering listening state
Jan  1 00:00:05 kernel: br0: port 2(eth2) entering learning state
Jan  1 00:00:05 kernel: br0: port 1(eth0) entering learning state
Jan  1 00:00:05 kernel: br0: port 2(eth2) entering forwarding state
Jan  1 00:00:05 kernel: g
Jan  1 00:00:05 kernel: br0: port 1(eth0) entering forwarding state
Jan  1 00:00:05 kernel: br0: topology change detected, propagating
Jan  1 00:00:06 kernel: usb.c: registered new driver usbdevfs
Jan  1 00:00:06 kernel: usb.c: registered new driver hub
Jan  1 00:00:06 kernel: usb-ohci.c: USB OHCI at membase 0xb8004000, IRQ 2
Jan  1 00:00:06 kernel: usb-ohci.c: usb-00:04.0, PCI device 14e4:4715
Jan  1 00:00:06 kernel: usb.c: new USB bus registered, assigned bus number 1
Jan  1 00:00:06 kernel: hub.c: USB hub found
Jan  1 00:00:06 kernel: hub.c: 2 ports detected
Jan  1 00:00:07 kernel: lp0: using parport0 (polling).
Jan  1 00:00:07 kernel: usb.c: registered new driver usblp
Jan  1 00:00:07 kernel: printer.c: v0.13: USB Printer Device Class driver
Jan  1 00:00:09 kernel: usb.c: registered new driver audio
Jan  1 00:00:09 kernel: audio.c: v1.0.0:USB Audio Class driver
Jan  1 00:00:09 kernel: Linux video capture interface: v1.00
Jan  1 00:00:10 kernel: SCSI subsystem driver Revision: 1.00
Jan  1 00:00:10 kernel: Initializing USB Mass Storage driver...
Jan  1 00:00:10 kernel: usb.c: registered new driver usb-storage
Jan  1 00:00:10 kernel: USB Mass Storage support registered.
Jan  1 00:00:11 pppd[79]: Plugin rp-pppoe.so loaded.
Jan  1 00:00:11 pppd[79]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Jan  1 00:00:11 pppd[80]: pppd 2.4.2 started by admin, uid 0
Jan  1 00:00:11 kernel: lp driver: get device ID
Jan  1 00:00:12 kernel: neg fail
Jan  1 00:00:16 pppd[80]: PPP session is 6858
Jan  1 00:00:16 pppd[80]: Using interface ppp0
Jan  1 00:00:16 pppd[80]: Connect: ppp0 <--> eth1
Jan  1 00:00:17 kernel: lp driver: get device ID
Jan  1 00:00:17 kernel: neg fail
Jan  1 00:00:17 kernel: neg fail
Jan  1 00:00:20 dnsmasq[49]: DHCPDISCOVER(br0) 00:11:d8:38:3e:a0
Jan  1 00:00:20 dnsmasq[49]: DHCPOFFER(br0) 10.1.1.150 00:11:d8:38:3e:a0
Jan  1 00:00:20 dnsmasq[49]: DHCPREQUEST(br0) 10.1.1.150 00:11:d8:38:3e:a0
Jan  1 00:00:20 dnsmasq[49]: DHCPACK(br0) 10.1.1.150 00:11:d8:38:3e:a0 metal
Jan  1 00:00:28 pppd[80]: PAP authentication failed
Jan  1 00:00:28 pppd[80]: Connection terminated.
Jan  1 00:00:59 pppd[80]: PPP session is 6925
Jan  1 00:00:59 pppd[80]: Using interface ppp0
Jan  1 00:00:59 pppd[80]: Connect: ppp0 <--> eth1
Jan  1 00:01:11 pppd[80]: PAP authentication failed
Jan  1 00:01:11 pppd[80]: Connection terminated.
Jan  1 00:01:41 wan: connected manually
Jan  1 00:01:41 pppd[80]: PPP session is 6974
Jan  1 00:01:42 pppd[80]: Using interface ppp0
Jan  1 00:01:42 pppd[80]: Connect: ppp0 <--> eth1
Jan  1 00:01:42 pppd[80]: Terminating on signal 15.
Jan  1 00:01:42 pppd[80]: Modem hangup
Jan  1 00:01:42 pppd[80]: Connection terminated.
Jan  1 00:01:43 kernel: Unable to handle kernel paging request at virtual address 000000e8, epc == 800d1b18, ra == 800d1af0
Jan  1 00:01:43 kernel: Oops in fault.c::do_page_fault, line 192:
Jan  1 00:01:43 kernel: $0 : 00000000 802078c4 00000001 00000023 808e0b10 00000000 00000000 00000008
Jan  1 00:01:43 kernel: $8 : 00000023 ffffffcf 00000010 74652301 00005000 00000000 00000000 00000000
Jan  1 00:01:43 kernel: $16: 802177e8 8071a840 808e0ae0 00000000 807ebe98 7fff7948 00000000 7fff7a00
Jan  1 00:01:43 kernel: $24: 00000010 2abd8790                   807ea000 807ebe58 7fff7aaa 800d1af0
Jan  1 00:01:43 kernel: Hi : 00000000
Jan  1 00:01:43 kernel: Lo : 0000000a
Jan  1 00:01:43 kernel: epc  : 800d1b18    Not tainted
Jan  1 00:01:43 kernel: Status: 1000fc03
Jan  1 00:01:43 kernel: Cause : 00000008
Jan  1 00:01:43 kernel: Process pppd (pid: 80, stackpage=807ea000)
Jan  1 00:01:43 kernel: Stack:    80024bb0 00000035 80bcb800 80bcb800 7fff7e08 806b7b58 0000001e
Jan  1 00:01:43 kernel:  00000003 7fff7ed4 7fff7948 800ead94 800ead50 80bc4a90 800c58e0 800c5638
Jan  1 00:01:43 kernel:  800c5620 00000018 00000000 a01a9000 74652301 0e003168 8c282ac5 60002ac9
Jan  1 00:01:43 kernel:  800c1001 fffffff0 80ee79a0 807b0da0 802792e0 802b9b80 80037a44 80776620
Jan  1 00:01:43 kernel:  80042c58 802ab000 80776620 807b0da0 809ba540 00000000 00000003 80035ebc
Jan  1 00:01:43 kernel:  80035ea8 ...
Jan  1 00:01:43 kernel: Call Trace:   [<80024bb0>] [<800ead94>] [<800ead50>] [<800c58e0>] [<800c5638>]
Jan  1 00:01:43 kernel:  [<800c5620>] [<800c1001>] [<80037a44>] [<80042c58>] [<80035ebc>] [<80035ea8>]
Jan  1 00:01:43 kernel:  [<80035f94>] [<800085a4>]
Jan  1 00:01:43 kernel: 
Jan  1 00:01:43 kernel: Code: 00000000  8e450024  24020001 <c0a400e8> 00821823  e0a300e8  1060fffc  00821823  0000000f 
Jan  1 00:01:43 pppd[125]: Plugin rp-pppoe.so loaded.
Jan  1 00:01:43 pppd[125]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Jan  1 00:01:43 pppd[126]: pppd 2.4.2 started by admin, uid 0
Jan  1 00:02:05 wan: connected manually
Jan  1 00:02:06 pppd[126]: Terminating on signal 15.
Jan  1 00:02:06 pppd[126]: recv (receivePacket)
Jan  1 00:02:06 pppd[142]: Plugin rp-pppoe.so loaded.
Jan  1 00:02:06 pppd[142]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Jan  1 00:02:06 pppd[143]: pppd 2.4.2 started by admin, uid 0
Jan  1 00:02:08 wan: connected manually
Jan  1 00:02:09 pppd[143]: Terminating on signal 15.
Jan  1 00:02:09 pppd[143]: recv (receivePacket)
Jan  1 00:02:09 pppd[155]: Plugin rp-pppoe.so loaded.
Jan  1 00:02:09 pppd[155]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Jan  1 00:02:10 pppd[156]: pppd 2.4.2 started by admin, uid 0

[nonnux]

Hello, i am new to this fórum.

i own a WL-500g, and i made this firmware update for first time. everything installed correctly.

the reason for the update was only this SNMP support, and is not working

i am using MRTG with this command:

perl cfgmaker public@10.0.0.1 asus.cfg
----
SNMP Error:
no response received

i didn't found any information about how to activate SNMP, or define the comunity and port.

thanx in advance, and sorry my bad english

excelent work Oleg! great firmware, fórum and support

[nonnux]

i didn't found any information about how to activate SNMP, or define the comunity and port.

just after posting this i found on the admin area that SNMP was inactive.

IP Config > SNMP > Enable SNMP

(on this menu we can also name the comunity!)

sorry for posting garbage, maybe my error could help someone

[Peter2]

Hi, I try to upgrade from 1.9.2.7-3b to 1.9.2.7-6b and for some reason I am unable to finish installation. Luckily I can restart the 500g by cycling the power but it is strange or am I forgetting something ?
So I was lucky/forgetting something, just resetted all parameters and I was able to upload the software.

[sleuther]

Hi Peter,

I was faced a similiar problem. One and only one of several WL500g routers, could not be updated to every version of Olegs software. Unfortunately I never found the reason! Several 1.9.2.7- version ended after upload and reset in a continous reset loop. You can notice a short "flicker" of the power lead every 10 to 15 sec. and the WLAN LED was never activated! I stick up with this problem. The last know version updating and running was 1.9.2.7-5 all ...-6(a,b) did not update to this router. May be that's useful to you to save your time. By the way this behaviour started earlier. Perhaps you search this forum by my user name....

Sigurd

[jjason]

Oleg,
Thanks for replying. Lease time requested by the router is the default, 86400. The lease time indicated in the router log as granted by Bigpond is nearly always 21600. The dropouts occur in multiples of about 27 1/2 minutes after the last lease is granted from Bigpond (i.e., 27.5 mnutes, 55 minutes, 82.5 minutes, etc.). The dropout lasts for about a minute or more. If using a VPN client, it drops out. Likewise with VoiP. This is *very* frustrating. I find it hard to believe that I am the only one with this problem.

I too had the same problem with my Asus 500gx although I have now "fixed" it via a little workaround.

The issue relates to both the Asus firmware and Oleg's firmware apparently a) hardcoding of the BigPond authentication/heartbeat server as an IP address and b) the BigPond domain not being appended to the router's DNS registration.

From what I can see the Asus firmware (and Oleg's firmware) uses the resolv.conf file where it specifies the IP BigPond name servers but does not reference the BigPond domain (e.g. nsw.bigpond.net.au).

With either firmware, bpalogin is executed as part of the startup routine and it uses the bpalogin.conf file. This specifies username/password the IP address for the authentication/heartbeat etc. This means bpalogin logs in ok to BigPond. However, bpalogin actually looks for heartbeats from "sm-server" . Since there is no default domain specified in resolv.conf, sm-server does not resolve to an IP address, thus bpalogin assumes the heartbeat will come from 255.255.255.255. So after it is logged on and the heartbeat arrives from the heartbeat server IP address (not 255.255.255.255), bpalogin ignores it because it isn't expecting the heartbeat from that address. Net effect is after four missed/ignored heartbeats, BigPond drops the connection and bpalogin logs in again. This happens ever 25-27 minutes.

The fix involves changing resolv.conf to add a line "domain nsw.bigpond.net.au" so that when bpalogin starts sm-server is appended with .nsw.bigpond.net.au. This then resolves to the IP address of the heartbeat server and bpalogin is now about to processes the heartbeat from the right IP address (not 255.255.255.255).

The actual workaround a little convoluted due to the fact that resolv.conf is replaced each time the router is rebooted. So you need to create a "post-boot" script which kills the bpalogin upon startup, sleeps a bit, then replaces resolv.conf with an updated one with a domain added and finally re-runs bpalogin.

Bottom line is that the router and the bpalogin connection are now rock-steady.

[Oleg]

I too had the same problem with my Asus 500gx although I have now "fixed" it via a little workaround.

Please post your bpalogin.conf file.

[jjason]

Please post your bpalogin.conf file.

Here it is:

username ########
password ########
authserver dce-server
authdomain nsw.bigpond.net.au
localport 5050
logging syslog
debuglevel 2
minheartbeatinterval 60
maxheartbeatinterval 420
#connectedprog bpa_connect
#disconnectedprog bpa_disconnect

Note the commenting out of the last two lines, these don't appear to be needed.

Unfortunately it is not as simple as replacing bpalogin.conf. From what I can see bpalogin terminates everytime the DHCP client renews its lease. It also appears that bpa_connect is executed each time this happens which results in the modified bpalogin.conf being overwritten with the old/original bpalogin.conf.

Thus, to ensure that each subsequent automatic restart of bpalogin correctly processes the heartbeat it is critical that resolv.conf is updated as part of the post-boot script to append the line "domain <state>.bigpond.net.au" (replace <state> with appropriate value, e.g. nsw, vic, qld etc.). That way each time bpa_connect executes (and thus bpalogin), it can resolve the sm-server to the correct IP address for processing heartbeats.

I'm thinking that if the DHCP client picked up the WAN domain in the first place then none of this would be needed.