Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 25 Oct 2014, 19:35
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
Frisbee Network Manager - Beta 2
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 24 of 27 Posts_count   Goto page: Previous 1, 2, 3, ..., 22, 23, 24, 25, 26, 27 Next
Author Message
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Sat 19 Jul 2014, 11:53    Post_subject:  

rerwin wrote:


BTW, thank you, Marv, for joining our dropwait session and reporting your testing. It sounds like the new 1-second-apart carrier checks are just what you need, if your dropouts last only a few seconds. Now, if could only figure out Scooby's "disable wireless" solution.
Richard


Indeed, duration of my dropouts is 3 seconds. See below. Makes for an interesting testbed. The 6.3.2 spup versions continues to work well subjectively with the dropwait time set to 4 seconds for now.
Code:
Jul 19 09:45:10 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:46:50 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:46:51 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:48:31 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:48:32 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:50:12 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:50:13 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds


Thank you Exclamation

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
Scooby

Joined: 03 Mar 2012
Posts: 319

PostPosted: Mon 21 Jul 2014, 17:25    Post_subject:  

Code:
> cat /var/log/everything/current | grep carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier acquired
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier lost
Jul 21 16:25:49 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:25:49 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:32 [dhcpcd] enp4s0: waiting for carrier


been running for a while( a couple of hours) with dropwait 5 sec

I never seem to get these messages
Code:
syslog(LOG_INFO, "%s: carrier lost temporarily for %d seconds", ifname, i);


If I have dropwait set to 0 I get some carrier's lost
but with 5 secs I have not experienced any!?
Back to top
View user's profile Send_private_message 
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Mon 21 Jul 2014, 19:28    Post_subject:  

If I set dropwait to 0 on the above system, no 'carrier temporarily lost' messages at all are generated but it forces a reconnect and renews the lease pretty much every minute or two. With a dropwait of 4 seconds, 'carrier temporarily lost' messages are logged every 108 seconds but dhcpcd waits them out as (I assume) it is supposed to do. Over several days now with dropwait set at 4 seconds and normal use, lid suspend, browsing, sfs creation etc., no reconnecting at all on this system. I'm running right now with dropwait of 0 and it's reconnected 4 times while I wrote this.
_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Wed 23 Jul 2014, 15:57    Post_subject: Hopefully nearly final versions of latest dhcpcd  

Marv, Scooby and other dropwait users,
After much experimentation I have settled on my adaptation of dhcpcd, to provide some tolerance of carrier dropouts while also ensuring that disabling (disconnecting) wireless continues to work reliably as expected. My goal is to minimize the risk of any mods inadvertently impacting the complicated operation of dhcpcd. I have narrowed the purpose of dropwait to be only for ignoring short outages, so that any delays caused by dropwait are minimal, particularly for link terminations during boot-up that would slow the process.

Now that the developer has made more bug fixes to the 6.4.x version, I start with 6.4.2. However, I discovered that the releasing of a wireless link requires 11 seconds on my Pentium II (266 MHz) laptop, which I consider the "worse case" to support. My netbook require almost as long. Since a timeout limit of 10 seconds results in killing the release process, leaving the situation Scooby has reported regarding the IP address remaining in the network status report.

The attached "patched" version of dhcpcd-6.4.2 has the timeout increased to 15 seconds. I propose that that version be considered the standard version because it retains all of the original design. The "patched-dropwait" version is offered for those needing more tolerance for carrier dropouts of short duration. I selected a fixed value of 3 seconds based on Marv's report of a 1 second dropout followed by a 2-second one. For this version, I added 3 seconds to the increased timeout value. Both versions are suitable for all puppies -- they adapt themselves for slacko installations.

Because I discovered that the network tray icon and link notification popups did not work when the user disabled wireless, I include a fix in the pinstall script for both patched versions. Instead of using the RELEASE "hook" when a link is released, the STOP hook is now used. the network_tray and notify hook scripts did not respond to the STOP hook, so indicate the link is still up. The pinstall script updates those hook scripts, which need to be fixed in the woof versions of them.

