WiFi Profiling a IPhone 12 Pro Max (Australia)

 Iphone 12 Pro Max  (Australia)

802.11  k,r,v,w  Supported

802.11n  Supported (2ss)

802.11ac Supported (2ss), SU BF supported, MU BF not supported

802.11ax Supported (Draft)

Max Power 12dbm

Min Power -7dbm

Supported 5Ghz Channels

36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 149, 153, 157, 161, 165

UPDATE  the supported channels is not correct due to a bug in the WLANPI profiler not taking into account of the regulatory Domain.

Supported 5Ghz Channels

36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 132,128, 140, 144, 149, 153, 157, 161, 165

Trying to work out if there is a way for the profiler to determine the country code.

The profiler could use the country code from  /etc/hostapd.conf on WLAN PI   ?  the user would need to set correctly 

here is pcap  https://www.dropbox.com/s/zjtf02k3atlej2y/4a-d3-49-71-07-c6_5.8GHz.pcap?dl=0

I saw this 

https://patents.google.com/patent/US20080259882A1/en

Could 802.11d help here....

IEEE 802.11d-2001 is an amendment to the IEEE 802.11 specification that adds support for "additional regulatory domains". This support includes the addition of a country information element to beacons, probe requests, and probe responses

Not seeing this in the pcap

And was asked by Josh Schmelzle try and get the Phone to connect to channel 124

I tried to set the WLAN PI to channel 124  in hotspot mode using the comfast adaptor  regardless of country code this was not possible   (and should not be possible is Australia !) 

 See below for DIAG from 

sudo hostapd -d /etc/hostapd.conf

CHANGE TO AU

BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)

wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE

Previous country code CA, new country code AU

Continue interface setup after channel list update

ctrl_iface not configured!

random: Got 20/20 bytes from /dev/random

nl80211: Drv Event 36 (NL80211_CMD_REG_CHANGE) received for wlan0

nl80211: Regulatory domain change

 * initiator=1

 * type=0

 * alpha2=AU

wlan0: Event CHANNEL_LIST_CHANGED (27) received

Channel list updated - continue setup

nl80211: Regulatory information - country=AU (DFS-ETSI)

nl80211: 2402-2482 @ 40 MHz 20 mBm

nl80211: 5170-5250 @ 80 MHz 17 mBm

nl80211: 5250-5330 @ 80 MHz 24 mBm (DFS)

nl80211: 5490-5710 @ 160 MHz 24 mBm (DFS)

nl80211: 5735-5835 @ 80 MHz 30 mBm

nl80211: Added 802.11b mode based on 802.11g information

nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 24                             62 2467 2472 2484

nl80211: Mode IEEE 802.11a: 5180 5200 5220 5240 5260[RADAR] 5280[RADAR] 5300[RAD                             AR] 5320[RADAR] 5500[RADAR] 5520[RADAR] 5540[RADAR] 5560[RADAR] 5580[RADAR] 5600                             [RADAR] 5620[RADAR] 5640[RADAR] 5660[RADAR] 5680[RADAR]

nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 24                             62 2467 2472 2484

Channel 124 (primary) not allowed for AP mode, flags: 0x7807979 RADAR

wlan0: IEEE 802.11 Configured channel (124) not found from the channel list of c                             urrent mode (2) IEEE 802.11a

wlan0: IEEE 802.11 Hardware does not support configured channel

Could not select hw_mode and channel. (-3)

wlan0: interface state COUNTRY_UPDATE->DISABLED

wlan0: AP-DISABLED

CHANGE TO CA

wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE

Previous country code AU, new country code CA

Continue interface setup after channel list update

ctrl_iface not configured!

random: Got 20/20 bytes from /dev/random

nl80211: Drv Event 36 (NL80211_CMD_REG_CHANGE) received for wlan0

nl80211: Regulatory domain change

 * initiator=1

 * type=0

 * alpha2=CA

wlan0: Event CHANNEL_LIST_CHANGED (27) received

Channel list updated - continue setup

nl80211: Regulatory information - country=CA (DFS-FCC)

nl80211: 2402-2472 @ 40 MHz 30 mBm

