Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hello, Does anyone have an issue if we make the change below? If we keep the code then at the very least the code should log why we are failing. Take Care Jason > On Sep 28, 2017, at 4:44 PM, Jason Kary wrote: > > Hi Folks, > > I was able to fix the problem by removing the following code: > > lines 1107-1108 in rfc2131.c: > > if (option_addr(opt).s_addr != override.s_addr) > return 0; > > Once I commented out this if statement the client was able to obtain the > correct IP address via DHCP Relay. The return 0 was causing the dnsmasq > process to just silently ignore the DHCP Request packet. > > I do not understand what the above code is checking for and why it is > returning 0. Maybe someone can help me the context a bit better? > > Take Care > Jason > >> On Sep 25, 2017, at 4:11 PM, Jason Kary > <mailto:jkary...@yahoo.com>> wrote: >> >> Hi Chris, >> >> I cloned the GIT repository and tested with version 2.78test2-gb697fbb >> >> I’m still seeing the server fail to respond to the request message: >> >> Frame 40189 (388 bytes on wire, 388 bytes captured) >>Arrival Time: Sep 25, 2017 20:59:01.142813000 >>[Time delta from previous captured frame: 0.000646000 seconds] >>[Time delta from previous displayed frame: 0.000646000 seconds] >>[Time since reference or first frame: 149.170698000 seconds] >>Frame Number: 40189 >>Frame Length: 388 bytes >>Capture Length: 388 bytes >>[Frame is marked: False] >>[Protocols in frame: eth:ip:udp:bootp] >> Ethernet II, Src: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1), Dst: >> 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >>Destination: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >>Address: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >> ...0 = IG bit: Individual address (unicast) >> ..0. = LG bit: Globally unique address >> (factory default) >>Source: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) >>Address: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) >> ...0 = IG bit: Individual address (unicast) >> ..0. = LG bit: Globally unique address >> (factory default) >>Type: IP (0x0800) >> Internet Protocol, Src: 33.33.33.33 (33.33.33.33), Dst: 10.168.101.20 >> (10.168.101.20) >>Version: 4 >>Header length: 20 bytes >>Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) >>0001 00.. = Differentiated Services Codepoint: Unknown (0x04) >> ..0. = ECN-Capable Transport (ECT): 0 >> ...0 = ECN-CE: 0 >>Total Length: 374 >>Identification: 0xbd9b (48539) >>Flags: 0x00 >>0.. = Reserved bit: Not Set >>.0. = Don't fragment: Not Set >>..0 = More fragments: Not Set >>Fragment offset: 0 >>Time to live: 255 >>Protocol: UDP (0x11) >>Header checksum: 0x4acd [correct] >>[Good: True] >>[Bad : False] >>Source: 33.33.33.33 (33.33.33.33) >>Destination: 10.168.101.20 (10.168.101.20) >> User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67) >>Source port: bootps (67) >>Destination port: bootps (67) >>Length: 354 >>Checksum: 0x95d3 [validation disabled] >>[Good Checksum: False] >>[Bad Checksum: False] >> Bootstrap Protocol >>Message type: Boot Request (1) >>Hardware type: Ethernet >>Hardware address length: 6 >>Hops: 1 >>Transaction ID: 0x21696b65 >>Seconds elapsed: 0 >>Bootp flags: 0x (Unicast) >>0... = Broadcast flag: Unicast >>.000 = Reserved flags: 0x >>Client IP address: 0.0.0.0 (0.0.0.0) >>Your (client) IP address: 0.0.0.0 (0.0.0.0) >>Next server IP address: 0.0.0.0 (0.0.0.0) >>Relay agent IP address: 33.33.33.33 (33.33.33.33) >>Client MAC address: 00:0c:29:65:e0:ea (00:0c:29:65:e0:ea) >>Client hardware address padding: >>Server host name not given >>Boot file name not given >>Magic cookie: (OK) >>Option: (t=53,l=1) DHCP Message Type = DHCP Request >>Option: (53) DHCP Message Type >>Length: 1 >>Value: 03 >>Option: (t=54,l=4) DHCP Server Identifier = 10.168.101.20 >>Option: (54) DHCP Server Identifier >>Length: 4 >>Value: 0AA86514 &g
Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hi Folks, I was able to fix the problem by removing the following code: lines 1107-1108 in rfc2131.c: if (option_addr(opt).s_addr != override.s_addr) return 0; Once I commented out this if statement the client was able to obtain the correct IP address via DHCP Relay. The return 0 was causing the dnsmasq process to just silently ignore the DHCP Request packet. I do not understand what the above code is checking for and why it is returning 0. Maybe someone can help me the context a bit better? Take Care Jason > On Sep 25, 2017, at 4:11 PM, Jason Kary wrote: > > Hi Chris, > > I cloned the GIT repository and tested with version 2.78test2-gb697fbb > > I’m still seeing the server fail to respond to the request message: > > Frame 40189 (388 bytes on wire, 388 bytes captured) >Arrival Time: Sep 25, 2017 20:59:01.142813000 >[Time delta from previous captured frame: 0.000646000 seconds] >[Time delta from previous displayed frame: 0.000646000 seconds] >[Time since reference or first frame: 149.170698000 seconds] >Frame Number: 40189 >Frame Length: 388 bytes >Capture Length: 388 bytes >[Frame is marked: False] >[Protocols in frame: eth:ip:udp:bootp] > Ethernet II, Src: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1), Dst: > 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >Destination: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >Address: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) >Source: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) >Address: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) >Type: IP (0x0800) > Internet Protocol, Src: 33.33.33.33 (33.33.33.33), Dst: 10.168.101.20 > (10.168.101.20) >Version: 4 >Header length: 20 bytes >Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) >0001 00.. = Differentiated Services Codepoint: Unknown (0x04) > ..0. = ECN-Capable Transport (ECT): 0 > ...0 = ECN-CE: 0 >Total Length: 374 >Identification: 0xbd9b (48539) >Flags: 0x00 >0.. = Reserved bit: Not Set >.0. = Don't fragment: Not Set >..0 = More fragments: Not Set >Fragment offset: 0 >Time to live: 255 >Protocol: UDP (0x11) >Header checksum: 0x4acd [correct] >[Good: True] >[Bad : False] >Source: 33.33.33.33 (33.33.33.33) >Destination: 10.168.101.20 (10.168.101.20) > User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67) >Source port: bootps (67) >Destination port: bootps (67) >Length: 354 >Checksum: 0x95d3 [validation disabled] >[Good Checksum: False] >[Bad Checksum: False] > Bootstrap Protocol >Message type: Boot Request (1) >Hardware type: Ethernet >Hardware address length: 6 >Hops: 1 >Transaction ID: 0x21696b65 >Seconds elapsed: 0 >Bootp flags: 0x (Unicast) >0... = Broadcast flag: Unicast >.000 = Reserved flags: 0x >Client IP address: 0.0.0.0 (0.0.0.0) >Your (client) IP address: 0.0.0.0 (0.0.0.0) >Next server IP address: 0.0.0.0 (0.0.0.0) >Relay agent IP address: 33.33.33.33 (33.33.33.33) >Client MAC address: 00:0c:29:65:e0:ea (00:0c:29:65:e0:ea) >Client hardware address padding: >Server host name not given >Boot file name not given >Magic cookie: (OK) >Option: (t=53,l=1) DHCP Message Type = DHCP Request >Option: (53) DHCP Message Type >Length: 1 >Value: 03 >Option: (t=54,l=4) DHCP Server Identifier = 10.168.101.20 >Option: (54) DHCP Server Identifier >Length: 4 >Value: 0AA86514 >Option: (t=50,l=4) Requested IP Address = 10.168.102.128 >Option: (50) Requested IP Address >Length: 4 >Value: 0AA86680 >Option: (t=55,l=18) Parameter Request List >Option: (55) Parameter Request List >Length: 18 >Value: 011C02790F060C28292A1A770379F921FC2A >1 = Subnet Mask >28 = Broadcast Address >2 = Time Offset >121 = Classless Static Route >15 = Domain Name >6 = Domain Name Server >12 = Host Name >40 = Network Information Service Domain >41 = Network Information Service Servers >42 = Network Time Protocol Serve
Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hi Folks, I wanted to follow up and see if anyone is available to help debug this issue? I won’t have the test bed available to me to help out for much longer. Is there some sort of debug that I could collect to help with the analysis? Take Care Jason > On Sep 25, 2017, at 4:11 PM, Jason Kary wrote: > > Hi Chris, > > I cloned the GIT repository and tested with version 2.78test2-gb697fbb > > I’m still seeing the server fail to respond to the request message: > > Frame 40189 (388 bytes on wire, 388 bytes captured) >Arrival Time: Sep 25, 2017 20:59:01.142813000 >[Time delta from previous captured frame: 0.000646000 seconds] >[Time delta from previous displayed frame: 0.000646000 seconds] >[Time since reference or first frame: 149.170698000 seconds] >Frame Number: 40189 >Frame Length: 388 bytes >Capture Length: 388 bytes >[Frame is marked: False] >[Protocols in frame: eth:ip:udp:bootp] > Ethernet II, Src: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1), Dst: > 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >Destination: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) >Address: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) >Source: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) >Address: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) >Type: IP (0x0800) > Internet Protocol, Src: 33.33.33.33 (33.33.33.33), Dst: 10.168.101.20 > (10.168.101.20) >Version: 4 >Header length: 20 bytes >Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) >0001 00.. = Differentiated Services Codepoint: Unknown (0x04) > ..0. = ECN-Capable Transport (ECT): 0 > ...0 = ECN-CE: 0 >Total Length: 374 >Identification: 0xbd9b (48539) >Flags: 0x00 >0.. = Reserved bit: Not Set >.0. = Don't fragment: Not Set >..0 = More fragments: Not Set >Fragment offset: 0 >Time to live: 255 >Protocol: UDP (0x11) >Header checksum: 0x4acd [correct] >[Good: True] >[Bad : False] >Source: 33.33.33.33 (33.33.33.33) >Destination: 10.168.101.20 (10.168.101.20) > User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67) >Source port: bootps (67) >Destination port: bootps (67) >Length: 354 >Checksum: 0x95d3 [validation disabled] >[Good Checksum: False] >[Bad Checksum: False] > Bootstrap Protocol >Message type: Boot Request (1) >Hardware type: Ethernet >Hardware address length: 6 >Hops: 1 >Transaction ID: 0x21696b65 >Seconds elapsed: 0 >Bootp flags: 0x (Unicast) >0... = Broadcast flag: Unicast >.000 = Reserved flags: 0x >Client IP address: 0.0.0.0 (0.0.0.0) >Your (client) IP address: 0.0.0.0 (0.0.0.0) >Next server IP address: 0.0.0.0 (0.0.0.0) >Relay agent IP address: 33.33.33.33 (33.33.33.33) >Client MAC address: 00:0c:29:65:e0:ea (00:0c:29:65:e0:ea) >Client hardware address padding: >Server host name not given >Boot file name not given >Magic cookie: (OK) >Option: (t=53,l=1) DHCP Message Type = DHCP Request >Option: (53) DHCP Message Type >Length: 1 >Value: 03 >Option: (t=54,l=4) DHCP Server Identifier = 10.168.101.20 >Option: (54) DHCP Server Identifier >Length: 4 >Value: 0AA86514 >Option: (t=50,l=4) Requested IP Address = 10.168.102.128 >Option: (50) Requested IP Address >Length: 4 >Value: 0AA86680 >Option: (t=55,l=18) Parameter Request List >Option: (55) Parameter Request List >Length: 18 >Value: 011C02790F060C28292A1A770379F921FC2A >1 = Subnet Mask >28 = Broadcast Address >2 = Time Offset >121 = Classless Static Route >15 = Domain Name >6 = Domain Name Server >12 = Host Name >40 = Network Information Service Domain >41 = Network Information Service Servers >42 = Network Time Protocol Servers >26 = Interface MTU >119 = Domain Search [TODO] >3 = Router >121 = Classless Static Route >249 = Private/Classless Static Route (Microsoft) >33 = Static Route >252 = Private/Proxy autodiscovery >42
Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hi Chris,
I cloned the GIT repository and tested with version 2.78test2-gb697fbb
I’m still seeing the server fail to respond to the request message:
Frame 40189 (388 bytes on wire, 388 bytes captured)
Arrival Time: Sep 25, 2017 20:59:01.142813000
[Time delta from previous captured frame: 0.000646000 seconds]
[Time delta from previous displayed frame: 0.000646000 seconds]
[Time since reference or first frame: 149.170698000 seconds]
Frame Number: 40189
Frame Length: 388 bytes
Capture Length: 388 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:bootp]
Ethernet II, Src: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1), Dst: 00:0c:29:cf:10:0b
(00:0c:29:cf:10:0b)
Destination: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b)
Address: 00:0c:29:cf:10:0b (00:0c:29:cf:10:0b)
...0 = IG bit: Individual address (unicast)
..0. = LG bit: Globally unique address (factory
default)
Source: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1)
Address: 58:ac:78:b1:38:e1 (58:ac:78:b1:38:e1)
...0 = IG bit: Individual address (unicast)
..0. = LG bit: Globally unique address (factory
default)
Type: IP (0x0800)
Internet Protocol, Src: 33.33.33.33 (33.33.33.33), Dst: 10.168.101.20
(10.168.101.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
..0. = ECN-Capable Transport (ECT): 0
...0 = ECN-CE: 0
Total Length: 374
Identification: 0xbd9b (48539)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: UDP (0x11)
Header checksum: 0x4acd [correct]
[Good: True]
[Bad : False]
Source: 33.33.33.33 (33.33.33.33)
Destination: 10.168.101.20 (10.168.101.20)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
Source port: bootps (67)
Destination port: bootps (67)
Length: 354
Checksum: 0x95d3 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0x21696b65
Seconds elapsed: 0
Bootp flags: 0x (Unicast)
0... = Broadcast flag: Unicast
.000 = Reserved flags: 0x
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 33.33.33.33 (33.33.33.33)
Client MAC address: 00:0c:29:65:e0:ea (00:0c:29:65:e0:ea)
Client hardware address padding:
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Option: (53) DHCP Message Type
Length: 1
Value: 03
Option: (t=54,l=4) DHCP Server Identifier = 10.168.101.20
Option: (54) DHCP Server Identifier
Length: 4
Value: 0AA86514
Option: (t=50,l=4) Requested IP Address = 10.168.102.128
Option: (50) Requested IP Address
Length: 4
Value: 0AA86680
Option: (t=55,l=18) Parameter Request List
Option: (55) Parameter Request List
Length: 18
Value: 011C02790F060C28292A1A770379F921FC2A
1 = Subnet Mask
28 = Broadcast Address
2 = Time Offset
121 = Classless Static Route
15 = Domain Name
6 = Domain Name Server
12 = Host Name
40 = Network Information Service Domain
41 = Network Information Service Servers
42 = Network Time Protocol Servers
26 = Interface MTU
119 = Domain Search [TODO]
3 = Router
121 = Classless Static Route
249 = Private/Classless Static Route (Microsoft)
33 = Static Route
252 = Private/Proxy autodiscovery
42 = Network Time Protocol Servers
Option: (t=82,l=44) Agent Information Option
Option: (82) Agent Information Option
Length: 44
Value: 010A01080006004C4F2A002F020658AC78B138E1970A0062...
Agent Circuit ID: 01080006004C4F2A002F
Agent Remote ID: 58AC78B138E1
DHCPv4 Virtual Subnet Selection: 006262742D76786C616E
Server Identifier Override: 0AA86601
Link selection: 10.168.102.0
End Option
Padding
Pls find my dnsmasq.conf as follows:
Take Care
Jason
> On Sep 25, 2017, at 4:10 PM, Jason Kary (jkary) wrote:
>
> Hi,
>
> Pls find my dnsmasq.conf as follows:
>
>
>
> Take Care
> Jason
>
>> On Sep 22, 2017, at 5:10 PM, Chris Novakovic > <mailto:ch...@chrisn.me.uk>> wrote:
>>
>> On 22/09/2017 19:24, Jason Kary (jkary) wrote:
>>> Thank yo
Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hi Chris, Thank you for the update. We are running version 2.66 Take Care Jason > On Sep 22, 2017, at 8:44 AM, Chris Novakovic wrote: > > On 22/09/2017 13:42, Chris Novakovic wrote: >> If you're using 2.76, > > It's implied by my later comment, but I should also clarify that this > bug affects 2.77 as well as 2.76. > . ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DNSMASQ Not Sending ACK?
Hi Folks, I’m working on getting DNSMASQ to work with IP RELAY in a VxLAN environment. Using tcpdump we were able to trace a DHCP relay request to the ‘request’ message. It appears the server is not sending an DHCP ACK message. Here is a tcpdump of the request message: 11:18:56.868214 IP (tos 0x10, ttl 254, id 29262, offset 0, flags [none], proto UDP (17), length 374) 22.22.22.21.bootps > dhcp-server.localdomain.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:25:b5:00:00:01 (oui Unknown), length 346, hops 1, xid 0x9a632d2c, Flags [none] (0x) Gateway-IP 22.22.22.21 Client-Ethernet-Address 00:25:b5:00:00:01 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Server-ID Option 54, length 4: dhcp-server.localdomain Requested-IP Option 50, length 4: 10.168.102.132 Parameter-Request Option 55, length 18: Subnet-Mask, BR, Time-Zone, Classless-Static-Route Domain-Name, Domain-Name-Server, Hostname, YD YS, NTP, MTU, Option 119 Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route Option 252, NTP Agent-Information Option 82, length 44: Circuit-ID SubOption 1, length 10: ^A^H^@^F^@LO*^@^I Remote-ID SubOption 2, length 6: M-LFM-V!M-)w Unknown SubOption 151, length 10: 0x: 0062 6274 2d76 786c 616e Unknown SubOption 11, length 4: 0x: 0aa8 6601 Unknown SubOption 5, length 4: 0x: 0aa8 6600 END Option 255, length 0 PAD Option 0, length 0, occurs 24 Is there any obvious issues you can see here? Take Care Jason [root@dhcp-server ~]# tcpdump -i ens224 'port 67 or port 68' -vvv tcpdump: listening on ens224, link-type EN10MB (Ethernet), capture size 65535 bytes 11:18:19.830492 IP (tos 0x10, ttl 254, id 29216, offset 0, flags [none], proto UDP (17), length 374) 22.22.22.21.bootps > dhcp-server.localdomain.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:25:b5:00:00:01 (oui Unknown), length 346, hops 1, xid 0xf0c7735e, Flags [none] (0x) Gateway-IP 22.22.22.21 Client-Ethernet-Address 00:25:b5:00:00:01 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 18: Subnet-Mask, BR, Time-Zone, Classless-Static-Route Domain-Name, Domain-Name-Server, Hostname, YD YS, NTP, MTU, Option 119 Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route Option 252, NTP Agent-Information Option 82, length 44: Circuit-ID SubOption 1, length 10: ^A^H^@^F^@LO*^@^I Remote-ID SubOption 2, length 6: M-LFM-V!M-)w Unknown SubOption 151, length 10: 0x: 0062 6274 2d76 786c 616e Unknown SubOption 11, length 4: 0x: 0aa8 6601 Unknown SubOption 5, length 4: 0x: 0aa8 6600 END Option 255, length 0 PAD Option 0, length 0, occurs 36 11:18:22.087323 IP (tos 0xc0, ttl 64, id 20920, offset 0, flags [none], proto UDP (17), length 372) dhcp-server.localdomain.bootps > 22.22.22.21.bootps: [bad udp cksum 0x9d58 -> 0xbe56!] BOOTP/DHCP, Reply, length 344, hops 1, xid 0xf0c7735e, Flags [none] (0x) Your-IP 10.168.102.132 Server-IP dhcp-server.localdomain Gateway-IP 22.22.22.21 Client-Ethernet-Address 00:25:b5:00:00:01 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.168.102.1 Lease-Time Option 51, length 4: 43200 RN Option 58, length 4: 21600 RB Option 59, length 4: 37800 SUBNET Option 118, length 4: 10.168.102.0 Subnet-Mask Option 1, length 4: 255.255.255.0 BR Option 28, length 4: 10.168.102.255 Domain-Name-Server Option 6, length 4: dhcp-server.localdomain Default-Gateway Option 3, length 4: 10.168.102.1 Agent-Information Option 82, length 44: Circuit-ID SubOption 1, length 10: ^A^H^@^F^@LO*^@^I Remote-ID SubOption 2, length 6: M-LFM-V!M-)w Unknown SubOption 151, length 10: 0x: 0062 6274 2d76 786c 616e Unknown SubOption 11, length 4: 0x: 0aa8 6601 Unknown SubOption 5, length 4: 0x: 0aa8 6600 END Option 255, length 0 11:18:22.088871 IP (tos 0x10, ttl 254, id 29219, offset 0, flags [none
Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.
Hi Dan, Thank you for the update. This appears to have resolved my issue. Take Care Jason > On May 1, 2017, at 2:35 PM, Dan Sneddon wrote: > > Your routing table is wrong. You have both 10.168.101.0/24 and > 10.168.102.0/24 both set up as local subnets (see the 0.0.0.0 gateway). > The remote subnet should be routed through the local router, so your > route would appear something like this: > > 10.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160 > 10.168.102.0 10.168.101.1 255.255.255.0 U 0 0 0 ens160 > > -- > Dan Sneddon | Senior Principal Software Engineer > dsned...@redhat.com | redhat.com/openstack > dsneddon:irc| @dxs:twitter > > On 04/27/2017 02:02 PM, Jason Kary wrote: >> Hi Folks, >> >> I have a basic setup for DHCP relay across VLANS in DNSMASQ. >> >> My configuration file looks like: >> >> >>bogus-priv >>interface=ens160 >>log-dhcp >>dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h >> >> >> The client and server are running on a VMs in separate VLANS. DHCP >> requests appear to be coming across: >> >> >>root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n >>tcpdump: verbose output suppressed, use -v or -vv for full protocol >>decode >>listening on ens160, link-type EN10MB (Ethernet), capture size >>262144 bytes >>03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >> >>root@DHCP-UBUNTU-SERVER:~# iptables -L >>Chain INPUT (policy ACCEPT) >>target prot opt source destination >> >>Chain FORWARD (policy ACCEPT) >>target prot opt source destination >> >>Chain OUTPUT (policy ACCEPT) >>target prot opt source destination >>root@DHCP-UBUNTU-SERVER:~# >> >> >> The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out >> however nothing is seen on the wire. >> >> >>Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>available DHCP range: 10.168.102.100 -- 10.168.102.150 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>tags: ens160 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 1:netmask, 28:broadcast, 2:time-offset, >>121:classless-static-route, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 15:domain-name, 6:dns-server, 12:hostname, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 40:nis-domain, 41:nis-server, 42:ntp-server, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 26:mtu, 119:domain-search, 3:router, >>121:classless-static-route, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 249, 33:static-route, 252, 42:ntp-server >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>next server: 10.168.101.20 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 1 option: 53 message-type 2 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 54 server-identifier 10.168.101.20 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 51 lease-time 12h >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 58 T1 6h >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 59 T2 10h30m >>Apr
Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.
Hello, The VLAN setup is pretty basic: interface Vlan1001 no shutdown mtu 9216 no ip redirects ip address 10.168.101.1/24 interface Vlan1002 no shutdown mtu 9216 no ip redirects ip address 10.168.102.1/24 ip dhcp relay address 10.168.101.20 ip dhcp relay source-interface Vlan1002 Single host running ESXi connected to single router. Take Care Jason > On Apr 28, 2017, at 5:36 PM, Simon Kelley wrote: > > On 27/04/17 22:02, Jason Kary wrote: >> Hi Folks, >> >> I have a basic setup for DHCP relay across VLANS in DNSMASQ. >> >> My configuration file looks like: >> >> >>bogus-priv >>interface=ens160 >>log-dhcp >>dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h >> >> >> The client and server are running on a VMs in separate VLANS. DHCP >> requests appear to be coming across: >> >> >>root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n >>tcpdump: verbose output suppressed, use -v or -vv for full protocol >>decode >>listening on ens160, link-type EN10MB (Ethernet), capture size >>262144 bytes >>03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >>03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, >>Request from 00:0c:29:65:e0:ea, length 322 >> >>root@DHCP-UBUNTU-SERVER:~# iptables -L >>Chain INPUT (policy ACCEPT) >>target prot opt source destination >> >>Chain FORWARD (policy ACCEPT) >>target prot opt source destination >> >>Chain OUTPUT (policy ACCEPT) >>target prot opt source destination >>root@DHCP-UBUNTU-SERVER:~# >> >> >> The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out >> however nothing is seen on the wire. >> >> >>Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>available DHCP range: 10.168.102.100 -- 10.168.102.150 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>tags: ens160 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 1:netmask, 28:broadcast, 2:time-offset, >>121:classless-static-route, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 15:domain-name, 6:dns-server, 12:hostname, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 40:nis-domain, 41:nis-server, 42:ntp-server, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 26:mtu, 119:domain-search, 3:router, >>121:classless-static-route, >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>requested options: 249, 33:static-route, 252, 42:ntp-server >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>next server: 10.168.101.20 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 1 option: 53 message-type 2 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 54 server-identifier 10.168.101.20 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 51 lease-time 12h >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 58 T1 6h >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 59 T2 10h30m >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 1 netmask 255.255.255.0 >>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 >>sent size: 4 option: 28 broadcast 10.168.102.255 >>Apr 27 04:03:29 DHCP-UBUNT
[Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.
Hi Folks, I have a basic setup for DHCP relay across VLANS in DNSMASQ. My configuration file looks like: bogus-priv interface=ens160 log-dhcp dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h The client and server are running on a VMs in separate VLANS. DHCP requests appear to be coming across: root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes 03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, Request from 00:0c:29:65:e0:ea, length 322 03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, Request from 00:0c:29:65:e0:ea, length 322 03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, Request from 00:0c:29:65:e0:ea, length 322 03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, Request from 00:0c:29:65:e0:ea, length 322 03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, Request from 00:0c:29:65:e0:ea, length 322 root@DHCP-UBUNTU-SERVER:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination root@DHCP-UBUNTU-SERVER:~# The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out however nothing is seen on the wire. Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 available DHCP range: 10.168.102.100 -- 10.168.102.150 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 tags: ens160 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 requested options: 1:netmask, 28:broadcast, 2:time-offset, 121:classless-static-route, Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 requested options: 15:domain-name, 6:dns-server, 12:hostname, Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 requested options: 40:nis-domain, 41:nis-server, 42:ntp-server, Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 requested options: 26:mtu, 119:domain-search, 3:router, 121:classless-static-route, Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 requested options: 249, 33:static-route, 252, 42:ntp-server Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 next server: 10.168.101.20 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 1 option: 53 message-type 2 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 54 server-identifier 10.168.101.20 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 51 lease-time 12h Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 58 T1 6h Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 59 T2 10h30m Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 1 netmask 255.255.255.0 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 28 broadcast 10.168.102.255 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 3 router 10.168.102.1 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 4 option: 6 dns-server 10.168.101.20 Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 sent size: 20 option: 82 agent-id 01:0a:01:08:00:06:00:4c:4f:2a:00:2f:02:06… I’ve been trying to trace this issue and it is like the sendmsg system call is not working properly. I believe routing is setup properly on the DHCP server. root@DHCP-UBUNTU-SERVER:~# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 172.31.13.1 0.0.0.0 UG0 0 0 ens192 10.168.101.00.0.0.0 255.255.255.0 U 0 0 0 ens160 10.168.102.00.0.0.0 255.255.255.0 U 0 0 0 ens160 172.31.13.0 0.0.0.0 255.255.255.0 U 0 0 0 ens192 root@DHCP-UBUNTU-SERVER:~# Can anyone seen something obvious that I am doing wrong? Take Care Jason___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