In the source tarballs, I include the patch file that would convert an original dhcpcd to the modified version. I also include a "README-...wait" file with patch instructions and configuration commands. (I would like to add commands for 64-bit systems, if someone would give them to me.)

Please try these latest packages and tell me of any problems that make them unacceptable for general use. Thanks for your help.
Richard

EDIT - Additional details of this "dropwait" implementation:
    1. The two new or modified "info" messages are:
      version 6.4.2-dropwait starting
      momentary carrier loss ignored

    2. The "-j --dropwait" option argument is eliminated. The user or developer uses either the standard dhcpcd or the "dropwait" version. The minimalist modifications to the original should avoid inadvertent impact to the operation of dhcpcd.

    3. The primary difference in behavior of the "disable wireless" (release) function since 5.6.4 appears to be that signal interruption of the daemon controlling the wifi link is limited, preventing the dropwait delay from being interrupted to release a link. I am reluctant to interfere with the developer's design, to try to enable interruption during the wait period.


UPDATE 7/25/2014: I repackaged the "pets" to make a separate set for use in Slacko puppies, rather than trying to be clever and make single, adaptable versions. The difference in the Slacko versions is that the "hook" files and script reside in /usr/libexec instead of /lib/dhcpcd. They function the same as the previous set with the workaround for slacko.

During testing of dhcpcd, using frisbee, I found some things to fix in frisbee-1.2, so will be uploading that shortly. With the new 6.4.2 dhcpcd, frisbee will no longer contain the button for setting the drop timeout value, because the value is fixed at 3 seconds. R
dhcpcd-6.4.2-patched-i686.pet
Description  "Standard" package - as released but with wait for daemon exit extended by 5 seconds.
(Not for slacko)
pet

 Download 
Filename  dhcpcd-6.4.2-patched-i686.pet 
Filesize  112.44 KB 
Downloaded  41 Time(s) 
dhcpcd-6.4.2-patched-slacko-i686.pet
Description  For Slacko installations and any pups using dhcpcd-hooks in /usr/libexec.
"Standard" package - as released but with wait for daemon exit extended by 5 seconds.
pet

 Download 
Filename  dhcpcd-6.4.2-patched-slacko-i686.pet 
Filesize  113.16 KB 
Downloaded  37 Time(s) 
dhcpcd-6.4.2-patched-dropwait-i686.pet
Description  Optional package for ignoring carrier dropouts up to 3 seconds.
(Not for slacko)
pet

 Download 
Filename  dhcpcd-6.4.2-patched-dropwait-i686.pet 
Filesize  112.57 KB 
Downloaded  33 Time(s) 
dhcpcd-6.4.2-patched-dropwait-slacko-i686.pet
Description  For Slacko installations and any pups using dhcpcd-hooks in /usr/libexec.
Optional package for ignoring carrier dropouts up to 3 seconds.
pet

 Download 
Filename  dhcpcd-6.4.2-patched-dropwait-slacko-i686.pet 
Filesize  127.33 KB 
Downloaded  37 Time(s) 
dhcpcd-6.4.2-patched.tar.gz
Description  Source - Original version but with exit wait period increased to 15 seconds (from 10)
gz

 Download 
Filename  dhcpcd-6.4.2-patched.tar.gz 
Filesize  205.26 KB 
Downloaded  36 Time(s) 
dhcpcd-6.4.2-patched-dropwait.tar.gz
Description  Source - single dropwait of 3 seconds
gz

 Download 
Filename  dhcpcd-6.4.2-patched-dropwait.tar.gz 
Filesize  205.82 KB 
Downloaded  41 Time(s) 

Edited_times_total
Back to top
View user's profile Send_private_message 
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Thu 24 Jul 2014, 11:23    Post_subject: dhcpcd-6.4.2-patched-dropwait-i686.pet testing  

