Discussion:
[Dnsmasq-discuss] Wrong server IP in dual normal/proxyDHCP mode
Alkis Georgopoulos
2015-05-14 05:34:48 UTC
Permalink
Since proxyDHCP mode doesn't yet work for UEFI clients, I'm using the
following as a workaround:

dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.67.20,192.168.67.250,8h

This is with a single NIC, dual IP server (10.161.254.11, 192.168.67.1).
The 192.168.67.1 server IP is only used to PXE boot the UEFI clients.

The problem is that the proxyDHCP clients receive
proxyDHCP server IP = 192.168.68.1
instead of the expected 10.161.254.11.

I.e. I would expect dnsmasq to reply with the server IP that matches the
proxyDHCP subnet, not the other one, which the clients can't reach.


Would that be a bug or am I doing something wrong?
Thanks!
Simon Kelley
2015-05-14 20:32:08 UTC
Permalink
Post by Alkis Georgopoulos
Since proxyDHCP mode doesn't yet work for UEFI clients, I'm using the
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.67.20,192.168.67.250,8h
This is with a single NIC, dual IP server (10.161.254.11, 192.168.67.1).
The 192.168.67.1 server IP is only used to PXE boot the UEFI clients.
The problem is that the proxyDHCP clients receive
proxyDHCP server IP = 192.168.68.1
instead of the expected 10.161.254.11.
I.e. I would expect dnsmasq to reply with the server IP that matches the
proxyDHCP subnet, not the other one, which the clients can't reach.
Would that be a bug or am I doing something wrong?
Bug, I think, could you try the code in the git repo HEAD

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=tree;h=62018e1f720fa11e83879111a4b1b3753b5c25bb;hb=62018e1f720fa11e83879111a4b1b3753b5c25bb

Cheers,

Simon.
Post by Alkis Georgopoulos
Thanks!
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Alkis Georgopoulos
2015-05-15 06:43:15 UTC
Permalink
Hi Simon, thanks for the patch,

it's a bit better, the client reports the correct proxyDHCP, but then
tries to fetch pxelinux.0 from the wrong TFTP server IP and fails.

Some network dump info: *only* when I'm using iPXE for the client, in
`dhcpdump -i eth1`, I see the wrong SIADDR:

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

TIME: 2015-05-15 08:43:32.853
IP: 10.161.254.11 (c0:4a:0:2:bc:1e) > 10.161.254.209 (8:0:27:8f:74:ad)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 00000000
SECS: 4
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 10.161.254.209
SIADDR: 192.168.68.1
GIADDR: 0.0.0.0
CHADDR: 08:00:27:8f:74:ad:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: /ltsp/i386/pxelinux.0.
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 54 ( 4) Server identifier 192.168.68.1
OPTION: 60 ( 9) Vendor class identifier PXEClient
OPTION: 97 ( 17) UUID/GUID 00e42f96d0e4e357 ../....W
4da25e75dab1f77f M.^u....
ac .
OPTION: 43 ( 7) Vendor specific info 470480000000ff G......
---------------------------------------------------------------------------

In the iPXE's `config` I don't see 192.168.68.x anywhere though.

On the other hand, when I'm using the NIC's PXE stack, I don't see
192.168.68.1 anywhere in the output of `dhcpdump`!!!

I'm attaching the whole output of `tcpdump` below, maybe your
experienced eyes will pinpoint it.

If it makes any difference, I applied your patch to the Ubuntu's 14.04
dnsmasq version (dnsmasq-base 2.68-1ubuntu0.1), but I can also test with
the git trunk if needed.

Thanks a lot,
Alkis

