Firmware v1.9.2.7 CR2 [Oleg]

Printable View

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

05-01-2005, 00:48
dsf260

Just to update:

The router has not crashed/locked up/ or lost the WAN connection since yesterday. It seems that one of the problems is solved, although I don't know if it is because I went back to 1.8.1.7-3 or if it is truly a problem with a printer that is unpowered but attached to the WL-500g.

Also, I still cannot get a WAN connection when using the et command except if I it set it to auto. Here's the syntax I use

et -i eth1 speed XXX

where XXX = auto, 100full, 10full, 100half, or 10half. I have tried all speeds and firmwares 1.8.1.7-3, 1.9.2.7-1, and 1.9.2.7-2. My cable modem is a Toshiba PCX2500--perhaps it's some conflict with the modem?
05-01-2005, 08:29
pipos

Problem with VPN

Hi,

i have this problem with 1.9.2.7CR-2 using in client mode.
While I'm copuing files from my VPN (i'm also connected to VPN server), my Asus goes down after while.
if I'm not connected to VPN everything is OK.

in fw 1.7.9.5-5 i havent this problem.
What could i tried to fix?

Here is what i found in log:

Quote:

Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:08 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:20 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:41 kernel: ip_conntrack_pptp.c:pptp_outbound_pkt: outbound control message ECHO_REQUEST
Jan 4 18:55:41 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 3->3
Jan 4 18:55:41 kernel: ip_conntrack_pptp.c:pptp_inbound_pkt: inbound control message ECHO_REPLY
Jan 4 18:55:41 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 3->3
Jan 4 18:55:42 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:pptp_outbound_pkt: outbound control message SET_LINK_INFO
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 3->3
Jan 4 18:55:44 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 66e for tuple 172.16.1.248:0x0 -> 172.16.2.100:0x0:1:0x880b
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:pptp_inbound_pkt: inbound control message SET_LINK_INFO
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:pptp_inbound_pkt: invalid SET_LINK_INFO (TY=15)
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 3->3
Jan 4 18:55:44 kernel: ip_conntrack_proto_gre.c:gre_pkt_to_tuple: found src key 0 for tuple 192.168.1.10:0x0 -> 172.16.1.248:0x66e:1:0x880b
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:pptp_outbound_pkt: outbound control message CALL_CLEAR_REQUEST
Jan 4 18:55:44 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 3->7
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:pptp_outbound_pkt: outbound control message STOP_SESSION_REQUEST
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 4->2, cstate: 7->7
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:pptp_inbound_pkt: inbound control message STOP_SESSION_REPLY
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: sstate: 2->0, cstate: 7->7
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: RST/FIN received, timeouting GRE
Jan 4 18:55:45 kernel: ip_conntrack_proto_gre.c:ip_ct_gre_keymap_destroy: entering for exp 80c24780
Jan 4 18:55:45 kernel: ip_conntrack_proto_gre.c:ip_ct_gre_keymap_destroy: removing 808246a0 from list
Jan 4 18:55:45 kernel: ip_conntrack_proto_gre.c:ip_ct_gre_keymap_destroy: removing 80824660 from list
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:pptp_timeout_related: setting timeout of conntrack 807eea60 to 0
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
Jan 4 18:55:45 kernel: ip_conntrack_proto_gre.c:gre_destroy: entering
Jan 4 18:55:45 kernel: ip_conntrack_proto_gre.c:ip_ct_gre_keymap_destroy: entering for exp 80c24780
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: RST/FIN received, timeouting GRE
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
Jan 4 18:55:45 kernel: ip_conntrack_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
J
05-01-2005, 10:34
oldudu

Quote:

Originally Posted by Oleg

Wait for 1.9.2.7-3 or use search. Answered question yesterday. Hint: change user name to root.

Or change root to admin in smb.conf

Friendly

Oldudu
05-01-2005, 15:37
garimo

samba on 1.9.2.7-2

thanks you all for replay, i got it working and you guys were right.
But my problem was that i changed in system setup the name "admin" for security reason, so in /etc/smb.conf force user = admin was not working and most likely also root for the same reason. It only worked with my login name.
06-01-2005, 22:54
Alexis

FTP & Webcam Server don't work through a router

My WL500G is used in access point behind a router (another ASUS).
Port forwarding is configure on the router to forward service FTP (port 21) and webcam (port 7776)
The problem is that FTP and webcam server don't work from wan access.
(It works in lan access).
The problem is the same when the router is a netgear or asus router.