Testing the above pet in X-slacko 2.1 on a Pentium M ipw2200 laptop, the identical setup used to sucessfully test the 6.3.2 spup dhcpcd with dropwait.
6.3.2 uninstalled, wireless disconnected, profile and resolv.conf deleted. 6.4.2 installed from pet, Frisbee used to reconnect. IP acquired correctly but resolv.conf not written so no DNS available. Rechecked with a reboot, with and without the resolv.conf stub (no nameservers) in place with the same results. Switched back to 6.3.2 after uninstalling 6.4.2. Resolv.conf immediately created and correct. Back to 6.4.2 again. Same result as before. Dropouts seem to be handled fine, just no resolv.conf. Copying in a resolv.conf or using a resolv.conf.head gets it going. Posting running with it now.

The tar.gz attached contains a sample of the dropout handling and a dhcpcd log snippet for 6.3.2 and 6.4.2.

Anything else I should try or log for now?

Edited once, added 'copy in resolv.conf and running now' stuff
dhcpcdlogs.tar.gz
Description  two dhcpcd log snips and a temp dropout sample
gz

 Download 
Filename  dhcpcdlogs.tar.gz 
Filesize  1.31 KB 
Downloaded  36 Time(s) 

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Fri 25 Jul 2014, 10:37    Post_subject:  

Marv,
Thanks for your report. I now have both slacko-5.7.0 and xslacko-2.1 installed on my netbook for testing. I see the problem you report occurring in both of my slackos but not in lupusuper2 or precise-5.7.1. That narrows it a bit. It may take some time to find the culprit in the slackos. I also see that the new wpa-supplicant hook is reporting an exit code of 127, whatever that means, but only in the slackos. They are probably related.

On a hunch, I added 2 dhcpcd-hooks links from /lib/dhcpcd to /usr/libexec. That cured both problems! The WEXIT... message implies that it was issued by a file in /lib/dhcpcd, which has never had the dhcpcd-run-hooks script in slacko. So, that is a mystery. But we have the workaround.
Code:
ln -snf /usr/libexec/dhcpcd-hooks /lib/dhcpcd/dhcpcd-hooks
ln -snf /usr/libexec/dhcpcd-run-hooks /lib/dhcpcd/dhcpcd-run-hooks
Hmmm. Maybe the configure command affects the directory name compiled into the dhcpcd executable. If so, I need to make separate pet packages for slacko. I assumed the names are set only in the scripts; maybe not.
R
Back to top
View user's profile Send_private_message 
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Fri 25 Jul 2014, 12:19    Post_subject:  

rerwin wrote:

On a hunch, I added 2 dhcpcd-hooks links from /lib/dhcpcd to /usr/libexec. That cured both problems! The WEXIT... message implies that it was issued by a file in /lib/dhcpcd, which has never had the dhcpcd-run-hooks script in slacko. So, that is a mystery. But we have the workaround.
Code:
ln -snf /usr/libexec/dhcpcd-hooks /lib/dhcpcd/dhcpcd-hooks
ln -snf /usr/libexec/dhcpcd-run-hooks /lib/dhcpcd/dhcpcd-run-hooks
Hmmm. Maybe the configure command affects the directory name compiled into the dhcpcd executable. If so, I need to make separate pet packages for slacko. I assumed the names are set only in the scripts; maybe not.
R

Running correctly with the workaround here.

Thanks

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Fri 25 Jul 2014, 20:29    Post_subject:  

"Running correctly" is good to hear! Thanks.

I have uploaded separate pet packages for slacko puppies and re-uploaded the main versions with the "adaptation" logic removed:
http://www.murga-linux.com/puppy/viewtopic.php?p=790629#790629
Be sure to use the appropriate slacko/all-others package for your puppy.

While testing the various dhcpcd versions, I fixed some minor bugs in frisbee-1.2 that might be useful where the new dhcpcd is in use (although there is no dependency between them). The new frisbee package is 20140724 at:
http://www.murga-linux.com/puppy/viewtopic.php?p=780962#780962
Back to top
View user's profile Send_private_message 
Scooby

Joined: 03 Mar 2012
Posts: 319

PostPosted: Sat 26 Jul 2014, 15:27    Post_subject:  

