Firmware v1.9.2.7 CR2 [Oleg]

[garimo]

Hallo everybody, first thing first a big thanks to Oleg not only because of the Firmware but also for his custom firmware page.
My WL-500g run vs. 1.9.2.7-2 work as a charm but i still have a short
request: I know the support for Samba is very limited but i still would like
to know if the share$ is on purpose kept read only

[Oleg]

Hallo everybody, first thing first a big thanks to Oleg not only because of the Firmware but also for his custom firmware page.
My WL-500g run vs. 1.9.2.7-2 work as a charm but i still have a short
request: I know the support for Samba is very limited but i still would like
to know if the share$ is on purpose kept read only

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

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

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

Here is what i found in log:

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.cptp_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.cptp_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.cptp_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.cptp_inbound_pkt: inbound control message SET_LINK_INFO
Jan 4 18:55:44 kernel: ip_conntrack_pptp.cptp_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.cptp_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.cptp_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.cptp_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.cptp_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

[Technik]

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.

[oldudu]

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

[garimo]

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.

[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

[Technik]

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.

[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