-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
If I've understood the problem correctly, dnsmasq is never even seeing
these packets. If the destination address in the IP-level header is
for a random IP address then the kernel network stack will discard the
packet, even if the link-layer MAC addre
Hi,
argh, embedded system, no space for python, nor Im able to develop
libpcap...
I still hope (cross fingers) dnsmasq can handle this somehow...
For Simon: we tested, dnsmasq is already handling smtng like this
(client correctly routed to different network) and it rightly sends DHCP
NAK+Option M
Hi again Nikita,
Le Sat, 21 Jan 2017 00:19:02 -0800
"Nikita N." a écrit:
> Hi,
> yes indeed, we are facing some kind of "stochastic bug", which happens
> randomly, otherwise that client network driver works usually fine.
> Also yes, that network card is not produced anymore,nor there is any
> bu
Hi,
yes indeed, we are facing some kind of "stochastic bug", which happens
randomly, otherwise that client network driver works usually fine.
Also yes, that network card is not produced anymore,nor there is any bug
support from the producer.
Anyway, too bad dnsmasq cant handle this.
I was infact ho
Hi again Nikita,
Le Fri, 20 Jan 2017 23:37:43 -0800
"Nikita N." a écrit:
> Hi,
> I confirm --dhcp-authoritative works *PERFECTLY* with all other
> clients. Meaning it works when client matches the IP layer address,
> and when Dst: Broadcast (ff:ff:ff:ff:ff:ff) and Src: 0.0.0.0
> (0.0.0.0) and Ds
Hi,
I confirm --dhcp-authoritative works *PERFECTLY* with all other clients.
Meaning it works when client matches the IP layer address, and when Dst:
Broadcast (ff:ff:ff:ff:ff:ff) and Src: 0.0.0.0 (0.0.0.0) and Dst:
255.255.255.255 (255.255.255.255).
Unfortunately my bugged client has IP Src bugged
Hi again Nikita,
Le Fri, 20 Jan 2017 13:24:10 -0800
"Nikita N." a écrit:
> Hi Albert,
> thank you for your answer, but my config already has
> --dhcp-authoritative.
OK, then. Have you tested that it does indeed work? (and you have also
tested that the normal/correct DHCP leasing scenario indeed
Hi Albert,
thank you for your answer, but my config already has
--dhcp-authoritative.
I will try to explain the problem in more details, showing the
Wireshark-style "bugged" frame, popping up on the wire:
-Ethernet II, Src: correct_mac_aa:bb:cc (mac_client), Dst:
correct_gateway_dd:ee:ff (mac_gatew
Sorry I apologize, an important correction: the gateway_ip is also not
correct, also gateway_ip is most of times bugged:
-Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 5.6.7.8
(wrong_gateway_ip)
But still those client DHCP frames pop up on the gateway/DHCP server
network, dnsmasq sees
Le Fri, 20 Jan 2017 11:20:17 -0800
"Nikita N." a écrit:
> Hi,
> I would like to know what is the setting, to force dnsmasq to *ALWAYS*
> answer every wrong/bugged DHCP Request, with a standard DHCP NAK.
> I have a bugged client which randomly (bugged driver) sends DHCP
> Requests with a wrong/bug
Hi,
I would like to know what is the setting, to force dnsmasq to *ALWAYS*
answer every wrong/bugged DHCP Request, with a standard DHCP NAK.
I have a bugged client which randomly (bugged driver) sends DHCP
Requests with a wrong/bugged IP, dnsmasq default behavior is not to
answer nothing: unfortuna
11 matches
Mail list logo
