[Dnsmasq-discuss] Wrong server IP in dual normal/proxyDHCP mode
Simon Kelley
simon at thekelleys.org.uk
Wed May 20 20:21:43 BST 2015
Thanks for staying with this. I just checked in another patch. Is that
any better?
Cheers,
Simon.
On 20/05/15 05:24, Alkis Georgopoulos wrote:
> Whoops sorry I think that I misunderstood the difference of the two
> packets that I attached.
>
> In both the successful and the unsuccessful boots, the transaction has
> this exact message:
>
> 06:54:45.724145 3c:07:71:a2:02:e3 > c0:4a:00:02:bc:1e, ethertype IPv4
> (0x0800), length 590: (tos 0x0, ttl 20, id 2, offset 0, flags [none],
> proto UDP (17), length 576)
> 10.161.254.149.4011 > 10.161.254.11.4011: [udp sum ok] UDP, length 548
> 0x0000: c04a 0002 bc1e 3c07 71a2 02e3 0800 4500 .J....<.q.....E.
> 0x0010: 0240 0002 0000 1411 92c8 0aa1 fe95 0aa1 . at ..............
> 0x0020: fe0b 0fab 0fab 022c 41ca 0101 0600 72a2 .......,A.....r.
> 0x0030: 02e3 0004 0000 0aa1 fe95 0000 0000 0000 ................
> 0x0040: 0000 0000 0000 3c07 71a2 02e3 0000 0000 ......<.q.......
> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0110: 0000 0000 0000 6382 5363 3501 0337 2401 ......c.Sc5..7$.
> 0x0120: 0203 0405 060b 0c0d 0f10 1112 1617 1c28 ...............(
> 0x0130: 292a 2b32 3336 3a3b 3c42 4380 8182 8384 )*+236:;<BC.....
> 0x0140: 8586 8739 0204 ec61 1100 5048 dcb1 ba8a ...9...a..PH....
> 0x0150: e211 a00d 3c07 71a2 02e3 5d02 0000 5e03 ....<.q...]...^.
> 0x0160: 0102 013c 2050 5845 436c 6965 6e74 3a41 ...<.PXEClient:A
> 0x0170: 7263 683a 3030 3030 303a 554e 4449 3a30 rch:00000:UNDI:0
> 0x0180: 3032 3030 312b 0747 0480 0000 00ff ff00 02001+.G........
> 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0240: 0000 0000 0000 0000 0000 0000 0000 ..............
>
>
> Then the transaction has the packets that I attached in my previous
> message, which are different.
>
> What I misread was that in the successful case, there was a reply from
> the server (10.161.254.11) to the client (10.161.254.149),
> while in the unsuccessful case the client continued sending the same
> packet like ^ above to the server for 4-5 times before it gave up.
>
> So I'm guessing that the problem is that with the latest patch, the
> server doesn't reply with the "ACK?" packet at all.
>
>
> Thanks,
> Alkis
>
>
>
> On 20/05/2015 07:10 πμ, Alkis Georgopoulos wrote:
>> On 20/05/2015 01:04 πμ, Simon Kelley wrote:
>>> I just pushed a patch into git
>>>
>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7f8565b94ca52dde31f7688a9f9a0cc611d9dae3
>>>
>>>
>>>
>>> Please could you see if that helps? It should apply to the Ubuntu 14.04
>>> version, if that's easier.
>>
>>
>> Hi Simon,
>>
>> I tested against the git head version.
>> It did fix the boot server's IP, i.e. the client now tried to download
>> pxelinux.0 from the correct IP=10.161.254.11.
>>
>> Unfortunately it seems like it also broke PXE booting completely.
>> Completely, as in, now the client won't boot either with or without
>> #dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
>>
>> The client now reports (after getting the IP, and at the point where
>> it's supposed to download pxelinux.0):
>> UD 10.161.254.11....|
>> PXE-E78 - Could not locate boot server
>>
>> And aborts PXE boot.
>>
>>
>> I'm attaching two packets which might help a bit if you compare them.
>>
>> The first is the last packet from 4011 in the successful case, i.e.
>> without any patches at all, and with the "#dhcp-range=192.168.68.20..."
>> line commented out. I'm guessing that what we want is to send the same
>> packet even when that dhcp-range isn't commented out.
>>
>> 06:54:45.724239 c0:4a:00:02:bc:1e > 3c:07:71:a2:02:e3, ethertype IPv4
>> (0x0800), length 342: (tos 0xc0, ttl 64, id 800, offset 0, flags [none],
>> proto UDP (17), length 328)
>> 10.161.254.11.4011 > 10.161.254.149.4011: [udp sum ok] UDP, length 300
>> 0x0000: 3c07 71a2 02e3 c04a 0002 bc1e 0800 45c0 <.q....J......E.
>> 0x0010: 0148 0320 0000 4011 63e2 0aa1 fe0b 0aa1 .H.... at .c.......
>> 0x0020: fe95 0fab 0fab 0134 7345 0201 0600 72a2 .......4sE....r.
>> 0x0030: 02e3 0004 0000 0000 0000 0aa1 fe95 0aa1 ................
>> 0x0040: fe0b 0000 0000 3c07 71a2 02e3 0000 0000 ......<.q.......
>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0090: 0000 0000 0000 6c74 7370 2f69 3338 362f ......ltsp/i386/
>> 0x00a0: 7078 656c 696e 7578 2e30 0000 0000 0000 pxelinux.0......
>> 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0110: 0000 0000 0000 6382 5363 3501 0536 040a ......c.Sc5..6..
>> 0x0120: a1fe 0b3c 0950 5845 436c 6965 6e74 6111 ...<.PXEClienta.
>> 0x0130: 0050 48dc b1ba 8ae2 11a0 0d3c 0771 a202 .PH........<.q..
>> 0x0140: e32b 0747 0480 0000 00ff ff00 0000 0000 .+.G............
>> 0x0150: 0000 0000 0000 ......
>>
>>
>> The second is the last packet from 4011 with the latest patch applied
>> and with the "dhcp-range=192.168.68.20..." in effect. Now tt's a lot
>> longer than the successful one:
>>
>> 07:00:57.059681 3c:07:71:a2:02:e3 > c0:4a:00:02:bc:1e, ethertype IPv4
>> (0x0800), length 590: (tos 0x0, ttl 20, id 5, offset 0, flags [none],
>> proto UDP (17), length 576)
>> 10.161.254.149.4011 > 10.161.254.11.4011: [udp sum ok] UDP, length 548
>> 0x0000: c04a 0002 bc1e 3c07 71a2 02e3 0800 4500 .J....<.q.....E.
>> 0x0010: 0240 0005 0000 1411 92c5 0aa1 fe95 0aa1 . at ..............
>> 0x0020: fe0b 0fab 0fab 022c 41c4 0101 0600 72a2 .......,A.....r.
>> 0x0030: 02e3 000a 0000 0aa1 fe95 0000 0000 0000 ................
>> 0x0040: 0000 0000 0000 3c07 71a2 02e3 0000 0000 ......<.q.......
>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0110: 0000 0000 0000 6382 5363 3501 0337 2401 ......c.Sc5..7$.
>> 0x0120: 0203 0405 060b 0c0d 0f10 1112 1617 1c28 ...............(
>> 0x0130: 292a 2b32 3336 3a3b 3c42 4380 8182 8384 )*+236:;<BC.....
>> 0x0140: 8586 8739 0204 ec61 1100 5048 dcb1 ba8a ...9...a..PH....
>> 0x0150: e211 a00d 3c07 71a2 02e3 5d02 0000 5e03 ....<.q...]...^.
>> 0x0160: 0102 013c 2050 5845 436c 6965 6e74 3a41 ...<.PXEClient:A
>> 0x0170: 7263 683a 3030 3030 303a 554e 4449 3a30 rch:00000:UNDI:0
>> 0x0180: 3032 3030 312b 0747 0480 0000 00ff ff00 02001+.G........
>> 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0x0240: 0000 0000 0000 0000 0000 0000 0000 ..............
>>
>>
>> Again sorry for not having found some way to decode those packets.
>>
>> Cheers,
>> Alkis
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
More information about the Dnsmasq-discuss
mailing list