==================================================
***@srv1-dide:~/tmp/dnsmasq/dnsmasq-2.68$ sudo tcpdump -i eth1 port
67 or port 68 or port 69 or port 4011 -e -n -vv
[sudo] password for alkisg:
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
65535 bytes
09:24:52.784009 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 0, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
GUID Option 97, length 17:
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
09:24:52.784016 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 0, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
GUID Option 97, length 17:
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
09:24:52.784170 c0:4a:00:02:bc:1e > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 365: (tos 0xc0, ttl 64, id 5393, offset 0, flags
[none], proto UDP (17), length 351)
10.161.254.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 323, xid 0x288f74ad, secs 4, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
file "/ltsp/i386/pxelinux.0"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.161.254.11
Vendor-Class Option 60, length 9: "PXEClient"
GUID Option 97, length 17:
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
Vendor-Option Option 43, length 41:
6.1.3.10.4.0.80.88.69.8.7.128.0.1.10.161.254.11.9.20.128.0.17.66.111.111.116.32.102.114.111.109.32.110.101.116.119.111.114.107.255
09:24:52.786368 00:24:97:f7:d9:06 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 344: (tos 0x0, ttl 255, id 14657, offset 0, flags
[none], proto UDP (17), length 330)
10.161.254.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 302, xid 0x288f74ad, Flags [Broadcast] (0x8000)
Your-IP 10.161.254.208
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.161.254.1
Lease-Time Option 51, length 4: 430603
RN Option 58, length 4: 215301
RB Option 59, length 4: 376777
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 10: "ioa.sch.gr"
Domain-Name-Server Option 6, length 8: 194.63.239.164,194.63.238.4
Default-Gateway Option 3, length 4: 10.161.254.1
09:24:54.811307 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 10.161.254.208
Parameter-Request Option 55, length 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
Server-ID Option 54, length 4: 10.161.254.1
GUID Option 97, length 17:
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
09:24:54.811313 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 10.161.254.208
Parameter-Request Option 55, length 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
Server-ID Option 54, length 4: 10.161.254.1
GUID Option 97, length 17:
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
09:24:54.813302 00:24:97:f7:d9:06 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 344: (tos 0x0, ttl 255, id 14658, offset 0, flags
[none], proto UDP (17), length 330)
10.161.254.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 302, xid 0x288f74ad, Flags [Broadcast] (0x8000)
Your-IP 10.161.254.208
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.161.254.1
Lease-Time Option 51, length 4: 432000
RN Option 58, length 4: 216000
RB Option 59, length 4: 378000
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 10: "ioa.sch.gr"
Domain-Name-Server Option 6, length 8: 194.63.239.164,194.63.238.4
Default-Gateway Option 3, length 4: 10.161.254.1
09:24:54.817082 08:00:27:8f:74:ad > 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.208.4011 > 10.161.254.11.4011: [udp sum ok] UDP, length 548
09:24:54.817183 c0:4a:00:02:bc:1e > 08:00:27:8f:74:ad, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 24832, offset 0, flags
[none], proto UDP (17), length 328)
10.161.254.11.4011 > 10.161.254.208.4011: [udp sum ok] UDP, length 300
09:24:55.856377 08:00:27:8f:74:ad > 00:24:97:f7:d9:06, ethertype IPv4
(0x0800), length 80: (tos 0x0, ttl 20, id 3, offset 0, flags [none],
proto UDP (17), length 66)
10.161.254.208.2070 > 192.168.68.1.69: [udp sum ok] 38 RRQ
"/ltsp/i386/pxelinux.0" octet tsize 0
09:25:00.545579 2c:27:d7:dc:2e:66 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 342: (tos 0x0, ttl 128, id 10752, offset 0, flags
[none], proto UDP (17), length 328)
10.161.254.190.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP,
Request from 2c:27:d7:dc:2e:66, length 300, xid 0xb9606c6d, Flags
[Broadcast] (0x8000)
Client-IP 10.161.254.190
Client-Ethernet-Address 2c:27:d7:dc:2e:66
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Inform
Client-ID Option 61, length 7: ether 2c:27:d7:dc:2e:66
Hostname Option 12, length 8: "gymnasio"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 13:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option
Option 252

