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

Printable View

Show 40 post(s) from this thread on one page

18-10-2005, 12:10
iog

1.9.2.7-6b still drops out with bigpond cable

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. :confused:
18-10-2005, 15:28
Oleg

Have you checked lease time, provided by BigPond? Perhaps, it's about 1 hour, which is too low.
19-10-2005, 04:19
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.
26-10-2005, 14:30
iog

Dropouts solved!

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.
27-10-2005, 11:26
Oleg

Quote:

Originally Posted by 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.

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.
27-10-2005, 15:00
iog

Quote:

Originally Posted by Oleg

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.
09-11-2005, 01:21
Adverse

Quote:

Originally Posted by iog

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
25-12-2005, 22:18
fabiosantos

1.9.2.7-6b

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???

Code:

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
28-12-2005, 13:03
nonnux

SNMP not working

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
28-12-2005, 13:23
nonnux

Quote:

Originally Posted by 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
30-12-2005, 21:20
Peter2

Upgrade from 1.9.2.7-3b fails ???

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.
03-01-2006, 15:13
sleuther

Upgrade problems

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
07-02-2006, 00:45
jjason

Quote:

Originally Posted by 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.

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.
07-02-2006, 09:45
Oleg

Quote:

Originally Posted by jjason

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.
08-02-2006, 11:05
jjason

Quote:

Originally Posted by Oleg

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.

Show 40 post(s) from this thread on one page