SCP and name resolution

Installing and Using OpenWrt
1

hello,
long story made short. I have a openwrt router and an openwrt dumb AP. Trying to get hostnames also on the AP status page. So i created a inotify based init script on the router that copies dhcp.leases to the ap every time it is changed.
The copy is made with scp with key auth.

The SCP command from CLI works perfectly

scp -i /root/.ssh/AccessPointSSH /tmp/dhcp.leases root@accesspoint.lan:/tmp/dhcp.leases

the problem is that when it is called inside the inotifywait it sources this kind of error

Connect failed: Error resolving 'accesspoint.lan' port '22'. Name does not resolve

clearly i have no dns problems at all resolving the accesspoint ip, so i'm just wondering what is there different when run insida an inotify wait..

the script code is as easy as this

 1 #!/bin/sh
 2 inotifywait -m /tmp/dhcp.leases -e delete,close_write,move | 
 3  while read action; do
 4   logger "DHCP Leases event: $action. Updating AP"
 5   scp -i /root/.ssh/AccessPointSSH /tmp/dhcp.leases root@accesspoint.lan:/tmp/dhcp.leases
 6  done

thanks

2

what is the output of:

nslookup accesspoint.lan

(from the same device that is running the scp command)

1 Like
3 
root@RUTTO:~# nslookup accesspoint.lan
Server:         127.0.0.1
Address:        127.0.0.1:53

Name:   accesspoint.lan
Address: 192.168.1.2

Non-authoritative answer:

my point is that running the command "simply" has 100% success, what is different when letting it to be run under an inotify?

4

Great.. I just wanted to verify that DNS was indeed resolving properly in general with a direct test.

I don't know why the inotify wrapped command specifically is failing, though... hopefully someone else can chime in about that.

5

Just for the course of debugging, what happens when you call ping, nslookup and the others from within your script?

1 Like
6

yes i had just tried (for pure debugging) and it's amazing, it's not resolving the name with the local name server, it's asking to the dns server of the internet connection
this doesn't make any sense

root@RUTTO:~# /etc/config/inotifyDHCP.sh 
Setting up watches.
Watches established.
DHCP Leases event: /tmp/dhcp.leases CLOSE_WRITE,CLOSE. Updating AP
Server:         2001:4860:4860::8888
Address:        [2001:4860:4860::8888]:53

** server can't find accesspoint.lan: NXDOMAIN

** server can't find accesspoint.lan: NXDOMAIN


/usr/bin/dbclient: Connection to root@accesspoint.lan:22 exited: Connect failed: Error resolving 'accesspoint.lan' port '22'. Name does not resolve
lost connection
8

i tried also with different script style (not using pipes, just while - do) and when i use inotifywait it breaks
this is a total nonsense an honestly i have no idea how to debug further.
ideas?
i also tried updatint to 24.10-rc4 but the issue i the same..

9

i ended up using the certificate to log to the ip address and not the dns name.. this keeps being a nonsense..

10

The DHCP server changes dhcp.leases, and triggers the DNS server to cope with that. I can imagine the DNS server will be down for a short moment because of that. Your inotifywait helps to sync on that short moment.

11

this is a good point! should i try with a simple sleep inside the pipe?
(not at home atm :))

12

I think so.

13

If the issue is in fact a blip in DNS, perhaps modify your script to lookup the address of accesspoint.lan in advance and assign to a variable. Something like

#!/bin/sh
get_ip() { nslookup accespoint.lan|awk '/^Address: / { print $2 }' | tail -n1
}
#IP to variable
AP_IP=$(get_ip)
 inotifywait -m /tmp/dhcp.leases -e delete,close_write,move | 
 while read action; do
 logger "DHCP Leases event: $action. Updating AP"
 scp -i /root/.ssh/AccessPointSSH /tmp/dhcp.leases root@$AP_IP:/tmp/dhcp.leases
done

@pattagghiu

14

i'm not in doubt about the ip of the AP (that is fixed), it's a matter of ssh key connected to the hostname and not the ip, so resolving it before che SCP and using the ip is the same that using the fixed ip by itself..
i was curious about the "blip", as you called it, but it seems inside a pipe.. sleep does not sleep lol :slight_smile:
am i missing something very stupid (again)?