Jump to content

Xolo

Members
  • Posts

    12
  • Joined

  • Last visited

About Xolo

  • Birthday 05/22/1980

Extra Info

  • Your CPU
    Intel Centrino Duo T2500 2.0Ghz
  • Your Graphics Card
    ATi Mobility FireGL V5200 256MB
  • Your RAM
    2GB
  • Your Hard Drive
    Hitachi 100GB SATAI
  • Your Sound Card
    Realtek HD Audio Integrated Chipset
  • Your Operating System
    Windows XP Pro SP3, Mandriva 2008.1 (Work/Personal)
  • Your Monitor
    1600x1200 4:3 Wide Viewing Angle FlexView integrated TFT
  • Your Keyboard
    Integrated US International Notebook Keyboard
  • Your Mouse
    UltraNav (Stick/Pad)
  • Your Case
    Titanium-Magnesium Alloy with rollcage (Or hopeless, your pick)

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    The Netherlands
  • Interests
    Linux

Xolo's Achievements

New Here

New Here (1/7)

0

Reputation

  1. You're welcome! I do feel I need to get in touch with Mandriva about this clipboard behaviour, the clipboard contents should under no circumstances be altered, it defeats the purpose and causes all sorts of (serious) trouble, not just in situations where you're asked to enter encryption keys :excl: :blink:
  2. Sorry for the late reply. No MAC restrictions, we currently do not have a central management tool for our AP's so manually entering MACs was considered.. euh, pointless :) I have good news: It now works! The solution was (as with most things that seem impossible to resolve) quite simple... I used a new AP for this test, configuring it to our current standards but leaving out SSID Suppression so the SSID is broadcasted normally. 1. Disable wireless via killswitch on notebook 2. Edit /etc/wpa_supplicant.conf as root with your pet text editor, manually removing all 'dead' wireless stations 3. Enable wireless via killswitch 4. Reopen /etc/wpa_supplicant.conf as root and confirm whether or not wireless station was detected and configured 5. Re-type the WPA encryption key listed under "psk=" header for your AP to be in UPPERCASE and then save the file, exit the editor. Very important! 6. Issue 'service network restart' (again, as root) to stop and restart the network And that was basically it. I will have to wipe and reconfigure the other accesspoints to reflect the new settings with broadcast SSID enabled and remember the above for Mandriva 2008.1 Spring, using ipw2200 wireless on an hp Compaq nc6120 notebook. As for Mandriva (specifically?) It appears that somehow for whatever reason, I just can't copy the WPA key from a textfile and paste it reliably in the GUI configuration tool in KDE or any text editor secondary to the one i'm pasting from, it is always silently converted to lowercase, and this is not accepted by the 3Com Wireless 7760 accesspoint. I found that the paste-converts-to-lowercase 'bug' manifests itself between gVim, Kate, and other text editors when you try to copy the WPA key, and then attempt to paste it into another editor (so in a nutshell, between source and target the copied text gets converted) editing wpa_supplicant.conf. Talk about bad ju-ju going on? I really have done nothing to this system that could cause this strange behaviour, and I must say it is a real show stopper for non-technical people.
  3. This issue remains unresolved. I'm currently awaiting the delivery of the newer 3Com accesspoints, and will try those to see if there is any difference.
  4. I do not have Gnome installed.. I am using KDE (3.xx, Compiz Fusion enabled), the place where I configure my wireless is through NetApplet which sits in the system tray. It handles both wired and wireless connection notification/monitoring/configuration. My attempts to reconfigure the wireless connection through the CLI have been equally fruitless; no connection is made despite correct settings. On the 3Com I can tell an attempt is made to connect; an association seems to be made but the TX is a mere 1Mbit, and during this apparent connection attempt, transmission errors occur. Note that when the accesspoint is stripped of security, it works without a hitch..
  5. Thanks! I have US International set as keyboard layout myself, 'US' or even one matching my local language always throws a wrench in the works with keys being 'in the wrong place' or 'missing'. I located the entry for 'Kill Window' under Control Centre>Regional & Accessibility>Keyboard Shortcuts>Global Shortcuts>System>Miscellaneous>Kill Window, the value there is set to 'Alt+Ctrl+Escape' And apparently it will only trigger if I hit (on the right side of the keyboard) alt gr+ctrl+escape, this brings up 'Process Table - KDE System Guard' showing a realtime updated list of processes currently running on my system. In contrast, it seems all entries in the shortcut list are using alt+ctrl combinations on my system.. the left side of the keyboard is entirely ignored concerning both keys. Note that I did not tweak KDE in any way, I have only updated this system (Mandriva Free Spring 2008.1) so far from online repositories. Now I know why it didn't work, I was hitting the 'wrong' keys :) Edit: typo!
  6. Further testing confirms that I am able to fully associate and connect to the 3Com AP when all security is OFF and SSID broadcast is ENABLED. I can see via ifconfig that I have obtained an IP address (wireless device is eth1): [root@localhost ~]# ifconfig eth0 Link encap:Ethernet HWaddr --:--:--:--:--:-- UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:16 eth1 Link encap:Ethernet HWaddr --:--:--:--:--:-- inet addr:172.22.4.63 Bcast:172.22.7.255 Mask:255.255.252.0 inet6 addr: fe80::216:6fff:fe3e:f1bc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1184 errors:6240 dropped:6240 overruns:0 frame:0 TX packets:776 errors:0 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:1000 RX bytes:1662910 (1.5 MiB) TX bytes:1467102 (1.3 MiB) Interrupt:22 Memory:d0000000-d0000fff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:758 errors:0 dropped:0 overruns:0 frame:0 TX packets:758 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:61764 (60.3 KiB) TX bytes:61764 (60.3 KiB) On eth0, the HWaddr shows the 3Com AP's wireless MAC. MACs have been omitted in this post. Via the AP's wireless station list I can confirm the connection at an RX rate of 54Mbps at -56dBm signal strength for both RX and TX ACK. So, I am able to connect to it, but enabling any kind of security apparently breaks it. My last resort would be to wipe the wireless accesspoints that were written to /etc/wpa_supplicant.conf and do a firmware update (if any available, that is) on the 3Com and try again to see if a 'clean' start can help the situation.
  7. Unfortunately, enabling the SSID broadcasting seems to have had zero effect, the situation remains the same. Through the AP's wireless configuration, SSID suppression was disabled, the setting was saved and the device was rebooted. As an extra measure, I disabled the wireless radio on my notebook via the software controlled button at the top of the keyboard, waited 20 seconds, and re-enabled the radio, then proceeded to the wireless controlpanel to view the status. At the moment once again the controlpanel does not allow me to edit the SSID field (locked/greyed) although I see the correct SSID written there. It is also very persistent in converting the entire WPA key of 63 characters (Maximum supported by AP) into lowercase, but the key is supposed to be uppercase. The key is always converted to lowercase, no matter how many times I paste or retype it into the key field; once saved it is lowercase. I could go ahead and disable security on the AP entirely as a test, but leaving it that way is undesirable as it sits inside the corporate perimeter, and thus security is mandatory for continuous operation.
  8. Hardware: hp Compaq nc6120 business notebook, relevant hardware is the IntelĀ® PRO/Wireless 2200/2915 chipset. Situation: Notebook is currently running Mandriva Free 2008 (Spring, 2008.1) and everything seems OK. Wireless at home via a Linksys WRT54G broadband router (running OpenWRT) using WPA encryption works OK. Curiosity is however, signal strength is shown as a value over 100% at all times. This did NOT change with updates! What is at fault: Wireless, this seems the picky part. The notebook was installed by use of DVD media, and updated via wired ethernet network. Wireless configuration was completed using the available controlpanel software in KDE; additional software was requested by the controlpanel and automatically retrieved and installed by the same controlpanel via wired ethernet. Wireless at home to the WRT54G is as perfect as you could describe it, WPA encryption and high speed, stable. Wireless at work, the accesspoint(s)(4 pieces, soon 6) is/are 3Com Wireless 7760 11a/b/g PoE AP's, using WPA and Supressed SSID. Wireless at work, does not work. The accesspoints can be seen in the air displayed by their MAC address (not by name), but supplying the SSID and accompanying WPA key will not enable any kind of networking. In contrast, when one uses the controlpanel to select, configure and connect to the AP, nothing happens. In 9 out of 10 tries of configuring an AP, the field where one can enter the SSID becomes gray and unconfigurable. Also, which is beyond my understanding, the controlpanel does not allow the REMOVAL of access points; one can only change or connect these while they are in range. Taking the notebook home ofcourse immediately brings up wireless without fail, but I need to work, so I wish it to work here in the office too. Any ideas? I have been trawling nearly all topics regarding the subject of the IPW2200 software/firmwares, but none of these are of any help. Thanks in advance.
  9. Curiosity; Not seeing this behaviour in a default install of Mandriva Spring 2008 (2008.1) within KDE; i.e. nothing happens. Personal tweak by you?
×
×
  • Create New...