Repeater DHCP Issues

[penguin22]

So does your router see those requests and provide a response?

Maybe we’ll have to tcpdump on the router like @JDB suggested to see which hop is dropping the ball here. tcpdump on router + AP/Bridge would help a lot.

Well I have tcpdump loaded on the router, but the first capture I initiated was a bit overwhelming and didn't break from displaying everything from terminal. Is there a basic capture that would cover only DHCP requests to limit the volume of information?

tcpdump -i any '((port 67 or port 68) and (udp[8:1] = 0x1))'

might work; I'll test

I see the following, but my command must be a bit wonky as the log file isn't saving as I would expect and it is just displaying in the SSH. It does have some results populating though on the router:

admin1@RT-AC86U:/tmp/home/root# tcpdump -i any -vvv -s 1500 '((port 67 or port 68) and (udp[8:1] = 0x1))' | tee /tmp/mnt/entware/dhcp.log
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 1500 bytes
16:22:48.011502 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 308)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:62:6e:53:b8:80 (oui Unknown), length 280, xid 0x20067928, Flags [none] (0x0000)
          Client-IP DEfoscam3
          Client-Ethernet-Address 00:62:6e:53:b8:80 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 00:62:6e:53:b8:80
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 7:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP
            Vendor-Class Option 60, length 12: "udhcp 1.21.1"
            END Option 255, length 0
16:22:48.011525 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 308)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:62:6e:53:b8:80 (oui Unknown), length 280, xid 0x20067928, Flags [none] (0x0000)
          Client-IP DEfoscam3
          Client-Ethernet-Address 00:62:6e:53:b8:80 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 00:62:6e:53:b8:80
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 7:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP
            Vendor-Class Option 60, length 12: "udhcp 1.21.1"
            END Option 255, length 0

 

[JDB]

Add -w file.pcap to the command and then you can open the resulting trace in Wireshark and filter.

As suggested though, some capture filters wouldn’t go amiss save ending up with a huge file!!

Also, -i any will allow you to get packets from all interfaces. Particularly useful on the MB where you want to see Ethernet and Wi-fi side.


Sent from my iPhone using Tapatalk

 

[penguin22]

Add -w file.pcap to the command and then you can open the resulting trace in Wireshark and filter.

As suggested though, some capture filters wouldn’t go amiss save ending up with a huge file!!

Also, -i any will allow you to get packets from all interfaces. Particularly useful on the MB where you want to see Ethernet and Wi-fi side.


Sent from my iPhone using Tapatalk

The / tee command isn't writing a file and -w dhcp.pcap doesn't seem to be creating a file either. I'm getting closer to getting capture data, but this isn't my primary foray, so I'm learning on the fly.

 

[JDB]

Add a path to the file, so -w /tmp/mnt/usb/dhcp.pcap or whatever your path to your USB drive is. Can be sure you’re attempting to write to a writable partition then.


Sent from my iPhone using Tapatalk

 

[kfp]

You don’t need the last bit in your tcpdump command as we want to see all requests and responses. This filter will give you requests only.

 and (udp[8:1] = 0x1))

 

[kfp]

The / tee command isn't writing a file and -w dhcp.pcap doesn't seem to be creating a file either. I'm getting closer to getting capture data, but this isn't my primary foray, so I'm learning on the fly.

If you Ctrl-C out of tcpdump then the .log or .pcap should then be written I think, it gets written/flushed to periodically during a live capture.

 

[penguin22]

Add a path to the file, so -w /tmp/mnt/usb/dhcp.pcap or whatever your path to your USB drive is. Can be sure you’re attempting to write to a writable partition then.


Sent from my iPhone using Tapatalk

For the benefit of anyone else also trying to capture this, here is what I used (note that my sda1 label is entware, thus the duplicate name in path); I found that the first /tmp is not required and if included gives a path not found error:

tcpdump -i any -vvv -s 1500 '(port 67 or port 68)' -w /mnt/entware/entware/tmp/dhcp.pcap

In the short time I enabled this on the router, I see DHCP Discover, Offer, Request, and ACK transactions, however it seems that one client during the short period had 3 Discovers, followed by 2 Offers, 3 more Discovers, 2 more Offers, 3 Request, 2 ACK, and ongoing. I stopped the logging to confirm file accessibility, but expect that the loop would keep occurring and now need to add a USB drive to the MB as I'm wondering if the attempt is getting to the router, the response sent, but never getting past the MB to the client. TBC

 

[kfp]

In the short time I enabled this on the router, I see DHCP Discover, Offer, Request, and ACK transactions, however it seems that one client during the short period had 3 Discovers, followed by 2 Offers, 3 more Discovers, 2 more Offers, 3 Request, 2 ACK, and ongoing.

Great sleuthing. Adding visibility to MB would give us a complete picture. Probably want to capture right after power cycling the MB too so we have a baseline to compare against.

 

[penguin22]

Great sleuthing. Adding visibility to MB would give us a complete picture. Probably want to capture right after power cycling the MB too so we have a baseline to compare against.

Time will tell if this is a factor, but when adding a USB, I went to Tools\Other Settings rather than Administration\System, which I do far too often mixing them up mentally. In there, I had adjusted the setting, "dhcpd: send empty WPAD with a carriage return" to Yes when configuring from a full reset (have done so since it was added). In reading the description, I made a change to No only on the MB and have yet to have the DHCP issue thus far for the past few hours. I have now changed the router and AP to match and will continue to capture pcap of the router and MB and see if the behavior is resolved or not with logs either way.

One thing that I find odd, when I am taking the tcpdump capture, I am spammed with the following message constantly in the logs:

Jul  7 00:34:05 kernel: protocol 0800 is buggy, dev br0
Jul  7 00:34:05 kernel: protocol 0800 is buggy, dev br0

