Flag --dhcp-http-ipxe-script-prepend-mac=false is ignored and MAC address is still prepended in TFTP URL

[bvelica]

Expected Behaviour

When the --dhcp-http-ipxe-script-prepend-mac=false flag is used with the smee service, the MAC address should not be prepended to the TFTP URL provided in the DHCP response. The expected URL format would be:
tftp://1.1.1.1:69/undionly.kpxe

Current Behaviour

Despite setting the flag --dhcp-http-ipxe-script-prepend-mac=false, the MAC address is still prepended to the TFTP URL in the DHCP response. The TFTP URL format that is being sent is:
tftp://1.1.1.1:69/02:01:48:xx:xx:xx/undionly.kpxe

Logs from smee confirm that the DHCP response is still including the MAC address:
{"level":"error","ts":1729151733.3863502,"logger":"github.com/tinkerbell/ipxedust","caller":"itftp/itftp.go:106","msg":"file serve failed","service":"github.com/tinkerbell/smee","event":"get","filename":"undionly.kpxe","uri":"02:01:48:xx:xx:xx/undionly.kpxe","client":{"IP":"10.7.3.3","Port":64297,"Zone":""},"macFromURI":"02:01:48:xx:xx:xx","b":0,"contentSize":95896,"error":"Channel timeout: 10.7.3.3:64297","stacktrace":"github.com/tinkerbell/ipxedust/itftp.Handler.HandleRead\n\t/home/runner/go/pkg/mod/github.com/tinkerbell/ipxedust@v0.0.0-20231215220341-a535c5deb47a/itftp/itftp.go:106\ngithub.com/pin/tftp/v3.(*Server).handlePacket.func2\n\t/home/runner/go/pkg/mod/github.com/pin/tftp/v3@v3.1.0/server.go:455"} {"level":"info","ts":1729151742.3133204,"caller":"reservation/handler.go:86","msg":"received DHCP packet","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"DISCOVER"} {"level":"info","ts":1729151742.313472,"caller":"reservation/handler.go:141","msg":"sent DHCP response","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"OFFER","bootFileName":"tftp://1.1.1.1:69/02:01:48:xx:xx:xx/undionly.kpxe","nextServer":"1.1.1.1","ipAddress":"10.7.3.3","destination":"255.255.255.255:68"} {"level":"info","ts":1729151743.3542678,"caller":"reservation/handler.go:86","msg":"received DHCP packet","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"DISCOVER"} {"level":"info","ts":1729151743.3544154,"caller":"reservation/handler.go:141","msg":"sent DHCP response","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"OFFER","bootFileName":"tftp://1.1.1.1:69/02:01:48:xx:xx:xx/undionly.kpxe","nextServer":"1.1.1.1","ipAddress":"10.7.3.3","destination":"255.255.255.255:68"} {"level":"info","ts":1729151745.4252472,"caller":"reservation/handler.go:101","msg":"received DHCP packet","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"REQUEST"} {"level":"info","ts":1729151745.425403,"caller":"reservation/handler.go:141","msg":"sent DHCP response","mac":"02:01:48:xx:xx:xx","xid":"0xce4d806d","interface":"ens7","type":"ACK","bootFileName":"tftp://1.1.1.1:69/02:01:48:xx:xx:xx/undionly.kpxe","nextServer":"1.1.1.1","ipAddress":"10.7.3.3","destination":"255.255.255.255:68"}

Possible Solution

Don't have one

Steps to Reproduce (for bugs)

1. Start smee as a standalone app (after build from go) with the following configuration:
   ./smee \ --log-level=debug \ --dhcp-http-ipxe-script-prepend-mac=false \ --dhcp-ip-for-packet=10.7.1.1 \ --tftp-addr=0.0.0.0:69 \ --tftp-enabled=true \ --syslog-enabled=true

If running smee in a kube pod this is the yaml used to deploy the pod (i used both for testing this issue)
`apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"deployment.kubernetes.io/revision":"4","meta.helm.sh/release-name":"tink-stack","meta.helm.sh/release-namespace":"tink-system"},"labels":{"app":"smee","app.kubernetes.io/managed-by":"Helm"},"name":"smee","namespace":"tink-system"},"spec":{"progressDeadlineSeconds":600,"replicas":1,"revisionHistoryLimit":10,"selector":{"matchLabels":{"app":"smee","stack":"tinkerbell"}},"strategy":{"rollingUpdate":{"maxSurge":"25%","maxUnavailable":"25%"},"type":"RollingUpdate"},"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt":"2024-10-16T11:55:42Z"},"labels":{"app":"smee","stack":"tinkerbell"}},"spec":{"containers":[{"args":["-log-level=debug","-backend-kube-namespace=tink-system","-dhcp-addr=0.0.0.0:67","-dhcp-enabled=true","-dhcp-http-ipxe-binary-url=http://1.1.1.1:7171/ipxe","-dhcp-http-ipxe-script-url=http://1.1.1.1:7171/auto.ipxe","-dhcp-http-ipxe-script-prepend-mac=false","-dhcp-ip-for-packet=1.1.1.1","-dhcp-syslog-ip=1.1.1.1","-dhcp-tftp-ip=1.1.1.1:69","-extra-kernel-args=tink_worker_image=quay.io/tinkerbell/tink-worker:v0.10.0","-http-addr=0.0.0.0:7171","-http-ipxe-binary-enabled=true","-http-ipxe-script-enabled=true","-osie-url=http://1.1.1.1:8080","-tink-server=1.1.1.1:42113","-tink-server-tls=false","-trusted-proxies=192.168.0.0/24","-syslog-addr=0.0.0.0:514","-syslog-enabled=true","-ipxe-script-patch=","-tftp-addr=0.0.0.0:69","-tftp-enabled=true","-tftp-timeout=10s"],"image":"quay.io/tinkerbell/smee:v0.11.0","imagePullPolicy":"IfNotPresent","name":"smee","resources":{"limits":{"cpu":"500m","memory":"128Mi"},"requests":{"cpu":"10m","memory":"64Mi"}}}],"dnsPolicy":"ClusterFirst","hostNetwork":true,"restartPolicy":"Always","schedulerName":"default-scheduler","serviceAccount":"smee","serviceAccountName":"smee","terminationGracePeriodSeconds":30}}}}
meta.helm.sh/release-name: tink-stack
meta.helm.sh/release-namespace: tink-system
creationTimestamp: "2024-10-16T15:05:46Z"
generation: 1
labels:
app: smee
app.kubernetes.io/managed-by: Helm
name: smee
namespace: tink-system
resourceVersion: "486982"
uid: 6da8ac29-616b-4f64-99da-f84522f824af
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: smee
stack: tinkerbell
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
annotations:
kubectl.kubernetes.io/restartedAt: "2024-10-16T11:55:42Z"
creationTimestamp: null
labels:
app: smee
stack: tinkerbell
spec:
containers:
- args:
- -log-level=debug
- -backend-kube-namespace=tink-system
- -dhcp-addr=0.0.0.0:67
- -dhcp-enabled=true
- -dhcp-http-ipxe-binary-url=http://1.1.1.1:7171/ipxe
- -dhcp-http-ipxe-script-url=http://1.1.1.1:7171/auto.ipxe
- -dhcp-http-ipxe-script-prepend-mac=false
- -dhcp-ip-for-packet=1.1.1.1
- -dhcp-syslog-ip=1.1.1.1
- -dhcp-tftp-ip=1.1.1.1:69
- -extra-kernel-args=tink_worker_image=quay.io/tinkerbell/tink-worker:v0.10.0
- -http-addr=0.0.0.0:7171
- -http-ipxe-binary-enabled=true
- -http-ipxe-script-enabled=true
- -osie-url=http://1.1.1.1:8080
- -tink-server=1.1.1.1:42113
- -tink-server-tls=false
- -trusted-proxies=192.168.0.0/24
- -syslog-addr=0.0.0.0:514
- -syslog-enabled=true
- -ipxe-script-patch=
- -tftp-addr=0.0.0.0:69
- -tftp-enabled=true
- -tftp-timeout=10s
image: quay.io/tinkerbell/smee:v0.11.0
imagePullPolicy: IfNotPresent
name: smee
resources:
limits:
cpu: 500m
memory: 128Mi
requests:
cpu: 10m
memory: 64Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
hostNetwork: true
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: smee
serviceAccountName: smee
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:

• lastTransitionTime: "2024-10-16T15:05:46Z"
  lastUpdateTime: "2024-10-16T15:05:47Z"
  message: ReplicaSet "smee-7694c856fb" has successfully progressed.
  reason: NewReplicaSetAvailable
  status: "True"
  type: Progressing
• lastTransitionTime: "2024-10-16T15:07:07Z"
  lastUpdateTime: "2024-10-16T15:07:07Z"
  message: Deployment has minimum availability.
  reason: MinimumReplicasAvailable
  status: "True"
  type: Available
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1`

3. Start a client with PXE boot and look for the logs
4. The TFTP server still has the client MAC addredss in the URL

Context

This issue is affecting my PXE boot process by serving a URL that prepends the MAC address, which is not required in my use case. This leads to complications in managing TFTP boot files and provisioning workflows as the client receives a URL format that isn't expected.

Your Environment

• Operating System: Ubuntu 20.04
• Tinkerbell Stack Deployment: Running on a Kubernetes cluster using k3s.
• Hardware: Testing on a server with IP 1.1.1.1 and MAC 02:01:48:xx:xx:xx. (IP and MAC address I don't think they are relevant since I tested with one client. Other clients were powered off.)
• smee Version: v0.11.0, built from source following the official docs.

[jacobweinstock]

Hey @bvelica , let me see if i understand correctly. You want to use Smee for DHCP but not for serving iPXE binaries or the iPXE script?

[bvelica]

Hi,

No, on my testing the flag "--dhcp-http-ipxe-script-prepend-mac=false" does not remove the MAC address from the PCE URL served to the client, so this URL "bootFileName":"tftp://1.1.1.1:69/02:01:48:xx:xx:xx/undionly.kpxe" still has the MAC address in the URL - this MAC address 02:01:48:xx:xx:xx

Or I did something wrong...

Thank you for replying on this.

[jacobweinstock]

Hey @bvelica , thanks for the clarification. It sounds like you're wanting a bring your own TFTP server solution and as you've seen we don't currently support that. As you've found the --dhcp-http-ipxe-script-prepend-mac flag is just for the HTTP auto.ipxe script.

Mind elaborating a bit more on your setup and use case?

[naishi001]

There is a significant demand for a custom TFTP solution, as many users wish to customize their own BIOS files. It would be beneficial to support this capability.

[jacobweinstock]

Hey @naishi001 , thanks for commenting here. Mind expanding/clarifying what you mean by BIOS files and your specific use case?