I accidentally deleted the IOS on 3750G Switch. As a result, I am thrown in the ROMMON mode when I console into the switch via Putty. I tried the following:
1) I set up my static IP as 192.168.168.167 255.255.255.0 with default gateway as the same as my switch's IP 192.168.168.168
2) I set the IP on the switch as 192.168.168.168 255.255.255.0 and default gateway as 192.168.168.167. I set the TFTP Server's IP same as my laptop's static IP.
3) Then I typed tftpdnld after I placed the new IOS on the to TFTP root folder.
That failed when I did all this on Putty. The switch was not able to read the Ethernet cable.
By the way, the show command does not work on ROMMON mode via Putty
Furthermore, the show command does not work on ROMMON mode. I have the IOS that will be uploaded into the switch. But how do I do that? Please help. Thanks. I am doing all this via console. Here is the site I used as a guide: http://www.mikcx.com/cisco-ios-deleted-by-mistake-recovery-guide/
I got it fixed and followed the rules below (I used ExtraPutty!!)
There are times when the IOS on a switch may crash and (as a last resort) you need to use the painfully slow Xmodem transfer to save your life. I bought a 3550 a while back and that is precisely what happened with me. Without much else to try, I decided to give Xmodem a shot. I want to share how this can be used and I hope that this may be useful to others.
Since the device is in ROMMON, there’s not much that you can do. There is, however, a method to transfer another IOS using a direct console connection with a PC (the transfer is over your console cable itself). This wonderful little thing is called Xmodem. Now the rate of transfer depends on the baud rate that you set for your console connection. I tried this with baud set to 9600 and man, it seemed like it would take over 3 hours for the transfer to complete. With a little trial and error, I found that the maximum baud rate I could set it up to work perfectly with was 57600. You can set the baud rate in ROMMON using the set BAUD command. See below:
switch: set BAUD 57600
This MUST also match on the terminal program setting as well. So (I’m using TeraTerm) under Setup -> Serial Port, set the baud rate to match whatever you set it as in ROMMON. Now we’re ready to transfer the file. The command is very straight forward:
switch: copy xmodem: flash:c3550-ipservicesk9-mz.122-44.SE6.bin
Once you press enter, you see the following:
Begin the Xmodem or Xmodem-1K transfer now…
C
At this point, you need to choose the file location from the terminal program. Go under File -> Transfer -> Xmodem -> Send and choose the file that you wish the transfer. The transfer will start and you will see a transfer window pop up. I made sure when the following image popped on ExtraPutty terminal ---> flash:c3750-ipbasek9-mz.150-2.SE8.bin Begin the Xmodem or Xmodem-1K transfer now... CCCCCCCCCCxmodem and I quickly went to the panel and click Xmodem located at the panel on top and click send and drag the c3750-ipbasek9-mz.150-2.SE8.bin file and have it sent through. Hence it explained why I kept get an I/O error, which made sense. Input error because the switch was waiting for me to send it the OS file.
Please take a look at this link for future reference and many thanks to this author who wrote this up: https://supportforums.cisco.com/blog/151336/loading-ios-switch-xmodem
Related
I recently installed Manjaro i3 on my laptop and tried to connect an external Monitor, to extend the main Screen when it's plugged in and just use the single monitor mode when not.
This seems to mostly work using arandr. Unfortunately I have to reapply the arandr settings again on every boot to get my layout back, since it gets reset every time.
I have tried exporting the arandr commands to .xinitrc and /root/xinitrc, I have tried editing the xorg confs and I have tried putting it into .screenlayout, but with no result.
So how can I permanently set my screen resolution and layout?
I case somebody comes across this question:
1. open arandr
2. Set your desired layout
3. Export it
4. open /etc/lightdm/xsession
5. Add the exported code before the last line
6. reboot
in my program i use command " netsh wlan SHOW NETWORKS MODE=BSSID" to show the available SSID and pass them into my program , the problem is the command don't refresh the available network list it's just show the cash of the last scanning and i need to re-scan Immediately when i told the program i found some thing disable then re-enable the interface through the netsh commands , and it's work for while , but i update the program now and i need to re-scan when i already connect to some network if i re-scan by this way , I'll disconnecting to this network at least 2 sec, i need another solution please
Ahmed,
if you haven't solved this problem yet, i think, i can help you.
I have the same issue and I found a solution, kind of.
It is possible to refresh, by clicking the wifi-symbol in the right-bottom corner of your computer. Here is a screenshot of this symbol.
It will take one or two seconds and then it's refreshed.
I hope I could help you and if you have found a better solution by now, it would be nice to let me know.
Greetings, Max
Microsoft WDK's Toaster sample code contains a ClassInstaller example(tostrcls.dll). It shows the ability to customize "device friendly name" displayed by Device Manager. The ability is achieved by modifying FriendlyName's value for the device's hardware key . After modifying FriendlyName, a close and reopen of the Device Manager window(devmgmt.msc) will reflect such changes. So far, so good.
However, in order to tell Device Manager window to reflect the change immediately(without close and reopen its window), some extra code has to be run. classInst.c takes the following way:
spDevInstall.FlagsEx |= DI_FLAGSEX_PROPCHANGE_PENDING;
SetupDiSetDeviceInstallParams(Params->DeviceInfoSet,
Params->DeviceInfoData,
&spDevInstall);
That works, but NOT optimal. DI_FLAGSEX_PROPCHANGE_PENDING causes the device to go through a STOP/START cycle. I mean, the driver's ToasterEvtDeviceReleaseHardware and ToasterEvtDevicePrepareHardware get executed. I think this is an undesired side-effect.
So my question is clear. Is there a way to refresh Device Manager's display without bothering with the driver code?
I got the answer from WDK7 PnpPorts project(which is the ClassInstaller that implement the Windows COM Port "Port Setting" tab).
Just change
spDevInstall.FlagsEx |= DI_FLAGSEX_PROPCHANGE_PENDING;
to
spDevInstall.Flags |= DI_PROPERTIES_CHANGE;
all done.
Note: The device-restarting behavior of DI_FLAGSEX_PROPCHANGE_PENDING is documented in WDK7 chm page "DIF_ADDPROPERTYPAGE_ADVANCED" but not in "SP_DEVINSTALL_PARAMS". I only check the latter, so missed it.
I've set up XDebug (2.2.1) and PHPStorm-IDE (Mac OS X 10.7.5) with standard LAMP stack for Mac OS (Apache 2.2.22, PHP 5.3.15).
/etc/php.ini
[xdebug]
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
xdebug.file_link_format="txmt://open?url=file://%f&line=%1"
xdebug.remote_enable = On
xdebug.remote_autostart = "PHPSTORM"
xdebug.var_display_max_data = 1024
xdebug.dump.GET=*
xdebug.dump.POST=*
xdebug.show_local_vars=On
xdebug.dump.SERVER=*
xdebug.dump_globals=On
xdebug.collect_params=4
I followed these two tutorials and it works in 99% of my project files:
http://blog.jetbrains.com/webide/2011/03/configure-php-debugging-in-phpstorm-2-0/
http://blog.jetbrains.com/webide/2011/02/zero-configuration-debugging-with-xdebug-and-phpstorm-2-0/
I use Zend Frameworks MVC architecture. I am able to stop at breakpoints in most of my controller classes, but in some other controllers PHPStorm ignores all of my breakpoints.
Do you have any suggestions? How can I debug the debugger? What kind of configuration error could cause that?
Thanks for your help.
This almost has to be the result of mismapped paths in phpstorm. You can configure paths in Settings->PHP->Servers. I ran into a similar problem and all I had to do was to set the correct absolute path on the server (where xdebug is running) in the mapping for the root of my code in phpstorm. e.g. c:\my\code\lives\here\on\my\dev\box => /myserver/my/code/lives/here/on/my/actual/server.
Here is a more complete solution, and some tips on debugging XDebug in general:
Add a remote log file to your xdebug settings: xdebug.remote_log = /path/to/logs/xdebug.log
Restart apache
Tail the log (I'm assuming you can do this in OSX)
tail -f /path/to/logs/xdebug.log
--You might see something obviously wrong by keeping track of the log contents the next time you try to debug a page. If so, just do whatever you need to do. If not, let's still assume it's a mismapping of paths and continue to try to fix that:--
Set a breakpoint where you know PHPStorm/XDebug will actually stop and make it stop there. In a lot of places on the web people report index.php being the easiest place to make PHPStorm actually stop at a breakpoint for the first time.
In a file that you can't get PHPStorm/XDebug to stop in, set and unset a breakpoint while PHPStorm is stopped at the breakpoint in the index.php file. You should see lines in your xdebug log file that look like this:
<- breakpoint_set -i 19 -t line -f
file:///myserver/my/code/lives/here/on/my/actual/server/file.php -n
159
->
See if the file actually does live where XDebug is looking for it e.g.
tail /myserver/my/code/lives/here/on/my/actual/server/file.php
If the file doesn't actually live there, adjust the path mappings in your PHPStorm settings until PHPStorm is telling XDebug to look at files that actually exist. e.g. if XDebug had said file=/mysrver/my/code/lives/here/on/my/actual/server/file.php, then in step 6 you would have noticed the file didn't exist on the server, and then you might realize "oh oops I spelled myserver wrong in the path mapping", and fixing the spelling in PHPStorm would then probably fix the issue.
This is a bit of an old thread but hopefully this will help someone eventually :)
OK, I had the same problem and dug around the PHPStorm bug tracking and also their dev forums.
It turns out that you need to make sure that the path to the file in which breakpoints don't work are exactly as they are (lower/upper case wise) on your MAC. I just migrated a project from Windows with mixed upper/lower case folders and file names on the drive and different cases in the require_once directives.
Once I made sure the path in the require_once matched the case on the disk, then my breakpoints started to work again!
See here http://devnet.jetbrains.com/message/5488439
This usually means the controllers aren't called.
If it does work for certain controllers (within the same project) it just means: the code wont get called.
So get a few steps up to see the correct controllers is called. (e.g. from the dispatch and then dive into until the controller gets loaded).
And is it possible that you work remotely (e.g. from local to another server). Than it can take a little time before it the code is placed on the server. Just wait a few seconds and than try again. Since how can it break on a point that it doesn't know?
Hope this helps to get you started to debugging it.
This happend to me too several times. Usually the debugger's configuration is the reason. You have to set the path mappings of the debug server correctly under "Run > Edit configurations".
Possible reasons for NOT stopping at breakpoints:
the IDE refuses the debug connection requests coming from the remote server. The telephone icon has to be green (Run -> Start Listening For PHP Debug Connections) in order to avoid this.
all the breakpoints are muted. Turn breakpoint muting off.
the Suspend checkbox of a particular breakpoint is not checked. Check them one-by-one in Run -> View Breakpoints. The tick means "Suspend Execution", not "Suspend the breakpoint", as one may think. (The current version of PHPStorm I use seems to be buggy, if I check the Suspend checkbox then it doesn't take effect yet. I have to click another breakpoint and then click back in order to "submit" checking the checkbox.)
If you want to debug a script invoked from a browser then the browser should set a cookie called XDEBUG_SESSION with the value of the idekey. You can initiate it by extending the URL this way: http://192.168.99.100/?XDEBUG_SESSION_START=PHPStorm. Be aware of the expiration of the cookie which is only one hour. There are useful browser add-ons for easing handling the debugger cookie. See https://xdebug.org/docs/remote#starting for more.
the individual breakpoint is not Enabled. Check them one-by-one in Run -> View Breakpoints.
the individual breakpoint has some condition that doesn't get met. Check the Condition setting of the breakpoint in Run -> View Breakpoints.
there is some mapping issue between the remote server and the IDE. When you set a breakpoint in the IDE then it sends the remote server that the execution should stop at the Nth line of the F file. There is a mapping between your local files and the files on the remote server. The mapping is defined in the IDE at the following places:
on the Path mapping field of the Preferences -> Languages & Frameworks -> PHP page
on the Preferences -> Languages & Frameworks -> PHP -> Servers page
If these mappings are incorrect, for example, the local F1.php is mapped to the remote F2.php by accident, then you may have problems. If you set a breakpoint at the line #N in your local file F1.php the server will stop the execution only if the execution reaches the line #N of file F2.php (rather than that of F1.php). If this is the problem then you still can debug your code if you turn on the Run -> Break at first line in PHP scripts flag. Be aware of the different case sensitivity in directory and file names of your development operating system versus that of the remote server!
The IDE is not receiving debug connection requests from the remote server due to some network setting issues. Check the Preferences -> Languages & Frameworks -> PHP -> Debug page whether the IDE is listening on port 9000 for XDebug, check whether it Can accept external connections, and so on.
The XDEBUG-related settings of the remote server are incorrect. I use the following settings in my php.ini
.
xdebug.default_enable = 1
xdebug.remote_enable = 1
xdebug.remote_connect_back = 0
xdebug.idekey = "PHPStorm"
xdebug.remote_autostart = 1
xdebug.remote_host=192.168.1.26
You should set remote_host to the IP address of your development computer, or you can omit the whole line if your server is on localhost.
Plus, I set the following environment variables:
export PHP_IDE_CONFIG="serverName=halmaiXdebug"
export XDEBUG_CONFIG="idekey=PHPStorm"
where the value of the serverName is the Name of the server I defined on the Preferences -> Languages & Frameworks -> PHP -> Servers page in the IDE.
UPDATE: Too old PhpStorm version also can cause breakpoint issues. With PHP 7.4 on the server and PhpStorm 2018.2 locally, the execution stopped at the first instruction but not at any further ones. After upgrading to a newer PhpStorm version (2020.1), it works as expected.
I'm using WinLIRC with IR receiver connected to serial port COM1 on Windows 7 x64. WinLIRC is added to Startup folder (Start->All applications->Startup) so it starts every time I log in. Very often (but not all the time) I see initialization error messages from WinLIRC, which continue for some time (couple of minutes) if I retry initialization, and after some retries it initializes correctly and works fine. If I remove it from Startup and start manually at any other moment it starts without errors.
I've downloaded WinLIRC sources and added MessageBox calls here and there so I can see what happens during initialization and found out that CreateFile call fails:
if((hPort=CreateFile(
settings.port,GENERIC_READ | GENERIC_WRITE,
0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0))==INVALID_HANDLE_VALUE)
{
char buffer[256];
sprintf_s(buffer, "CreateFile(%s) failed with %d", settings.port, GetLastError());
MessageBox(NULL, buffer, "debug", MB_OK);
hPort=NULL;
return false;
}
I see message box saying "CreateFile(COM1) failed with 5", and 5 is an error code for "Access denied" error according to this link.
So the question is why opening COM-port can fail with such error right after booting Windows and proceed normally few seconds or minutes later?
Update: the COM-port is the real one.
Update2: regarding the other application that opens serial port before WinLIRC. I did the following: I put Process Explorer to the Startup folder so it start on log in also, then rebooted. As soon as process explorer started I ran "Find Handle or Dll" dialog, put "Serial0" to the input and hit "Search". By that moment WinLIRC had already shown message box saying "CreateFile(COM1) failed with 5". Then I waited till the process explorer search ends, seen that it found nothing, then tried to reinitialize WinLIRC and it failed again. So I suggest that it is not the case of serial port being opened by other application. If anyone can suggest a better way to check it, I'll happily recheck.
When I search for "Serial0" in process explorer while WinLIRC is running it finds the winlirc.exe process, so it looks like it is correct term to search.
Update3: regarding the serial mouse driver. It is not listed in device manager, so I wasn't able to disable it there, however I have found this instructions on how to disable sermouse service and it didn't help.
Update4: one more thing I forgot to mention. It happens only if I log in soon after booting PC. If I leave windows on log in screen for several minutes and log in later, then WinLIRC initializes without any problems always.
Update5: Unfortunately, I don't have access to the computer that had this problem reproducing, so I can't experiment anymore.
It takes time to initialize the port.
Your application will run absolutely fine on windows XP.
Windows7's serial ports are virtual.
You can run a small code and check it out
using System.IO.Ports;
private void Form1_Load(object sender, EventArgs e)
{
string[] ports = System.IO.Ports.SerialPort.GetPortNames();
comboBox1.Items.Add("None");
foreach (string port in ports)
comboBox1.Items.Add(port);
comboBox1.SelectedIndex = 0;
}
This will return you the list of serial port. Check the status of it and display it on message box.
Make this code and run at startup. You'll get the root cause.
Here some links one has to visit before plunging into the magic world of serial programming in Windows :)
A detailed explanation of serial programming in Windows:
http://www.codeguru.com/cpp/i-n/network/serialcommunications/article.php/c5425/Serial-Communication-in-Windows.htm
a little bit outdated (the site states 1999-2003 so yes, it's outdated) but absolutely useful:
http://www.flounder.com/serial.htm