================================================================
Post by Simon Kelley
Post by Alkis Georgopoulos
Since proxyDHCP mode doesn't yet work for UEFI clients, I'm using the
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
This is with a single NIC, dual IP server (10.161.254.11, 192.168.68.1).
The 192.168.67.1 server IP is only used to PXE boot the UEFI clients.
The problem is that the proxyDHCP clients receive
proxyDHCP server IP = 192.168.68.1
instead of the expected 10.161.254.11.
I.e. I would expect dnsmasq to reply with the server IP that matches the
proxyDHCP subnet, not the other one, which the clients can't reach.
Would that be a bug or am I doing something wrong?
Bug, I think, could you try the code in the git repo HEAD
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=tree;h=62018e1f720fa11e83879111a4b1b3753b5c25bb;hb=62018e1f720fa11e83879111a4b1b3753b5c25bb
Cheers,
Simon.
Simon Kelley
2015-05-15 20:13:18 UTC
Permalink
Post by Alkis Georgopoulos
Hi Simon, thanks for the patch,
it's a bit better, the client reports the correct proxyDHCP, but then
tries to fetch pxelinux.0 from the wrong TFTP server IP and fails.
Some network dump info: *only* when I'm using iPXE for the client, in
Do you have dhcp-boot configuration. Do they have tags to select the
correct one depending on the efi tag you're using?



Cheers,