nl80211: 5170-5250 @ 80 MHz 17 mBm

nl80211: 5250-5330 @ 80 MHz 24 mBm (DFS)

nl80211: 5490-5600 @ 80 MHz 24 mBm (DFS)

nl80211: 5650-5730 @ 80 MHz 24 mBm (DFS)

nl80211: 5735-5835 @ 80 MHz 30 mBm

nl80211: Added 802.11b mode based on 802.11g information

nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484

nl80211: Mode IEEE 802.11a: 5180 5200 5220 5240 5260[RADAR] 5280[RADAR] 5300[RADAR] 5320[RADAR] 5500[RADAR] 5520[RADAR] 5540[RADAR] 5560[RADAR] 5580[RADAR] 5600[RADAR] 5620[RADAR] 5640[RADAR] 5660[RADAR] 5680[RADAR]

nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484

Channel 124 (primary) not allowed for AP mode, flags: 0x109 RADAR

wlan0: IEEE 802.11 Configured channel (124) not found from the channel list of current mode (2) IEEE 802.11a

wlan0: IEEE 802.11 Hardware does not support configured channel

Could not select hw_mode and channel. (-3)

wlan0: interface state COUNTRY_UPDATE->DISABLED

wlan0: AP-DISABLED

CHANGE TO US

BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)

wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE

Previous country code CA, new country code US

Continue interface setup after channel list update

ctrl_iface not configured!

random: Got 20/20 bytes from /dev/random

nl80211: Drv Event 36 (NL80211_CMD_REG_CHANGE) received for wlan0

nl80211: Regulatory domain change

 * initiator=1

 * type=0

 * alpha2=US

wlan0: Event CHANNEL_LIST_CHANGED (27) received

Channel list updated - continue setup

nl80211: Regulatory information - country=US (DFS-FCC)

nl80211: 2402-2472 @ 40 MHz 30 mBm

nl80211: 5170-5250 @ 80 MHz 23 mBm

nl80211: 5250-5330 @ 80 MHz 23 mBm (DFS)

nl80211: 5490-5730 @ 160 MHz 23 mBm (DFS)

nl80211: 5735-5835 @ 80 MHz 30 mBm

nl80211: 57240-63720 @ 2160 MHz 40 mBm

nl80211: Added 802.11b mode based on 802.11g information

nl80211: Mode IEEE 802.11g: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484

nl80211: Mode IEEE 802.11a: 5180 5200 5220 5240 5260[RADAR] 5280[RADAR] 5300[RADAR] 5320[RADAR] 5500[RADAR] 5520[RADAR] 5540[RADAR] 5560[RADAR] 5580[RADAR] 5600[RADAR] 5620[RADAR] 5640[RADAR] 5660[RADAR] 5680[RADAR]

nl80211: Mode IEEE 802.11b: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484

Channel 124 (primary) not allowed for AP mode, flags: 0x7c07979 RADAR

wlan0: IEEE 802.11 Configured channel (124) not found from the channel list of current mode (2) IEEE 802.11a

wlan0: IEEE 802.11 Hardware does not support configured channel

Could not select hw_mode and channel. (-3)

wlan0: interface state COUNTRY_UPDATE->DISABLED

wlan0: AP-DISABLED

Fixing Windows 10 Boot after Ghosting 2 disks

 I love Ghost but it is getting old now and does not set the MBR when finished for windows 10

Once Ghosted you need to fix the boot records on the new SSD

Windows 10 USB Boot  --> Adv --> Command prompt

DISKPART

LIST DISK

SEL DISK 0

LIST VOL

SELECT VOL3 (the EFT one  99mb fat32) 

ASSIGN LETTER=H:

SEL VOL 1  (the windows disk)

ASSIGN LETTER=F:

BOOTREC /fixmbr

BCDEDIT /SET {bootmgr} device partition=h:
BCDEDIT /SET {default} device partition=f:
BCDEDIT /SET {default} osdevice partition=f:

And reboot !

RDNSS with IPV6

