From: bod43 on
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
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
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
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
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.