Simon.
Post by Alkis Georgopoulos
---------------------------------------------------------------------------
TIME: 2015-05-15 08:43:32.853
IP: 10.161.254.11 (c0:4a:0:2:bc:1e) > 10.161.254.209 (8:0:27:8f:74:ad)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 00000000
SECS: 4
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 10.161.254.209
SIADDR: 192.168.68.1
GIADDR: 0.0.0.0
CHADDR: 08:00:27:8f:74:ad:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: /ltsp/i386/pxelinux.0.
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 54 ( 4) Server identifier 192.168.68.1
OPTION: 60 ( 9) Vendor class identifier PXEClient
OPTION: 97 ( 17) UUID/GUID 00e42f96d0e4e357 ../....W
4da25e75dab1f77f M.^u....
ac .
OPTION: 43 ( 7) Vendor specific info 470480000000ff G......
---------------------------------------------------------------------------
In the iPXE's `config` I don't see 192.168.68.x anywhere though.
On the other hand, when I'm using the NIC's PXE stack, I don't see
192.168.68.1 anywhere in the output of `dhcpdump`!!!
I'm attaching the whole output of `tcpdump` below, maybe your
experienced eyes will pinpoint it.
If it makes any difference, I applied your patch to the Ubuntu's 14.04
dnsmasq version (dnsmasq-base 2.68-1ubuntu0.1), but I can also test with
the git trunk if needed.
Thanks a lot,
Alkis
==================================================
67 or port 68 or port 69 or port 4011 -e -n -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
65535 bytes
09:24:52.784009 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 0, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
"PXEClient:Arch:00000:UNDI:002001"
09:24:52.784016 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 0, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
"PXEClient:Arch:00000:UNDI:002001"
09:24:52.784170 c0:4a:00:02:bc:1e > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 365: (tos 0xc0, ttl 64, id 5393, offset 0, flags
[none], proto UDP (17), length 351)
10.161.254.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 323, xid 0x288f74ad, secs 4, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
file "/ltsp/i386/pxelinux.0"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.161.254.11
Vendor-Class Option 60, length 9: "PXEClient"
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
6.1.3.10.4.0.80.88.69.8.7.128.0.1.10.161.254.11.9.20.128.0.17.66.111.111.116.32.102.114.111.109.32.110.101.116.119.111.114.107.255
09:24:52.786368 00:24:97:f7:d9:06 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 344: (tos 0x0, ttl 255, id 14657, offset 0, flags
[none], proto UDP (17), length 330)
10.161.254.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 302, xid 0x288f74ad, Flags [Broadcast] (0x8000)
Your-IP 10.161.254.208
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.161.254.1
Lease-Time Option 51, length 4: 430603
RN Option 58, length 4: 215301
RB Option 59, length 4: 376777
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 10: "ioa.sch.gr"
Domain-Name-Server Option 6, length 8: 194.63.239.164,194.63.238.4
Default-Gateway Option 3, length 4: 10.161.254.1
09:24:54.811307 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 10.161.254.208
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
Server-ID Option 54, length 4: 10.161.254.1
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
"PXEClient:Arch:00000:UNDI:002001"
09:24:54.811313 08:00:27:8f:74:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none],
proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 08:00:27:8f:74:ad, length 548, xid 0x288f74ad, secs 4, Flags
[Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 10.161.254.208
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
Server-ID Option 54, length 4: 10.161.254.1
0.208.150.47.228.227.228.77.87.162.94.117.218.177.247.127.172
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
"PXEClient:Arch:00000:UNDI:002001"
09:24:54.813302 00:24:97:f7:d9:06 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 344: (tos 0x0, ttl 255, id 14658, offset 0, flags
[none], proto UDP (17), length 330)
10.161.254.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 302, xid 0x288f74ad, Flags [Broadcast] (0x8000)
Your-IP 10.161.254.208
Client-Ethernet-Address 08:00:27:8f:74:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.161.254.1
Lease-Time Option 51, length 4: 432000
RN Option 58, length 4: 216000
RB Option 59, length 4: 378000
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 10: "ioa.sch.gr"
Domain-Name-Server Option 6, length 8: 194.63.239.164,194.63.238.4
Default-Gateway Option 3, length 4: 10.161.254.1
09:24:54.817082 08:00:27:8f:74:ad > 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.208.4011 > 10.161.254.11.4011: [udp sum ok] UDP, length 548
09:24:54.817183 c0:4a:00:02:bc:1e > 08:00:27:8f:74:ad, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 24832, offset 0, flags
[none], proto UDP (17), length 328)
10.161.254.11.4011 > 10.161.254.208.4011: [udp sum ok] UDP, length 300
09:24:55.856377 08:00:27:8f:74:ad > 00:24:97:f7:d9:06, ethertype IPv4
(0x0800), length 80: (tos 0x0, ttl 20, id 3, offset 0, flags [none],
proto UDP (17), length 66)
10.161.254.208.2070 > 192.168.68.1.69: [udp sum ok] 38 RRQ
"/ltsp/i386/pxelinux.0" octet tsize 0
09:25:00.545579 2c:27:d7:dc:2e:66 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 342: (tos 0x0, ttl 128, id 10752, offset 0, flags
[none], proto UDP (17), length 328)
10.161.254.190.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP,
Request from 2c:27:d7:dc:2e:66, length 300, xid 0xb9606c6d, Flags
[Broadcast] (0x8000)
Client-IP 10.161.254.190
Client-Ethernet-Address 2c:27:d7:dc:2e:66
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Inform
Client-ID Option 61, length 7: ether 2c:27:d7:dc:2e:66
Hostname Option 12, length 8: "gymnasio"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope,
Router-Discovery
Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option
Option 252
================================================================
Post by Simon Kelley
Post by Alkis Georgopoulos
Since proxyDHCP mode doesn't yet work for UEFI clients, I'm using the
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
This is with a single NIC, dual IP server (10.161.254.11, 192.168.68.1).
The 192.168.67.1 server IP is only used to PXE boot the UEFI clients.
The problem is that the proxyDHCP clients receive
proxyDHCP server IP = 192.168.68.1
instead of the expected 10.161.254.11.
I.e. I would expect dnsmasq to reply with the server IP that matches the
proxyDHCP subnet, not the other one, which the clients can't reach.
Would that be a bug or am I doing something wrong?
Bug, I think, could you try the code in the git repo HEAD
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=tree;h=62018e1f720fa11e83879111a4b1b3753b5c25bb;hb=62018e1f720fa11e83879111a4b1b3753b5c25bb
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Alkis Georgopoulos
2015-05-16 07:05:16 UTC
Permalink
Post by Simon Kelley
Do you have dhcp-boot configuration. Do they have tags to select the
correct one depending on the efi tag you're using?
Hi Simon, here's my minimal.conf with which I can reproduce the problem:
enable-tftp
tftp-root=/var/lib/tftpboot/
dhcp-option=17,/opt/ltsp/i386
dhcp-match=set:efi,option:client-arch,7
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
dhcp-boot=tag:!efi,ltsp/i386/pxelinux.0
dhcp-boot=tag:efi,ltsp/amd64/bootnetx64.efi
pxe-service=X86PC, "Boot from network", ltsp/i386/pxelinux
pxe-service=BC_EFI,"BC_EFI: Boot from network",ltsp/amd64/bootnetx64