This stops the moment I break out of the tcpdump, so not a big issue, but odd nonetheless.

 

[JDB]

That err is purely a symptom of using a packet capture tool like tcpdump. Nothing to worry about.


Sent from my iPhone using Tapatalk

 

[penguin22]

Ok, for those knowledgeable of pcap troubleshooting, the problem persists, even following the WPAD setting adjustment. I currently have an Amazon Echo that will not obtain an IP address, surprisingly even after restarting the MB this afternoon. The following link contains 4 pcap files, cap1 is from last night and cap 2 is following a restart of the MB. https://1drv.ms/f/s!AjymRl4AerPXicYVzm2c7PxSdhKXpA

 

[kfp]

Ok, for those knowledgeable of pcap troubleshooting, the problem persists, even following the WPAD setting adjustment. I currently have an Amazon Echo that will not obtain an IP address, surprisingly even after restarting the MB this afternoon. The following link contains 4 pcap files, cap1 is from last night and cap 2 is following a restart of the MB. https://1drv.ms/f/s!AjymRl4AerPXicYVzm2c7PxSdhKXpA

There seems to be several Amazon devices, so I'm not really sure which one is having a problem.

One interesting thing though is that one Echo seems to be asking for a particular IP (192.168.1.98) after MB reboot and got denied with a DHCP NAK, those NAKs are present in both router-cap2 and MB-cap2, so I don't think this is a problem with any packets being dropped. But afterwards it got 192.168.50.53, which is consistent with what it got in cap1, so I don't think this is the problematic Echo.

 

[penguin22]

There seems to be several Amazon devices, so I'm not really sure which one is having a problem.

One interesting thing though is that one Echo seems to be asking for a particular IP (192.168.1.98) after MB reboot and got denied with a DHCP NAK, those NAKs are present in both router-cap2 and MB-cap2, so I don't think this is a problem with any packets being dropped. But afterwards it got 192.168.50.53, which is consistent with what it got in cap1, so I don't think this is the problematic Echo.

Sorry about that, it is as follows:

Living Room Echo
A0:02:DC:DF:A0:8F
192.168.50.19
LivingRoomEcho

Interesting part is that this Echo has a Manual Assignment in LAN\DHCP Server settings and does not show in the General Log, Wireless Log, or DHCP leases section. The AP shows the Echo connecting to the SSID and disconnecting; going to attempt to restart the AP to see if that has any effect.
Edit 2: Restarting the AP and MB allowed for DHCP to function again.

 

[kfp]

Sorry about that, it is as follows:

Living Room Echo
A0:02:DC:DF:A0:8F
192.168.50.19
LivingRoomEcho

Interesting part is that this Echo has a Manual Assignment in LAN\DHCP Server settings and does not show in the General Log, Wireless Log, or DHCP leases section. The AP shows the Echo connecting to the SSID and disconnecting; going to attempt to restart the AP to see if that has any effect.
Edit 2: Restarting the AP and MB allowed for DHCP to function again.

That one doesn’t seem to be in any of the PCAPs, so I guess it’s safe to say this time it’s the AP dropping the ball. As to why, I’m not sure.

 

[penguin22]

That one doesn’t seem to be in any of the PCAPs, so I guess it’s safe to say this time it’s the AP dropping the ball. As to why, I’m not sure.

Well that's ok, it gives me one more place to throw a USB drive, setup entware, tcpdump, and go to town

Getting the full picture and tracing root cause will hopefully help out everyone with more complex setups.

 

[penguin22]

Ok, I just got tcpdump installed to the AP and immediately notice that the amount of DHCP occurrences is far greater than that on the MB and router, by a huge amount! In the past 1-2 min, I see 140 occurrences, where it took 15-20 minutes for the same amount on the other devices. This will be interesting I think.

 

[penguin22]

Ok, same link now has the AP pcap.

 

[kfp]

Ok, same link now has the AP pcap.

Is there anything connected to the AP? The pcap looks almost exclusively broadcast messages and no DHCP ACKs in there, I don't have any more insight other than the Echos seems pretty aggressive on DHCP Discovers..

Which interface are you running tcpdump on? Maybe try capturing on br0?

 

[penguin22]

Ok, good news from a troubleshooting perspective, the issue surfaced this morning with my Surface Book after resuming from sleep where it didn't have an IP and couldn't obtain one. I stopped all applications on the SB, ran to another computer and was able to start network captures on the SB, router, MB, and AP (capture 1).
I tried initiating IP renewals using ipconfig /release and /renew with no success, performed a NIC reset (disable/re-enable - capture 2), and reboot of the SB (capture 3) with no change.

I then stopped the capture on the MB and rebooted from the SSH; following reboot, I restarted the captures on the SB, router and MB (capture 4). Next I checked the SB and it had not yet pulled an IP (good news from the capture perspective), then was able to immediately obtain an IP following an ipconfig /renew, which should be captured and visible in the following files:

4_SBdhcp_MBreboot_ipconfigrenew.pcapng
1_APdhcpSB.pcap - didn't need to be restarted
4_MBdhcpSBMBreboot.pcap
4_routerdhcpSBMBreboot.pcap

https://1drv.ms/f/s!AjymRl4AerPXicYVzm2c7PxSdhKXpA

Surface Book = SB
router (AC86U) = router
MB (AC68P) = MB
AP (AC3200) = AP

 

[Sparhawk]

Any updates on this?

I have a RT-AC86U with the same symptoms. (Clients attempting to connect over 2.4GHz are not receiving their DHCP addresses, but 5GHz works with no problems)

The strange part is that I bought this unit and set it up (as an AP) back in July, and it's been working fine until about two days ago.