I was trying to get my Meraki AP on IPv6.  It seems the AP does not support DHCPv6  (and will not any time soon I have been told on forum)  Android devices also do not support DHCPv6  and rely on RDNDSS.

Windows 10 will only use RDNSS if there is no DHCPv6 or DHCPv4 server. To get RDNSS to work on windows 10 need to disable DHCP IPv4 and DHCP IPv6.  So for the best compatibility in a dual stacked environment you need to have DHCPv4 and DHCPv6 add RDNSS for segments with android and Meraki devices.

I thought DNS option were only supported on DHCPv6  but they supported on RDNSS  rfc8106

This allows RA DNS options to distribute DNS server information as part of RA advertisements.

On Cisco

interface Vlan1

 ip address x.x.x.x 255.255.255.0

 ipv6 address 1::1:0:0:0:1/64

 ipv6 enable

 ipv6 nd other-config-flag

 ipv6 nd ra dns server 2001:8000:101::1

 ipv6 nd ra dns server 2001:8000:101::2

Can you do virtual wireless training ?

Covid-19 has forced us to try a lot of things out of necessity, that we may never have thought possible or counter intuitive.  Some companies I look after are now asking me how they can remove their office all together as working from home is working so well for them and they want to save the $150,000 p/a office rent. They would never have thought they could all work from home before Covid-19 lock down.  We are lucky in Australia that technology (Zoom, Office 365, Cloud products) and broadband upgrades are making working from home technically possible.

One of the problems of being in the technology field is keeping up with the latest advances and keeping fully trained and knowledgeable. I have always found learning by certification the best way of learning and differentiating yourself in a crowded market. I started my certification journey in 1995 with Microsoft and then Cisco in 1999 after finding wireless to be right up my alley.  Doing my first 802.11b wireless survey for a wool shed, with survey mode (which only showed signal strength!) on Cisco 802.11b PCMCIA adapter.

One of my biggest issues was getting Cisco courses to run in Australia and in Melbourne.  Generally these high-end courses run only when they have at least 8 people and will run where there are the most people (generally Sydney). The additional cost of traveling to Sydney adds up an extra $2000 to the cost of the training making it out of reach for many. I have lost count of the amount of times Cisco courses were cancelled due do to lack of paying customers. In one instance I paid for 2 extra attendees so the course would run in Melbourne after being cancelled 4 times over a 2 year period.

When Ekahau ECSE Training was offered in Melbourne via Dicker Data, I was not going to miss this opportunity especially with Keith Parsons teaching the course. I love face to face training as it gives you time to be 100% dedicated to learning and learning from other student experiences.  Even with face to face Keith's plane was delayed and Darko of Dicker Data had to try and fill Keith's big shoes on the first day (he did a great job).  What a great course this was always learning something new and learning from Keith's vast experience. Highly recommend this course.