I actually have 2 NICs on the server, I didn't mention the second one
because it was irrelevant, but I do have some new debugging hint so I'm
mentioning it now.
With these IPs, I get the problem:
$ ip -oneline -family inet addr show
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever
preferred_lft forever
2: eth0 inet 10.160.67.10/24 brd 10.160.67.255 scope global eth0\
valid_lft forever preferred_lft forever
3: eth1 inet 10.161.254.11/24 brd 10.161.254.255 scope global eth1\
valid_lft forever preferred_lft forever
3: eth1 inet 192.168.68.1/24 brd 192.168.68.255 scope global eth1\
valid_lft forever preferred_lft forever

The problem is that the non-uefi client tries to fetch pxelinux.0 from
192.168.68.1 instead of from 10.161.254.11.
Everything else (uefi clients etc) works fine.

Now, if I move 192.168.68.1 to my other NIC just as a test, and without
changing anything else at all, the non-uefi client does boot fine:
***@srv1-dide:~$ ip -oneline -family inet addr show
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever
preferred_lft forever
2: eth0 inet 10.160.67.10/24 brd 10.160.67.255 scope global eth0\
valid_lft forever preferred_lft forever
2: eth0 inet 192.168.68.1/24 brd 192.168.68.255 scope global eth0\
valid_lft forever preferred_lft forever
3: eth1 inet 10.161.254.11/24 brd 10.161.254.255 scope global eth1\
valid_lft forever preferred_lft forever

Today (Saturday) the traffic at work was minimal so I was able to
capture a full tcpdump, in case it helps:
http://paste.debian.net/178053/

The problematic client screen is at:
http://paste.debian.net/178055/


I still haven't tested with git-trunk, but of course I have applied your
patch to the Ubuntu 14.04's dnsmasq version.

Thanks,
Alkis
Alkis Georgopoulos
2015-05-16 08:27:45 UTC
Permalink
I just tried with git head, with the same results.


Another debugging hint... I tried commenting out the following line:
#dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h

Meaning that I only had the proxyDHCP range in effect:
dhcp-range=tag:!efi,10.161.254.0,proxy

The client of course booted successfully.

Then I compared the 2 DHCP transactions using `sudo tcpdump -i eth1 port
67 or port 68 or port 69 or port 4011 -e -n -vv`

I couldn't find any differences!
Except for the "id"s, the Lease-time option 51, the RN option 58, and
the RB option 59, everything else was identical!

Since dnsmasq sent the same replies, and the server IPs didn't change, I
don't understand why the client got the correct TFTP IP at the first try
and the wrong IP at the second try... :-/

With the 192.168.68.x range commented out:
http://paste.debian.net/178081/

With the 192.168.68.x range in effect:
http://paste.debian.net/178082/

--
Thanks,
Alkis

(reminding my config:
enable-tftp
tftp-root=/var/lib/tftpboot/
dhcp-option=17,/opt/ltsp/i386
dhcp-match=set:efi,option:client-arch,7
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
dhcp-boot=tag:!efi,ltsp/i386/pxelinux.0
dhcp-boot=tag:efi,ltsp/amd64/bootnetx64.efi
pxe-service=X86PC, "Boot from network", ltsp/i386/pxelinux
pxe-service=BC_EFI,"BC_EFI: Boot from network",ltsp/amd64/bootnetx64

$ ip -oneline -family inet addr show
3: eth1 inet 10.161.254.11/24 brd 10.161.254.255 scope global eth1\
valid_lft forever preferred_lft forever
3: eth1 inet 192.168.68.1/24 brd 192.168.68.255 scope global eth1\
valid_lft forever preferred_lft forever
)
Alkis Georgopoulos
2015-05-16 09:19:10 UTC
Permalink
OK, I managed to pinpoint the difference using another tcpdump command
line (-XX):
$ sudo tcpdump -i eth1 port 67 or port 68 or port 69 or port 4011 -e -n
-vv -XX


1) Without the normal dhcp-range, so that the client boots successfully:

11:51:23.036199 c0:4a:00:02:bc:1e > 3c:07:71:a2:02:e3, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 27064, 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 69b8 0000 4011 fd49 0aa1 fe0b 0aa1 ***@..I......
0x0020: fe95 0fab 0fab 0134 7a4c 0201 0600 72a2 .......4zL....r.
0x0030: 02e3 0004 0000 0000 0000 0aa1 fe95 c0a8 ................
0x0040: 4401 0000 0000 3c07 71a2 02e3 0000 0000 D.....<.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 04c0 ......c.Sc5..6..
0x0120: a844 013c 0950 5845 436c 6965 6e74 6111 .D.<.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 ......