Sounds good

I will bundle them up for alphaos.

I will be less usefull as a tester cause I got optical fibre with ethernet port
in my wall in my new apartement so I am not using wlan at the moment
Back to top
View user's profile Send_private_message 
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Sat 26 Jul 2014, 15:57    Post_subject:  

Currently running the most recent dhcpcd-6.4.2-patched-dropwait-slacko-i686.pet and the updated Frisbee 1.2 in X-slacko 2.1 on the 1.6GHz Pentium M with intel ipw2200 wireless. All prior versions and configuration files/profiles stripped before installation. All seems well. WPA2 connection works, resolv.conf populated correctly, carrier dropouts of 1 and 2 seconds 'waited out', and the Frisbee dialog boxes in the Diagnostics pane correctly reflect my configuration.

dhcpcd-6.4.2-patched-dropwait-i686.pet running correctly on Carolite 1.2 (with Battleshooters 3.15 kernel swap). Resolv.conf ok, 3 second dropouts waited out ok.

I can't check the current Frisbee completely on that as it needs a newer net_tray than Carolite has and in general I run peasywifi there as it handles the wpa2/ipw2200 combo better (both in original and 3.15 kernel). Just why THAT is remains a mystery to me. Peasywifi and Frisbee are calling the same wpa_supplicant and requesting the newer wext driver for the ipw2200. I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool. Frisbee 1.2 run from a terminal and Frisbee beta-4 behave identically in this respect. Peasywifi, on the other hand, starting from scratch in Carolite (either kernel) just accepts the password, creates the profile and connects. I've looked at the line that calls wpa_supplicant in both and see no significant differences. Just an aside and pretty much a nonevent as Frisbee works perfectly with that troublesome card/WPA2 combo in all newer pups I've run, both precise and slacko based.

Given a rainy (non-firewood cutting) day I'll install the above on my iwlwifi laptop and test.

Edited to add Carolite test.

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Mon 28 Jul 2014, 10:51    Post_subject:  

Marv wrote:
I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool.
The modprobing of the modules you mention may be something I can automate with a modprobe configuration file. Please tell me more about what you know about your technique. Thanks. R
Back to top
View user's profile Send_private_message 
Marv


Joined: 04 May 2005
Posts: 350
Location: SW Wisconsin

PostPosted: Mon 28 Jul 2014, 14:43    Post_subject:  

rerwin wrote:
Marv wrote:
I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool.
The modprobing of the modules you mention may be something I can automate with a modprobe configuration file. Please tell me more about what you know about your technique. Thanks. R


It.. or I.. isn't consistent enough so I can explain or implement it. To be honest, I now usually just snitch a working profile from one of my other pups. I'm going to continue to try and understand why peasywifi, which does no explicit modprobing, works in Carolite 1.2 and Frisbee (either beta-4 or 1.2) doesn't in exactly the same installation. I'm quite sure that the failure is due to the ipw2200 being WPA capable but not 'officially' so.

Sorry I can't do better.

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.2n, Lxpup-Tahr, and not to forget trusty Carolina/Carolite (now with 3.17 kernel). All lean and steady pups.
Back to top
View user's profile Send_private_message 
stray_dog

Joined: 18 Mar 2014
Posts: 47

PostPosted: Tue 29 Jul 2014, 21:43    Post_subject:  

Dear rerwin, between the frisbee 1.2 and the updates to dhcpd, you really made a big difference to how easily my wifi works & connects to open networks with slacko 5.6! Thank you! Would you like to get married?
Back to top
View user's profile Send_private_message 
Scooby

Joined: 03 Mar 2012
Posts: 319

PostPosted: Tue 05 Aug 2014, 15:39    Post_subject:  

Found some time for packaging frisbee for alphaos

1. frisbee-1.2-20140724.pet has removed /usr/sbin/dhcpcd_dropwait_option

But I think /usr/local/frisbe/func still uses it?

Will you please confirm if it should be included or safely discarded?