With ECSE under my belt ECSE Advanced (the one I sat was under license from Wifi Academy https://wifiacademy.net/awst) was the next on the bucket list.  Dicker Data ran this again in Melbourne and with  Francois Verges, his knowledge and enthusiasm to wireless again made this a fantastic course which I highly recommend to anyone who has completed the ECSE Design course.

The third course in the Ekahau training series (which I have now realised is not a series) is the ECSE Troubleshooting course.  I asked Dicker Data if they ever ran this course in Australia to count me in.    There seemed to be enough interest so Dicker Data scheduled the course. Then Covid-19 struck.  I was disappointed as I knew after all the travel restrictions and Melbourne going into lock down that it would be cancelled. Sure enough it was! This was not going to stop Darko and the Dicker team thinking can we do it virtually??  The email came out to all attendees "Would you attend this course in a virtual format?"  This required a lot of thought, these courses are expensive and would you get the same information and experience?  I had my doubts. How would you do wireless virtually, how would you do the wireless labs? Wireless signals don't travel that far! I had my reservations. I knew this course would not run face to face for some years in the current situation so I decided to attend (and I am glad I did!)

ECSE Troubleshooting

The Team at  Ekahau, Wireless LAN Professionals, Dicker Data and most of all Ferney Munoz, went out of their way to not only just teach the face to face curriculum but to use all the advantages of virtual training to make this course in my opinion better than on site training. Dicker Data who have always been attentive and professional training hosts, got all the LAB equipment couriered to our home address with quick testing instructions so all would be ready on day 1 of the training. No sharing of equipment like you do in classroom training and no working in groups. This enabled us to be able to individually fully complete and understand the labs which was a very useful advantage.

Day one started perfectly on time (no one arriving late trying to find the place or stuck in traffic) and students were immediately impressed with the Presenter, Zoom and wireless setup. At this point we knew the course was going to be good. Ferney had gone to great trouble to set up his garage with everything wireless and everything was in reach so his explanations were using real equipment you could see which greatly enhanced his teaching and explanations. He has the lighting just right, auto focus camera and wireless microphone so you could always hear him, even when he was surveying the property outside!

View from the participant point of view

Ferney hit the ground running starting with content from 9.00 am  as we had already introduced ourselves via a Google sign in document in the previous week. You did feel like you were really there.  Zoom makes it feel like you are in the classroom and you can see all the students as well.

I have a 3 screen setup so I had the Teacher on one screen, his shared presentation on another and all my class mates on the third. Breaks were short and lunch was 35 minutes each day with Dicker Data supplying Uber eats vouchers for lunch. I did however,miss the networking aspect where you can interact face to face during a class lunch, but this was a small price to pay for the efficiency of the class and keeping it running like clockwork and not missing any content. In fact this format meant than Ferney could go off script regularly and add more content depending on class interest and questions imparting some of his vast real world experience.

Class from teacher (Ferney Munoz) point of view (There is me 4th from left on top row!)

This class is so full of content and time so precious that the classroom environment would not have let us learn from Ferney's vast experience. Ferney was clear and attentive not having just got off a plane and suffering from jet lag and hotel food! Ferney did cover all the curriculum but on day 3 due to going off script a little due to class interest and questions, the virtual format allowed us to do some of the LABS as homework.  Having all the equipment at home and not having to waste 1-2 hours travelling to and from the training center meant we could spend that time doing the labs at night at our own pace.  Dicker also gave us the option of returning the LAB equipment a week after the course finished also giving us time to fully get the most out of the hands on experience.

This course is a great stand alone course! You do get more out of it if you have done ECSE Design but this course gets you to understand WiFi and how it works and how can you fix something if you don't know how it works in the first place? Ferney does LIVE demonstrations that truly help you visualize how WiFi works. He even does a live wireless survey around his property while you watch and listen to the do's and don'ts. This course shows you can troubleshoot most WiFi issues with free or cheap tools too.  I highly recommend this course to anyone who looks after WiFi at their work or whose job it is to fix WiFi issues. You will need to understand the OSI model, basic network protocols and CWNA would be an advantage to get the most out of the instructors verbal knowledge.

I was skeptical about doing a virtual Ekahau course but now I think I got more out of the virtual class than I would have from the physical class. I think Zoom technology and the effort that Ekahau, Dicker Data, WLAN Professionals and Ferney made this format work and therefore was a great success.  Going forward I think this will be great for the industry as courses that I could never do in Australia could now be made available in Australia virtually. 

https://www.ekahau.com/training/

A course that would probably never come to Australia is Devin Akin Wireless Adjusters Course however, due to Covid-19 has started running this course online. This was a bit harder to do virtually as it would run in Devin's Local Time zone, which was 11.00pm - 6.00am Melbourne time so this was going to be a bigger commitment. Despite this I am glad I did this course. Devin is a WiFi veteran and the wireless wisdom that he explains during his class kept me awake all night and early morning! He will make you fall in love with WiFi Explorer Pro as a diagnostic tool and reconsider the move to MAC! Again I highly recommend his course as well and would be a great follow up from ECSE Design and ECSE Troubleshooting as you need to have a good understanding of WiFi before you then start tuning it for Best Practices. Devin takes you through 57 WiFi parameters that have Best Practices to make WiFi work at it's most optimal.

Again a virtual course I would highly recommend.

http://divdyn.com/wireless-adjuster-course-level-ii/

Looking forward to my next virtual class!

 Cisco Catalyst 9100 Series

 

 

Comparison of Sizes

New Bracket

Wall Mount AP with PASS THROUGH

Catalyst Power Requirements

IOS 14, iPadOS 14, macOS Big Sur, WatchOS 7 Supported devices.

iOS 14

• iPhone 11
• iPhone 11 Pro
• iPhone 11 Pro Max
• iPhone XS
• iPhone XS Max
• iPhone XR
• iPhone X
• iPhone 8
• iPhone 8 Plus
• iPhone 7
• iPhone 7 Plus
• iPhone 6s
• iPhone 6s Plus
• iPhone SE (1st generation)
• iPhone SE (2nd generation)
• iPod touch (7th generation)

iPadOS 14

• iPad Pro 12.9-inch (4th generation)
• iPad Pro 11-inch (2nd generation)
• iPad Pro 12.9-inch (3rd generation)
• iPad Pro 11-inch (1st generation)
• iPad Pro 12.9-inch (2nd generation)
• iPad Pro 12.9-inch (1st generation)
• iPad Pro 10.5-inch
• iPad Pro 9.7-inch
• iPad (8th generation)
• iPad (7th generation)
• iPad (6th generation)
• iPad (5th generation)
• iPad mini (5th generation)
• iPad mini 4
• iPad Air (4rd generation)
• iPad Air (3rd generation)
• iPad Air 2

macOS Big Sur

Here's the line-up of Macs that will get Big Sur:

• MacBook (2015 and later)
• MacBook Air (2013 and later)
• MacBook Pro (late 2013 and later
• Mac mini (2014 and later)
• iMac (2014 and later)
• iMac Pro (2017 and later -- all models)
• Mac Pro (2013 and later)

watchOS 7

• Apple Watch Series 3
• Apple Watch Series 4
• Apple Watch Series 5
• Apple Watch Series 6

Xerox Scanner has no password field

If you are trying to setup SMB scanning and there is NO password field.

you need to connect with HTTPS  not HTTP

this will require setting up a self signed CERT and then enabling HTTPS.

DHCP Relay issue Meraki MX64

** Update this issue has been fixed in MX 15.34 **

In 10 Feb 2020  an interesting problem to solve which has taught me in great detail how DHCP relay works.

I am writing this to help others understand and explain the bug in the DHCP relay MX64 implementation.

Client had a IoT device that would work fine for 1 day and the next day it would loose network connectivity completely (would not ping) , the only way to fix the issue was to restart the client IoT device, all other clients were fine on the same network.

After some head scratching and some observations over a couple of days, I realized the client was stopping exactly 24 hours after it was rebooted.  I checked the DHCP lease time and it was set to 24 hours.  I changed to 48 hours and sure enough the client stopped working 48 hours later, so I was on to something.  All other clients were fine so what was special about this client?

Out came the wire-shark toolkit, using Meraki gear is great as you can take pcap trace at any point in the network and load into wire-shark.

This network did not have a local DHCP server  it was using a DHCP relay (Cisco DHCP helper address)  to a Meraki MX64 on another subnet running a DHCP server service.

Now this device did have a DHCP reservation.   Maybe this was the issue ??

Below is a diagram of the network  (with identifying bits removed)

  

The IoT device does a broadcast for a DHCP address and the layer 3 switch then sends this packet as a uni-cast to x.y .4.1 the dhcp server.

After looking at the .pcap  the initial DHCP request and reply worked initially, but when it came to renewal time the device would ask to renew and nothing would come back and then eventually the client would stop and unbind the existing ip address.

I needed to get a trace at the DHCP server.  When I did this the server was replying at renewal but with a NAK  and with the address of 255.255.255.255  the device would never see the NAK, as the address was a broadcast on the x.y.4.0/24 subnet  and the device was on the x.y.1.0/24 subnet.  To me it seemed common sense that this needed to be a uni-cast not a broadcast to get through the routers. 

I opened a case with Meraki (04855962) to ask them why.  This was very frustrating as after an hour working with the engineer and getting all the captures, they went off shift and I had to start again with another engineer. (the difference between working with Meraki compared to Cisco TAC)

After Meraki reviewed, I was told the issue was NOT caused by the meraki MX64 it was operating correctly.

I was told

-----------------------

I've reviewed your issue and the issue is NOT caused by the MX as per Section 3.2 in 'IETF RFC2131 | Dynamic Host Configuration Protocol' below:

RFC  link: https://tools.ietf.org/html/rfc2131#page-17
3.2 Client-server interaction - reusing a previously allocated network
    address
    If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
          the same subnet as the server.  The server MUST
          broadcast the DHCPNAK message to the 0xffffffff broadcast address
          because the client may not have a correct network address or subnet
          mask, and the client may not be answering ARP requests.
          Otherwise, the server MUST send the DHCPNAK message to the IP
          address of the BOOTP relay agent, as recorded in 'giaddr'.  The
          relay agent will, in turn, forward the message directly to the
          client's hardware address, so that the DHCPNAK can be delivered even
          if the client has moved to a new network.

      Please refer to page 9 of the RFC for more information about the DHCP fields description.
      e.g. giaddr: Relay agent IP address, used in booting via a relay agent.

The RFC2131 said that if the 'giaddr' (Relay agent IP address) in the client's DHCPREQUEST is 0.0.0.0, the MX will consider this DHCPREQUEST is within same broadcast domain of your MX's subnet: x.y.4.0/24. Because the client's requested 'dhcp.ip.client == x.y.1.71' (as per frame.number == 120 in your provided packet capture) is NOT within the same broadcast domain of the MX, the MX's DHCP server will send a DHCPNAK to a broadcast address.

If you are filtering the pcap with the filter: 'dhcp.ip.relay == x.y.1.0/24', you will see there are 2 DHCP relay agent IP addresses: x.y.1.1 and x.y.1.4 which were in the client's DHCP requests and they were the working DHCP renewal requests as per below screenshot. Please note that the source IP of the DHCPREQUEST will be always a DHCP relay agent IP if it is included in the DHCPREQUEST (as per RFC2131).

---------------------------------------------

Well this looked very technical and quoting the RFC,  but it did not make any sense.   I could NOT believe that people smarter than me that write the RFC made this glaring mistake.  It was time to download the RFC and look for myself.  7 hours later and some experiments I had made some progress !

You needed to read further in the RFC Meraki Quoted.

My issue was with the renewing process and  NOT for the  Initial DHCP Discover ??

From Page 31 of the same document meraki quoted

https://tools.ietf.org/html/rfc2131#page-31

DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'

      option MUST NOT be filled in, 'ciaddr' MUST be filled in with

      client's IP address. In this situation, the client is completely

      configured, and is trying to extend its lease. This message will

      be unicast, so no relay agents will be involved in its

      transmission.  Because 'giaddr' is therefore not filled in, the

      DHCP server will trust the value in 'ciaddr', and use it when

      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The

      server may choose not to extend the lease (as a policy decision by

      the network administrator), but should return a DHCPACK message

      regardless.

The renew conversation is between end device and the DHCP server (the relay agent is NOT involved)  Why would it need to put the relay agent IP address in ?

The issue in this network is the broadcast will not even be seen by the  DHCP relay agent as there is a router in between.

I thought this might be a BUG just with the IoT device   so I decided to  do the same experiment with a WINDOWS 10 PC Latest Build

NO reservation in Meraki DHCP

On PC did a ipconfig /release then  ipconfig /renew (for initial request)  and then a ipconfig /renew  (for the renewal request)

Dell.pcap showed

You can not tell me that Windows 10 has the same bug ??  But users were not complaining with the same issue yet they were still affected by it.

I did not think what meraki was referring to from RFC is for the RENEWAL .  The RENEWAL should be a Uni CAST

Also why is the DHCP server sending a NAK  and Not and ACK ?   (some logic is wrong here)

I did not believe I had found a bug in the RFC

 

From the Meraki.pcap  file in their example  x.y.1.1  and x.y.1.4    (by the way x.y.1.4 is a cisco WLAN controller, this also acks like a dhcp helper for the wireless clients)

The Meraki Tech working example are NOT renewals  these are initial DHCP requests

I did some testing using the wireless DHCP x.y.1.4 helper with the same laptop

Now it works perfectly as the WLAN controller  PROXIES ALL DHCP  and will not let the client talk directly to DHCP server

The renewal goes via the PROXY and the GiAddr is the WLAN controller..

(DellWireless.pcap) 

BUT THIS IS NOT THE ISSUE I WAS TALKING ABOUT

My issue is when the DHCP client talks directly to the DHCP server to renew as in Dell.pcap

It should ACK the request  and should unicast this back to client.

 Also after look at the .pcap the client is SPECIFICALLY Requesting a unicast reply.

From   https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point. Additionally, there is a BROADCAST flag (1 bit in 2 byte flags field, where all other bits are reserved and so are set to 0) the client can use to indicate in which way (broadcast or unicast) it can receive the DHCPOFFER: 0x8000 for broadcast, 0x0000 for unicast.^[8] Usually, the DHCPOFFER is sent through unicast.

In the Dell PC example

From the IoT device

Now when I read the RFC

https://www.rfc-archive.org/getrfc?rfc=5010&tag=The-Dynamic-Host-Configuration-Protocol-Version-4-%28DHCPv4%29-Relay-Agent-Flags-Suboption

it has the flag the other way around ??

This may be where the bug came in?

When I look at the document Meraki refer to  Page 24

https://tools.ietf.org/html/rfc2131#page-24

A client that can

   receive unicast IP datagrams before its protocol software has been

   configured SHOULD clear the BROADCAST bit to 0.

So it looks like wireshark is correctly decoding….

At this point I was convinced....  but Meraki was not !!!

So back to lab and I setup identical network  and this time I used a Windows 2008R2Server as the DHCP server and NOT the Meraki. I wanted to see if other vendors DHCP server had the same issue.

 

I removed the MX64  and replaced with Windows 2008R2 Server running DHCP Scope with x.x.1.0/24  subnet and reservation for x.x.1.33

So I was just changing the MX64 for a Microsoft windows 2008R2 DHCP server the network was identical.

Using my Dell Latop

 DHCP initial address  broadcasts and gets IP via the DHCP proxy  (No 1 to 4 in capture below)

 DHCP renewal is a Unicast direct to DHCP server and the ACK is a unicast to the client (No 4 , 5 below)

  DHCP Release  is a Unicast Direct to DHCP server…  (No 7 below)

This is 100% correct and works PERFECTLY

Compare this to how the MX64 works (explained in detail above)

  DHCP initial address  broadcasts and gets IP via the DHCP proxy

  DHCP renewal is a Unicast direct to DHCP server and the NAK is a broadcast (saying the address is not available)

Device never sees the broadcast as not on the same subnet

And keeps trying…  ALSO why iit get a NAK when it is a reservation ?

Meraki now believed me and the "Meraki Support Firewall" would now send this bug to development. (What a battle, you would think they would want to know about bugs in their software)

I was puzzled why other devices and the WLAN controller were not affected.  After some more traces all the clients were affected.  The difference here was after the renew failed all the other devices then did a normal broadcast for a new ip address after the renewal failed.  This IoT device did not and just went offline.

Mystery solved.

It is now 23rd of May 2020 and I still don't have any info from Meraki when this bug will be fixed.

 I did expect a bug of this nature to be fixed quite quickly.  I suppose this is the difference between Cisco Meraki and Cisco Enterprise products.  Bugs I have found in Cisco Enterprise products have been hot fixed within a week.

It is always tricky being a consultant as to how can I charge this customer for finding bugs in Meraki Devices.  I could have stopped when I identified the problem which is what the customer actually asked, but I wanted to get this issue actually fixed, but did not expect the resistance I got from the meraki support when trying to get this bug fixed.  Meraki support engineers get paid to work in the lab and isolate issues, I do not. I could not reasonably bill the customer for the 20 hours I have spent working on this simple issue.  I think Meraki owe me some "Meraki Swag" for finding this one !

 

** Update this issue has been fixed in MX 15.34 **