2) Including the normal dhcp-range, so that the client fails:

11:54:45.038754 c0:4a:00:02:bc:1e > 3c:07:71:a2:02:e3, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 57382, 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 e026 0000 4011 86db 0aa1 fe0b 0aa1 .H.&***@.........
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 ......


Search for 192.168.68.1 (=c0.a8.44.01) in the first message, it exists
in 2 offsets, while in the second (=correct) packet it doesn't.

Sorry I couldn't find out how to tell tcpdump or wireshark to decode
that particular packet, wireshark just mentions it's a UDP protocol at
altserviceboot (4011) port.
Simon Kelley
2015-05-19 22:04:35 UTC
Permalink
Hi Alkis,

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.

Cheers,

Simon.
Post by Alkis Georgopoulos
OK, I managed to pinpoint the difference using another tcpdump command
$ sudo tcpdump -i eth1 port 67 or port 68 or port 69 or port 4011 -e -n
-vv -XX
11:51:23.036199 c0:4a:00:02:bc:1e > 3c:07:71:a2:02:e3, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 27064, 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.
0x0020: fe95 0fab 0fab 0134 7a4c 0201 0600 72a2 .......4zL....r.
0x0030: 02e3 0004 0000 0000 0000 0aa1 fe95 c0a8 ................
0x0040: 4401 0000 0000 3c07 71a2 02e3 0000 0000 D.....<.q.......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ...............http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7f8565b94ca52dde31f7688a9f9a0cc611d9dae3.
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 04c0 ......c.Sc5..6..
0x0120: a844 013c 0950 5845 436c 6965 6e74 6111 .D.<.PXEClientahttp://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7f8565b94ca52dde31f7688a9f9a0cc611d9dae3.
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 ......
11:54:45.038754 c0:4a:00:02:bc:1e > 3c:07:71:a2:02:e3, ethertype IPv4
(0x0800), length 342: (tos 0xc0, ttl 64, id 57382, 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.
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..........http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7f8565b94ca52dde31f7688a9f9a0cc611d9dae3..
0x0150: 0000 0000 0000 ......
Search for 192.168.68.1 (=c0.a8.44.01) in the first message, it exists
in 2 offsets, while in the second (=correct) packet it doesn't.
Sorry I couldn't find out how to tell tcpdump or wireshark to decode
that particular packet, wireshark just mentions it's a UDP protocol at
altserviceboot (4011) port.
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Alkis Georgopoulos
2015-05-20 04:24:02 UTC
Permalink
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 ***@..............
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
Post by Alkis Georgopoulos
Post by Simon Kelley
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
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.
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
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.
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
Simon Kelley
2015-05-20 19:21:43 UTC
Permalink
Thanks for staying with this. I just checked in another patch. Is that
any better?


Cheers,

Simon.
Post by Alkis Georgopoulos
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
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.
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
Post by Alkis Georgopoulos
Post by Simon Kelley
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
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.
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
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.
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
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Alkis Georgopoulos
2015-05-21 07:59:55 UTC
Permalink
Post by Simon Kelley
Thanks for staying with this. I just checked in another patch. Is that
any better?
That did the trick! It worked in all the cases that I tried.

Btw if there's any testing that I could do to help in implementing the
proxyDHCP support for UEFI clients, I'd be glad to do it.

Thanks a lot Simon!
Alkis
Simon Kelley
2015-05-21 19:21:08 UTC
Permalink
Post by Alkis Georgopoulos
Post by Simon Kelley
Thanks for staying with this. I just checked in another patch. Is
that any better?
That did the trick! It worked in all the cases that I tried.
Good stuff. Thanks for your help with this.
Post by Alkis Georgopoulos
Btw if there's any testing that I could do to help in implementing
the proxyDHCP support for UEFI clients, I'd be glad to do it.
Thanks. That's on the list to be done after 2.73 is (finally) released.

Simon.
Post by Alkis Georgopoulos
Thanks a lot Simon! Alkis
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...