2. About /usr/local/bin/frisbee
I want to discuss the way you check for only one script running at the time.
The drawback with your aproach is that you have to add a lot of grep -v
like the one you've added for geany ( I would have to add emendo for instance)

Does puppy contain flock command? if so maybe try
( from here )
Code:

LOCKFILE="/tmp/frisbee.lock"
LOCKFD=99

# PRIVATE
_lock()             { flock -$1 $LOCKFD; }
_no_more_locking()  { _lock u; _lock xn && rm -f $LOCKFILE; }
_prepare_locking()  { eval "exec $LOCKFD>\"$LOCKFILE\""; trap _no_more_locking EXIT; }

# ON START
_prepare_locking

# PUBLIC
exlock_now()        { _lock xn; }  # obtain an exclusive lock immediately or fail
exlock()            { _lock x; }   # obtain an exclusive lock
shlock()            { _lock s; }   # obtain a shared lock
unlock()            { _lock u; }   # drop a lock

if ! exlock_now; then
   gtkdialog-splash -placement center -timeout 10 -bg orange -text "$(gettext 'Frisbee is already running.')"
   exit
fi




*UPDATE* fuser aproach doesn't seem to work if you restart wpa_supplicant
it will retain filehandle and then you cannot start frisbee.
I will keep fuser approach below for reference


--------------------------------- BEGIN does not work -----------------------------------------------------

Does puppies have fuser command? if so I like
(from here a little bit down)
Code:

#       mutex file
#
# Open a mutual exclusion lock on the file, unless another process already owns one.
#
# If the file is already locked by another process, the operation fails.
# This function defines a lock on a file as having a file descriptor open to the file.
# This function uses FD 9 to open a lock on the file.  To release the lock, close FD 9:
# exec 9>&-
#
mutex() {
    local file=$1 pid pids

    exec 9>>"$file"
    { pids=$(fuser -f "$file"); } 2>&- 9>&-
    for pid in $pids; do
        [[ $pid = $$ ]] && continue

        exec 9>&-
        return 1 # Locked by a pid.
    done
}
mutex /var/run/frisbee.lock || { echo "Already running." >&2; exit 1; }


*UPDATE* tried below it didn't work but it seems to work if you put both
mutex function and check in frisbee file

OBS! doesn't work! You could put function mutex in /usr/local/frisbee/func and
only keep last codeline(or modified to fit) in frisbee file.

--------------------------------- END does not work -------------------------------------------

also I think I would have to adjust "which frisbee"
for me it returns "frisbee is /usr/local/bin/frisbee"
And it is not the same for you right?

Okay remered now that I have which aliased to "type -a"

3. Shouldn't you up the version maybe to something like 1.2.1???
I mean in --version output

4. I didn't get the new dhcpcd-hook scripts, they were files of size 0
Will test and see if they work. answer: don't work
re-added old 99-notify, and they work aagain.

5. *UPDATE* variable TERMEMLTR must be exported in frisbee

6. *UPDATE* on "Network interfaces" tab when pressing "view DHCP log"
/var/log/messages is used. My log is at /var/log/everything/current.
This could be solved with a symlink, Is this the way we should solve it or an entry
in frisbee.conf?


I will make a test package for alphaos and run for a while

I am very pleased with the new version, good job
Back to top
View user's profile Send_private_message 
bigpup


Joined: 11 Oct 2009
Posts: 5237
Location: Charleston S.C. USA

PostPosted: Mon 11 Aug 2014, 02:22    Post_subject:  

rerwin,

rcrsn51 has maybe invented the better mouse trap for wifi connection.
Maybe you two could get together and compare notes.
At least bounce ideas off each other.

His wifi connection manager is here:
PeasyWiFi
http://murga-linux.com/puppy/viewtopic.php?t=94501

_________________
I have found, in trying to help people, that the things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected Shocked
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 24 of 27 Posts_count   Goto page: Previous 1, 2, 3, ..., 22, 23, 24, 25, 26, 27 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2244s ][ Queries: 12 (0.1039s) ][ GZIP on ]