[Dnsmasq-discuss] Regarding: DHCP server not assigning IP to RTMU86
Kamil
kamil at incmachines.com
Thu Jun 2 12:54:32 UTC 2022
On Mon, May 23, 2022 at 09:06PM +0200, Geert Stappers <stappers at stappers.nl>
wrote:
> On Mon, May 23, 2022 at 08:11:53PM +0200, Kamil wrote:
> > On Wed, May 18, 2022 at 10:14, Geert Stappers via Dnsmasq-discuss wrote:
> > > On Tue, May 17, 2022 at 11:16:28AM +0200, Kamil via Dnsmasq-discuss
> wrote:
> > > > On Mon, May 16, 2022 at 04:56:25PM +0100, Simon Kelley wrote:
> > > > >
> > > > > What does the output of
> > > > >
> > > > > iptables -L
> > > > >
> > > > > look like?
> > > > >
> > > > # iptables -L
> > > > Chain INPUT (policy ACCEPT)
> > > > target prot opt source destination
> > > >
> > > > Chain FORWARD (policy ACCEPT)
> > > > target prot opt source destination
> > > >
> > > > Chain OUTPUT (policy ACCEPT)
> > > > target prot opt source destination
> > >
> > > Acknowledge on those firewall (empty) rules.
> > >
> >
> > Dear Geert,
> >
> > Is there something I should change?
> >
>
Dear Geert,
>
> Not on the firewall rules.
>
> } Is there something I should change?
>
> Yes
>
> > | # tcpdump -i eth0
>
> Add a filter (stop flooding us )
> a filter to try
> ether host 38:XX:XX:XX:XX:c3 or port bootps
> So the command line with filter
> tcpdump -i eth0 ether host 38:XX:XX:XX:XX:c3 or port bootps
>
>
> Use another character as >
> example given |
> so another character as what email client use for "previous text"
>
Of course!
I'm sorry for flooding previously.
>
> Example
> > | tcpdump: verbose output suppressed, use -v[v]... for full protocol
> decode
> > | listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144
> bytes
>
Here is the filtered tcpdump:
| # tcpdump -i eth0 port bootps
| tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
| listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144
bytes
|
| [All devices unplugged. Plugging Device X]
|
| 14:16:53.674021 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:16:59.174249 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:17:02.179593 IP 192.168.6.1.bootps > 25250484.bootpc: BOOTP/DHCP,
Reply, length 300
| 14:17:02.180817 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:17:02.198161 IP 192.168.6.1.bootps > 25250484.bootpc: BOOTP/DHCP,
Reply, length 300
|
| [Unplugging Device X]
| [Unplugged]
| [Plugging RTMU86]
|
| 14:17:41.901105 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:17:44.978012 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:18:05.667274 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:18:08.747191 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:18:29.659678 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:18:32.737700 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
|
| [Unplugging RTMU86]
| [Unplugged RTMU86]
| [Plugging Device X]
|
| 14:19:50.276363 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:19:52.686176 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:19:56.186461 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:19:56.187331 IP 192.168.6.1.bootps > 25250484.bootpc: BOOTP/DHCP,
Reply, length 300
| 14:19:56.188564 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:19:56.202561 IP 192.168.6.1.bootps > 25250484.bootpc: BOOTP/DHCP,
Reply, length 300
Moreover - I've tried isc-dhcp-server with minimal config (without
"authorative" flag):
| subnet 192.168.6.0 netmask 255.255.255.0 {
| interface eth0;
| range 192.168.6.11 192.168.6.20;
| option subnet-mask 255.255.255.0;
| option routers 192.168.6.1;
| }
And the result of filtered tcpdump is as follows:
| # tcpdump -i eth0 port bootps
| tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
| listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144
bytes
|
| [All devices unplugged. Plugging Device X]
|
| 14:29:07.305369 IP 192.168.6.11.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:29:08.306388 IP 0.0.0.0.bootps > 192.168.6.11.bootpc: BOOTP/DHCP,
Reply, length 300
| 14:29:08.307842 IP 192.168.6.11.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 38:XX:XX:XX:XX:c3 (oui Unknown), length 548
| 14:29:08.308360 IP 0.0.0.0.bootps > 192.168.6.11.bootpc: BOOTP/DHCP,
Reply, length 300
|
|
| [Unplugging Device X]
| [Unplugged]
| [Plugging RTMU86]
|
| 14:30:09.646491 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:30:10.647624 IP 0.0.0.0.bootps > 192.168.6.12.bootpc: BOOTP/DHCP,
Reply, length 300
| 14:30:10.686487 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:ZZ:ZZ:ZZ:ZZ:1c (oui Unknown), length 300
| 14:30:10.702470 IP 0.0.0.0.bootps > 192.168.6.12.bootpc: BOOTP/DHCP,
Reply, length 300
So IP was assigned to the RTMU86 in the same maner as for Device X
Kind regards,
Kamil
>
> > > ....
> > >
> > > [Done]
> >
> > Syslog:
> > > ...
> > > Done
> >
> > As you can see - Device X got its IP assigned every time.
>
> No, because I have other stuff to look after.
> No, because I have other stuff to see at.
>
>
> > I have absolutely no idea why RTMU86 is not working...
> >
> >
> > > Start with analyzing the working configuration.
> > >
> > What information about the network could I provide?
> >
> >
> >
> > >
> > > Groeten
> > > Geert Stappers
> > >
> > > P.S. @Kamil: Your email client doesn't add
> > > On <timestamp>, <person> wrote:
> > > line on top of your responses.
> > >
> >
> > It should work now
>
> Yes, it did.
> Thanks for fixing it.
>
>
> > >
> > > P.S. @all: Please avoid obfuscation of what you send.
> > > (Please do not mangle MAC addresses)
> > >
> >
> > I'm sorry, I'm obligated to not publish this data
> >
>
> I feel sorry for you (in your current situation).
>
>
>
> Groeten
> Geert Stappers
> No hard feelings
> (My younger version also encountered unawareness first hand)
> --
> Silence is hard to parse
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220602/9e3b21ea/attachment.htm>
More information about the Dnsmasq-discuss
mailing list