From: bod43 on 7 Aug 2010 15:51 On 7 Aug, 19:25, JF Mezei <jfmezei.spam...(a)vaxination.ca> wrote: > I have a laptop on the wifi. It can connect to internet no problem. It > can connect to almost every host on the wired LAN without problem. > > There is an IPMI destination on the wired LAN which is sometimes > accessible, sometimes not. (sometimes I can just start the GUI for > server monitoring, and within a few minutes it will be able to connect, > after which there is no problem - this never happens on the wired LAN > portion). During failed attempts, the wi-fi device does get an ARP > resolution for the IPMI destination. > > Now howver, I try to ping or SSH to another wi-fi device (a phone) and > it fails royally. I can telnet to a wired server from the laptop, and > that server has no problem pinging or SSH to the phone. > > So wi-fi to LAN seems to work. > LAN to Wi-Fi seems to work. > But Wi-fi to wi-fi seems to be a problem. > > Is this common ? What should I look at in the config ? > > While I am at it, for such a router, what would be the best way to run > wireshark to scan all of the wi-fi traffic ? Can I do a port monitor on > the BVI10 interface ? To test wifi connections (or others too:) I like to send a lot of pings. fping.exe is nice for this if you have windows. http://www.kwakkelflap.com/fping.html fping 10.8.37.129 -s 1300 -t 0 -n 1000 add -i if you have any weird problems/error messages You can use >1 instance if required. If there is anything dodgy about the link you will see it right away. Be aware that this application can send a lot of traffic and could affect network/system performance. To use wireshark on wifi you need linux, or windows with the wireless pcap shim. The latter is commercial software and is not free (airpcap?). Alternatively you can use the free Windows Network Monitor from Microsoft. You may be able to save the files in wireshark format or wireshark may be able to read it's files. I may be a bit out of date on this, it is possible that someone has written a free shim now. To capture traffic other than your own you will need a wireless card *and* driver that can be put in monitor mode. Unless there is a bug in the router I would have thought that wifi<->wifi traffic should be no different to wifi<->lan. Of course there are two wireless hops in the former case and BOTH would need to be working correctly. The later IOS software can I seem to recall do packet capture to flash/network (12.4.twentysomething). On an 87x router however I would think that the performance would soon become CPU limited. You would not I would think see ethernet<->ethernet traffic either unless routing between vlans or maybe bridging between vlans. It would work on BVI10 I guess. Check memory requirements before upgrading. Stated flash requirements now include the Web GUI thingy which of course is not essential. If the image fits the flash then you have enough flash:) For testing/ development purposes you could always boot over the network if you did not have enough flash. Not so wise for production:))
From: Aaron Leonard on 7 Aug 2010 17:48 On Sat, 7 Aug 2010 12:51:20 -0700 (PDT), bod43 <Bod43(a)hotmail.co.uk> wrote: >On 7 Aug, 19:25, JF Mezei <jfmezei.spam...(a)vaxination.ca> wrote: >> So wi-fi to LAN seems to work. >> LAN to Wi-Fi seems to work. >> But Wi-fi to wi-fi seems to be a problem. >> >> Is this common ? What should I look at in the config ? I admit that I didn't follow the topology here. I got lost at IPMI. OK, I've now googled IPMI, and I still don't get where it fits in. Guess I'd need to see a picture. >> While I am at it, for such a router, what would be the best way to run >> wireshark to scan all of the wi-fi traffic ? Can I do a port monitor on >> the BVI10 interface ? Traffic on a BVI is strictly traffic to/from the router itself (i.e. where the router is the IP endpoint.) Transit traffic in the BVI's bridge group is just bridged by the router and does not touch the BVI. You can see packets transmitted / received on the radio interface thus: (send the radio driver debugs to the IOS logger, rather than writing them directly the console) no debug dot11 d0 print printf debug dot11 d0 trace print mgmt rcv xmt standard IOS logging best practice pertains: - worst practice is to log to the console at 9600 bps (i.e. the default) - less bad practice is to log to the console at 115200 bps - good practice is "no logging console" and use "terminal monitor" in a telnet/ssh session - best practice is to log to a logging buffer Is there a shim to take the output of these debugs and feed them into Wireshark, e.g. via text2pcap? Nope, haven't done it yet. >To test wifi connections (or others too:) I like to send a lot >of pings. fping.exe is nice for this if you have windows. >http://www.kwakkelflap.com/fping.html > >fping 10.8.37.129 -s 1300 -t 0 -n 1000 > >add -i if you have any weird problems/error messages > >You can use >1 instance if required. > >If there is anything dodgy about the link you will see it >right away. > >Be aware that this application can send a lot of traffic and >could affect network/system performance. > >To use wireshark on wifi you need linux, or windows with >the wireless pcap shim. The latter is commercial software >and is not free (airpcap?). Alternatively you can use the free >Windows Network Monitor from Microsoft. You may be able >to save the files in wireshark format or wireshark may be >able to read it's files. I may be a bit out of date on this, it is >possible that someone has written a free shim now. Yep, Netmon 3.4 now actually works (in Windows 7, not in XP) to capture wireless traffic. The data is saved in a Netmon 2 format that the production releases of Wireshark can't grok. However the latest 1.5 dev builds can read Netmon output. Aaron
From: bod43 on 7 Aug 2010 22:04 On 7 Aug, 22:48, Aaron Leonard <Aa...(a)Cisco.COM> wrote: > On Sat, 7 Aug 2010 12:51:20 -0700 (PDT), bod43 <Bo...(a)hotmail.co.uk> > wrote: > > >On 7 Aug, 19:25, JF Mezei <jfmezei.spam...(a)vaxination.ca> wrote: > >> So wi-fi to LAN seems to work. > >> LAN to Wi-Fi seems to work. > >> But Wi-fi to wi-fi seems to be a problem. > > >> Is this common ? What should I look at in the config ? > > I admit that I didn't follow the topology here. > I got lost at IPMI. > > OK, I've now googled IPMI, and I still don't get > where it fits in. Guess I'd need to see a picture. Nor me, but I decided that it was not likely relevant to the problem and I ignored my ignorance completely. Maybe I'll google it tomorrow, or sometime.
From: bod43 on 7 Aug 2010 22:35 On 7 Aug, 22:48, Aaron Leonard <Aa...(a)Cisco.COM> wrote: > On Sat, 7 Aug 2010 12:51:20 -0700 (PDT), bod43 <Bo...(a)hotmail.co.uk> > wrote: > > >On 7 Aug, 19:25, JF Mezei <jfmezei.spam...(a)vaxination.ca> wrote: > >> So wi-fi to LAN seems to work. > >> LAN to Wi-Fi seems to work. > >> But Wi-fi to wi-fi seems to be a problem. > >> wireshark to scan all of the wi-fi traffic ? Can I do a port > monitor on > >> the BVI10 interface ? > > Traffic on a BVI is strictly traffic to/from the router itself > (i.e. where the router is the IP endpoint.) Transit traffic > in the BVI's bridge group is just bridged by the router and does > not touch the BVI. Ah yes. I was not clear enough on that, thanks. I am not at all sure however that you are exactly correct either:-) Surely a packet capture on a BVI will capture *both* traffic to and from the router and traffic *routed* by the router via the BVI? Or perhaps even more exactly, traffic addressed to the BVI's MAC address *or* addressed to the MAC broadcast address *or* traffic transmitted by the BVI? The received traffic may not be routed since no route may exist or perhaps ACLs may subsequently block the traffic. It would not I would think capture traffic bridged within the bridge group. I am frankly guessing here, but guessing based on my understanding of network architectures. Other behaviour would not make sense to me. Thanks very much for your valued contributions. Finally. BVIs of course can be used soley for managemnt traffic however I have used them frequently for routing traffic on 87x routers. This message will in fact be sent via such an interface on an 87xW. interface Dot11Radio0.1 encapsulation dot1Q 23 no cdp enable bridge-group 23 bridge-group 23 subscriber-loop-control bridge-group 23 spanning-disabled bridge-group 23 block-unknown-source no bridge-group 23 source-learning no bridge-group 23 unicast-flooding BVI23 10.x.x.x YES NVRAM up up
From: JF Mezei on 7 Aug 2010 22:43 bod43 wrote: >> OK, I've now googled IPMI, and I still don't get >> where it fits in. Guess I'd need to see a picture. > > Nor me, but I decided that it was not likely relevant to the > problem and I ignored my ignorance completely. Maybe > I'll google it tomorrow, or sometime. IPMI is a subsystem in a server that has its own IP address and allows you to monitor the hardware of the server (temperartures, fan speeds etc), turn off or on the server itself etc. (in other words, this small piece of hardware remains active even when server is powered off). Often, it uses the same physical ethernet port as the one used by the server for its own connectivity (IP etc). In other words, for Arp, there might be 2 IP addresses pointing to the same ethernet address. My LAN machines never have problems connecting to the IPMI interface of the server. But wi-fi connected laptop often does (but not all the time). This is why I thought it might be significant in trying to debug the inability of a laptop to connect to another wi-fi device.
|
Next
|
Last
Pages: 1 2 Prev: Pix as Firewall Endpoint Next: Port forwarding on Cisco 1800 series - Help |