Could you find a solution to my problem ?
Thank you
Alexis
07-01-2005, 01:37
Technik

Quote:

Originally Posted by pipos

Hi,

i have this problem with 1.9.2.7CR-2 using in client mode.
While I'm copuing files from my VPN (i'm also connected to VPN server), my Asus goes down after while.
if I'm not connected to VPN everything is OK.

in fw 1.7.9.5-5 i havent this problem.
What could i tried to fix?

Aren't you running on WinXP SP1? Is the connection lost in few minutes even if there's no data traffic? I suppose that "goes down" does not mean reboot nor hang.
If that's the case, try to stop the Windows Management Instrumentation service before your VPN access attempt. SP2 update could also help.
07-01-2005, 01:44
Technik

Quote:

Originally Posted by Alexis

My WL500G is used in access point behind a router (another ASUS).
Port forwarding is configure on the router to forward service FTP (port 21) and webcam (port 7776)
The problem is that FTP and webcam server don't work from wan access.
(It works in lan access).
The problem is the same when the router is a netgear or asus router.

Could you find a solution to my problem ?
Thank you
Alexis

Try to search the forum and double check your configuration. Try to configure the router from scratch (apply reset to defaults first).
In case you can't fix the problem still, specify your firmware version and more config related details.
07-01-2005, 10:17
pipos

VPN Hang

I'm Running WinXP SP2,

It looks like eth2 die....

when i look at the shell and run top....the 5min avg usage goes up to 2.5 and then it disconetcs...

whne not in VPN...usage is cca 0.2
07-01-2005, 12:21
Technik

Quote:

Originally Posted by pipos

I'm Running WinXP SP2,

It looks like eth2 die....

when i look at the shell and run top....the 5min avg usage goes up to 2.5 and then it disconetcs...

whne not in VPN...usage is cca 0.2

OK so you loose the wireless connectivity completely. What you do to make it working again? Do you have to reboot the router or do you just initialize the interface somehow?
What's the free memory status?
07-01-2005, 12:53
Antiloop

Quote:

Originally Posted by pipos

I'm Running WinXP SP2,

It looks like eth2 die....

when i look at the shell and run top....the 5min avg usage goes up to 2.5 and then it disconetcs...

whne not in VPN...usage is cca 0.2

could you supply a testaccount or something to test so I can confirm the possible 'bug' ?
08-01-2005, 13:05
wiz

Quote:

Originally Posted by pipos

I'm Running WinXP SP2,

It looks like eth2 die....

when i look at the shell and run top....the 5min avg usage goes up to 2.5 and then it disconetcs...

whne not in VPN...usage is cca 0.2

That's strange. I've been using VPN as well, and without any problems. Even with transferring large files, my vpn connection stayed up throughout the whole day, and so did my Asus.

I use it to work from home, so I "hook up" my laptop wireless and work the whole day.

I've been running olegs 1.9.2.7-2 . I've just fired up a vpn connection to the office, and my average doesn't go up.
It runs rock solid over here.
08-01-2005, 23:26
Technik

Quote:

Originally Posted by wiz

That's strange. I've been using VPN as well, and without any problems. Even with transferring large files, my vpn connection stayed up throughout the whole day, and so did my Asus.

I use it to work from home, so I "hook up" my laptop wireless and work the whole day.

I've been running olegs 1.9.2.7-2 . I've just fired up a vpn connection to the office, and my average doesn't go up.
It runs rock solid over here.

...using in client mode...
That's the difference!
09-01-2005, 09:25
Oleg

Addiotinal load was probably caused by debug messages produced by pptp kernel modules - try 1.9.2.7-3.
09-01-2005, 19:33
yato

QoS, Bandwidth management

I have found, that 1.9.2.7 firmware is is using command tc for bandwidth management and is distinct from wshaper added by Oleg.
Is someone using that?
Should I use tc or wshaper approach?
Can anyone suggest me which is better?
09-01-2005, 19:35
yato

Bandwidth management GUI

Also I have discovered that limits labeled as kbps (kilobits) in GUI are kBps (kilobytes) in fact (tc reports numbers eight times higher than entered!)
So, it looks like QoS doesn't work, but if you divide limits by eight, it works fine - maybe Oleg can fix that in custom FW.

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