Greetings,
Anyone seeing BOOTP requests in addition to DHCP requests from iPhone
or iTouch devices?
Seeing a few iTouch/iPhone requesting BOOTP in addition to their
current DHCP lease. The device is online and working with the DHCP
lease but also requests BOOTP leases per the Cisco WLCs, i.e. the
BOOTP requests are forward by the WLC to our dhcp server.
I "suspect" these few iPhone/iTouch devices are doing broadcasts for
some installed application and the broadcasts are wrongly forwarded
by the WLCs to our dhcp server, but still trying to nail down. The
clients never uses the BOOTP lease, just keeps asking even when
supplied one.
thanks!
jim
~debug client 00:25:4b:7a:05:b on the WLC~
*Mar 16 14:48:04.532: 00:25:4b:7a:05:b6 DHCP received op BOOTREQUEST
(1) (len 308, port 2, encap 0xec03)
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP selecting relay 1 -
control block settings:
dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
dhcpGateway: 0.0.0.0, dhcpRelay: nnn.nnn.nnn.nnn VLAN: xxx
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP selected relay 1 -
nnn.nnn.nnn.nnn (local address nnn.nnn.nnn.nnn, gateway
nnn.nnn.nnn.nnn, VLAN xxx, port 1)
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP transmitting BOOTP (0)
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP op: BOOTREQUEST,
htype: Ethernet, hlen: 6, hops: 1
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP xid: 0xa12d952c
(2704119084), secs: 4, flags: 0
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP chaddr: 00:25:4b:7a:05:b6
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP ciaddr: 0.0.0.0,
yiaddr: 0.0.0.0
*Mar 16 14:48:04.533: 00:25:4b:7a:05:b6 DHCP siaddr: 0.0.0.0,
giaddr: nnn.nnn.nnn.nnn
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP sending REQUEST to
nnn.nnn.nnn.nnn (len 350, port 1, vlan xxx)
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP selecting relay 2 -
control block settings:
dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
dhcpGateway: 0.0.0.0, dhcpRelay: nnn.nnn.nnn.nnn VLAN: xxx
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP selected relay 2 -
nnn.nnn.nnn.nnn (local address nnn.nnn.nnn.nnn, gateway
nnn.nnn.nnn.nnn, VLAN xxx, port 1)
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP transmitting BOOTP (0)
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP op: BOOTREQUEST,
htype: Ethernet, hlen: 6, hops: 2
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP xid: 0xa12d952c
(2704119084), secs: 4, flags: 0
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP chaddr: 00:25:4b:7a:05:b6
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP ciaddr: 0.0.0.0,
yiaddr: 0.0.0.0
*Mar 16 14:48:04.534: 00:25:4b:7a:05:b6 DHCP siaddr: 0.0.0.0,
giaddr: nnn.nnn.nnn.nnn
*Mar 16 14:48:04.535: 00:25:4b:7a:05:b6 DHCP sending REQUEST to
nnn.nnn.nnn.nnn (len 350, port 1, vlan xxx)
~sniffer trace of what I believe is kicking the WLC to relay _/00 25
4b 7a 05 b6 /_
DLC: ----- DLC Header -----
DLC:
DLC: Frame 391 arrived at 14:48:07.9902; frame size is 418
(01A2 hex) bytes.
DLC: Destination = Station 000F35DE8400
DLC: Source = Station 001BD4C17504
DLC: Ethertype = 0800 (IP)
DLC:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: DiffServ Field = 00
IP: 0000 00.. = DSCP - 0 , Best Effort
IP: .... ..00 = ECT - Transport protocol will not
participate in ECN
IP: Total length = 404 bytes
IP: Identification = 13639
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = C80F (correct)
IP: Source address = [nn.nn.nn.nn]
IP: Destination address = [yy.yy.yy.yy]
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 18260
UDP: Destination port = 5247
UDP: Length = 384
UDP: No checksum
UDP: [376 byte(s) of data]
UDP:
ADDR HEX ASCII
0000: 00 0f 35 de 84 00 00 1b d4 c1 75 04 08 00 45 00 | ..5Ã....ÃÃu...E.
0010: 01 94 35 47 40 00 ff 11 c8 0f ac 1f 9c 84 ac 1f |
....@...Ã.¬...¬.
0020: 88 3e 47 54 14 7f 01 80 00 00 00 20 03 20 00 00 |
<88>>GT....... . ..
0030: 00 00 01 04 c0 20 00 00 00 00 01 08 2c 00 00 1c | ....Ã ......,...
0040: 0e 26 1e 90 _/00 25 4b 7a 05 b6/_ ff ff ff ff ff ff |
.&...%Kz.¶......
0050: 01 00 aa aa 03 00 00 00 08 00 45 00 01 48 ef 36 |
..ªª......E..Hï6
0060: 00 00 ff 11 cb 6e 00 00 00 00 ff ff ff ff 00 44 | ....Ãn.........D
0070: 00 43 01 34 b8 5f 01 01 06 00 a1 2d 95 2c 00 09 | .C.4¸_.....-.,.
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0090: 00 00 _/00 25 4b 7a 05 b6/_ 00 00 00 00 00 00 00 00 |
...%Kz.¶........
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0160: 00 00 63 82 53 63 ff 00 00 00 00 00 00 00 00 00 | ..c.Sc..........
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
01a0: 00 00 | ..
On 3/10/2010 12:13 PM, Lee H Badman wrote:
We are not a Meru shop, but have similar driver-related issues on
secure networks. It is my conjecture that this is a way of life on
secure networks where you have a wide range of client device types
and driver vintages.
Frustratingly, MacBooks and iPhones tend to be among the most
frustrating and inconsistent clients to deal with.
-Lee
Lee H. Badman
Wireless/Network Engineer
Information Technology and Services
Adjunct Instructor, iSchool
Syracuse University
315 443-3003
------------------------------------------------------------------------
*From:* The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]] *On Behalf Of
*Clipperton, Ken
*Sent:* Wednesday, March 10, 2010 9:45 AM
*To:* [email protected]
*Subject:* Re: [WIRELESS-LAN] Experiences with Meru
Richard,
We have a campus-wide Meru 802.11n wireless network in place with
802.1x as part of the picture. Our experience matches yours. I have
believed it was our combination of WPA2-Enterprise and 802.1x that
accounted for the inability of older drivers to work with our
implementation. We do run a "guest" network that is not encrypted
and I believe that we have not seen the same issue for those clients.
We urge people to use the Windows Update site using the "Custom"
option and installing any wireless drivers that pop up. We keep the
current Intel drivers on a USB memory stick that hangs next to the
help desk service window. We have used it many times. Happily that
install is extremely simple -- just click on one executable, wait a
short time while the updated driver installs and becomes active.
We have found that Windows default network settings don't match our
needs. Some students follow a short step-by-step guide. Most bring
them into the help desk. If we weren't under 1,000 students I would
definitely look into the automated client configuration tools that
have recently been mentioned here. I wonder if those tools also
handle driver updates.
Ken
On Wed, Mar 10, 2010 at 6:24 AM, R. Smit <[email protected]
<mailto:[email protected]>> wrote:
Hello,
I have a question for other Universities who are using Meru wireless
802.11n networks. We are in the process of doing a Proof of Concept
on Meru’s technology of single cell architecture. We ran into a few
issues and I was wondering how other universities are dealing with
these kind of issues or maybe they didn’t experience any issues at all.
We noticed that clients with older drivers were unable to connect to
the Meru network but after updating the drivers it worked fine. For
example Intel 3945ABG chipset needed the 12.x driver to connect. So
the default driver in Microsoft Vista is out dated. We have about
40,000 students and they all have their own laptop. Does anyone had
to deal with this kind of problems? And how did you manage it in a
large environment?
Does anyone experience that Meru is very demanding on client
configuration and driver and hardware versions?
Thanks.
Regards,
Richard Smit
Hogeschool van Amsterdam
University of Professional Education
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
