Im planning to putting a wire to it, thats the only way.
Does it still happen if you stop firewall on openwrt? Just guessing.
The error message suggests that either the Offer packet won't make it to the end device (phone) or the subsequent Request packet is not sent or never reaches the dhcp server.
In the search for the point of failure, tcpdump (opkg install tcpdump-mini) is your friend. Try listening on udp ports 67-68, whether the offer is received on the wireless interface and is relayed to the other interface.
Edit: and yes, if wired connection is an option, go for it and forget all of this...
Can I ask you how to stop the firewall? I "disabled" for all the "interfaces" but I don't know if this is enough.
The strange thing (but again, I'm not at expert at all) is the one client (is an IPcam) sometimes connects to it and receive the right IP address (right in the sense that is the one that I configured in the main router and DHCP server, statically). In this case the IPcam is working fine but, however, the devides (MAC and IP) are not listed by the main router. After some time (10-30 minutes) the connection is lost...
Thanks,
Matteo
Ciao,
root@OpenWrt:~# tcpdump -i wlan0 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:55:21.447047 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:55:21.547408 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:26.185739 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:26.264680 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:28.078538 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:28.107919 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:32.077600 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:32.105480 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:40.077722 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:40.192683 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:56.080586 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:56.165707 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:57:28.080992 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:57:28.118232 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
the MAC address (08:ea:40:47:f5:9d) is the MAC address of the IPcam I'm trying to connect...
If I understand seems ok, isn't it? The request is forwarded to the main router (192.168.1.1 on port 67) and there's even a reply... Isn't it?
Thanks,
Matteo
It even seems that the IP is got correctly!
root@OpenWrt:~# tcpdump -i wlan0 udp port 67 -vv
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:01:41.324015 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308, xid 0x72c9, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 08:ea:40:47:f5:9d (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
MSZ Option 57, length 2: 1500
Parameter-Request Option 55, length 4:
Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
14:01:41.351715 IP (tos 0x0, ttl 64, id 38224, offset 0, flags [none], proto UDP (17), length 328)
192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x72c9, Flags [Broadcast] (0x8000)
Your-IP 192.168.1.90
Server-IP 192.168.1.1
Client-Ethernet-Address 08:ea:40:47:f5:9d (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.1.255
Default-Gateway Option 3, length 4: 192.168.1.1
Domain-Name-Server Option 6, length 8: resolver1.opendns.com,resolver2.opendns.com
Matteo
This means the Offer packet was transmitted from the router (zyxel) to the bridge (netgear). Which is fine, but it's only a part of the story.
I'd try tcpdump on the other bridged interface (possibly br-lan) to see if the same packet is sent towards the client.
If it is, try connecting another device, a laptop perhaps, to see if the dhcp procedure fails with it too, or the camera is the culprit.
If the packet is not being sent over, try my suggested setup above.
- calling
psto list running processes, you should seerelaydrunning without the-Dparameter - in dnsmasq generated config file (
/var/etc/dnsmasq.conf.*) there should be a line like
dhcp-relay=192.168.2.1,192.168.1.1,wlan0
matching your setup - make sure
odhcpdignores dhcpv4 packets, maybe just stop it for the moment (/etc/init.d/odhcpd stop)
Can I ask you how to stop the firewall?
I use /etc/init.d/firewall stop to stop temporarily. But your method likely works too. Either way, iptables -L should only print empty tables.
Hi,
I tried with a second device (my iPhone):
root@OpenWrt:~# tcpdump -i wlan0 udp port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:10:09.188734 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:10:09.239595 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:13.916223 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:13.956923 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:15.805419 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:15.902659 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:19.804511 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:19.896192 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:27.804617 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:27.885297 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:33.894806 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:33.925067 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:35.174317 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:35.258158 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:37.766038 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:37.816299 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:42.738219 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:42.834000 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:43.807408 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:43.857968 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:51.262489 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:51.333249 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
at the beginning there's the camera MAC address, still trying to connect, and when I tried with the phone there's the new mac address.
The strange (to me) is that:
the two devices seems connected and with a good IP (in the case of the camera is even the one I set in the router, even if now I have the doubt that I set as static also when I configured the cam...) but, for example, my iPhone is still saying "no connection" and has 169.254.9.100 as IP...
Thanks,
Matteo
Just to ask: is normal that I cannot set a IPv4 netmask in my br-lan intrerface?
If I set with from LuCI it never ends and says that needs to come back to the backup configuration...
Matteo
For example now is working (without the "new" configuration, but with the standard "relay bridge"...) even if I don't understand why and why, for sure, after few minutes it will stop working...
One symptom (I think) is that the router sees the devices connected to the AP with the MAC of the AT itself:
if you see the MAC 10:da:43:0c:13:3a is present 4 times: 192.168.1.3 is the AP itself, the other 3 are devices connected...
I don't know if it's related but with the original firmware by NetGear the MAC address transmitted to the router was a sort of combination between the AP one and the device one...
Matteo
P.S.: after 1 hours it stopped working. And rebooting the NetGear repeater seems not solving.
Maybe for some reason after sometime the router (i.e. the main DHCP server) recognize the packets as a sort of "hacking" or something similar?
Please. Read again. Try again. Ask when you are not sure.
Have you tried tcpdump on br-lan (or whatever your second interface is called)?
Have you seen matching DHCP packets on both interfaces (wlan0 vs br-lan)?
You have the tools to study the problem at its source, yet you keep guessing from side effects.
Does relayd do what it should be doing? Find that out first.
Good luck
Hi,
you're right. The problem is that I needed it working. So at the end I moved to a "dumb AP", moving it in another room where I have an ethernet plug.
Would be interesting to solve but I needed it to work...
Thanks and sorry,
Matteo
Thanks a lot @kolalok for these instructions. I had trouble making it work myself, until I understand the DHCP on the lan interface needs to be enabled (usual instructions and tutorials from openwrt to setup relay states disabling DHCP on lan interface is required), because the overall configuration changes a bit with your suggestions.
Thanks again!
Hello guys!
I'm using OpenWRT on Archer C7 as a repeater and I wasn't successful in connecting any client, it was only possible to configure IPs manually. Looking for a solution, I arrived here and saw that DHCP on LAN must be enabled, but the recommendation is that it be disabled as with stock firmwares. I'm not good at English, so I don't know if I understand correctly, I turned on DHCP and Voilà. Is this correct?
DHCP should be enabled on main router.
Repeater connects to main router via wifi.
DHCP should be disabled on Repeater.
2 Likes
Really. But, it wasn't connecting to anything before. I enabled and everything connected automatically. Now I turned it off and the connection was kept lOl
Thanks!
In fact there was another mistake. I don't know what happens because I redid the configuration and never saved. I gave up and I'm returning to stock because it takes time and patience with Openwrt. The speed of 2.4 and 5G connections are matching with the stock firmware, but the settings are the points that keep me away from Openwrt
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.