Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

2017-01-21 Thread Nikita N. 
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 Message="wrong network".
*BUT ONLY* when the frames comes with 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).
When Dst mac is not Bcast and/or Src/Dst ip is not Bcast, then dnsmasq
just keeps silent... instead we would like dnsmasq answers NAK.
Hope that clarifies, thanks
-- 
  Nikita N.
  niki...@operamail.com


On Sat, Jan 21, 2017, at 12:37 AM, Albert ARIBAUD wrote:
> 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
> > bug support from the producer.
> > Anyway, too bad dnsmasq cant handle this.
> > I was infact hoping dnsmasq would handle this too, because it is very
> > similar to the cases when a client changes network (routed
> > correctly,no bug) when dnsmasq already answers such cases with a
> > NAK+Message=wrong network.
> > 
> > Otherwise, the last resource I have (beside reboot) is forging a fake
> > DHCP NAK with some hacker net tool... it feels awful even just typing
> > isn it... :P
> > Albert thanks, do you know of such specific alternate "standalone
> > daemon which would spy on the DHCP traffic" you can suggest me (under
> > linux of course)?
> > Or an easy net tool to easily forge fake UDP frames you can suggest?
> > Thanks
> 
> I assume you mean you don't want to actually code such a daemon in a
> compilable language such as C, and are instead looking for something to
> just install and configure without too much hassle?
> 
> Then there is scapy, a Python swiss-army-knife network application. Its
> the man page says it can replace "hping, parts of nmap, arpspoof,
> arp-sk, arping, tcpdump, tshark, p0f, ..."
> 
> See http://www.secdev.org/projects/scapy/demo.html for an introduction.
> It shows interactive uses, but this being Python, scapy is scriptable.
> It is also testable: you can feed it a pcap file and have it output to
> a pcap file too. It knows DHCP at least to some point.
> 
> You should quite probably be able to write a script that recognizes
> DHCP REQUESTs with mismatching IP layer and DHCP layer IPv4 addresses,
> and craft the corresponding DHCP NAKs.
> 
> If, however, resources are scarce (e.g., in an embedded product), then
> maybe you would be better off developing a C language daemon (possibly
> based on libpcap if this library is already present on the DHCP server
> marchine).
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - A fast, anti-spam email service.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

2017-01-21 Thread Albert ARIBAUD 
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
> bug support from the producer.
> Anyway, too bad dnsmasq cant handle this.
> I was infact hoping dnsmasq would handle this too, because it is very
> similar to the cases when a client changes network (routed
> correctly,no bug) when dnsmasq already answers such cases with a
> NAK+Message=wrong network.
> 
> Otherwise, the last resource I have (beside reboot) is forging a fake
> DHCP NAK with some hacker net tool... it feels awful even just typing
> isn it... :P
> Albert thanks, do you know of such specific alternate "standalone
> daemon which would spy on the DHCP traffic" you can suggest me (under
> linux of course)?
> Or an easy net tool to easily forge fake UDP frames you can suggest?
> Thanks

I assume you mean you don't want to actually code such a daemon in a
compilable language such as C, and are instead looking for something to
just install and configure without too much hassle?

Then there is scapy, a Python swiss-army-knife network application. Its
the man page says it can replace "hping, parts of nmap, arpspoof,
arp-sk, arping, tcpdump, tshark, p0f, ..."

See http://www.secdev.org/projects/scapy/demo.html for an introduction.
It shows interactive uses, but this being Python, scapy is scriptable.
It is also testable: you can feed it a pcap file and have it output to
a pcap file too. It knows DHCP at least to some point.

You should quite probably be able to write a script that recognizes
DHCP REQUESTs with mismatching IP layer and DHCP layer IPv4 addresses,
and craft the corresponding DHCP NAKs.

If, however, resources are scarce (e.g., in an embedded product), then
maybe you would be better off developing a C language daemon (possibly
based on libpcap if this library is already present on the DHCP server
marchine).

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

2017-01-21 Thread Nikita N. 
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 hoping dnsmasq would handle this too, because it is very
similar to the cases when a client changes network (routed correctly,no
bug) when dnsmasq already answers such cases with a NAK+Message=wrong
network.

Otherwise, the last resource I have (beside reboot) is forging a fake
DHCP NAK with some hacker net tool... it feels awful even just typing
isn it... :P
Albert thanks, do you know of such specific alternate "standalone daemon
which would spy on the DHCP traffic" you can suggest me (under linux of
course)?
Or an easy net tool to easily forge fake UDP frames you can suggest?
Thanks

-- 
  Nikita N.
  niki...@operamail.com


On Fri, Jan 20, 2017, at 11:58 PM, Albert ARIBAUD wrote:
> 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 Dst: 255.255.255.255 (255.255.255.255).
> > Unfortunately my bugged client has IP Src bugged, and IP Dst gateway
> > bugged.
> 
> OK, then , I guess the answer to my question "And it always matches the
> IP layer address?" is "No", even though the example frame you gave had
> the IP layer and DHCP layer IP adresses matching. I suspect this is not
> a valid DHCP fame, but I could not find an explicit requirement in the
> DHCP RFC about IP and DHCP layer client IP addresses having to match.
> 
> It may be, tough, that dnsmasq considers the frame dubious because of
> the IP mispatch, and refrains from processing it at all.
> 
> > No matter that, I see those DHCP request frames in the server network
> > where I run dnsmasq (because my net conf is so), so also dnsmasq sees
> > them.
> 
> (I had no doubt that dnsmasq was seeing these frames.)
> 
> > I believe the option I'm looking for is smtng like: if a UDP frame
> > with Dst Port: 67 comes from Src: macX, and is *NOT*
> > protocol/standard valid, then dnsmasq sends a DHCP NAK with Dst: macX
> > (e.g. similar to the different cases when dnsmasq sends NAK with
> > option Message wrong network, whatever)
> > Is that possible?
> 
> Everything is "possible". If by "possible" you mean "by just setting an
> option", then answer is no; if you mean "is it ok if I write a patch
> for this", nobody can (or should) prevent you from doing so; if you
> mean "... and get this patch integrated in mainline dnsmasq", then only
> Simon Kelley might tell. AFAIU, you are requesting a behavior not
> explicitly specified in the DHCP RFC in order to match an out-of-RFC
> client behavior; this may or may not be accepted by Simon.
> 
> I personally would not be in favor of adding such a feature to dnsmasq,
> as it adds very specific source code, adds complexity, and affects
> maintenability, for a situation which is apparently rare and caused
> by a blatant bug in a not-widely-found third party client; I personally
> would suggest, in order of preference
> 
>   i) to fix the buggy client, although I  suspect that this
>  is not an option in your case), or
> 
>   ii) to keep dnsmasq unmodified, keep it running in
>   dhcp-authoritative mode, and run an additional, standalone
>   daemon which would spy on the DHCP traffic, specifically
>   recognize the buggy client DHCPREQUEST frames and send a
>   crafted DHCPNAK on its own. This would never clash with
>   dnsmasq since only one of the two daemons would ever send
>   a DHCPNAK message. And if ever dnsmasq started sending
>   DHCPNAKs to your buggy client, you'd just have to remove
>   the custom daemon.
> 
> But as I wrote, the answer to your question is now in Simon's hands.
> 
> > Thanks
> 
> NP!
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - Email service worth paying for. Try it for free


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

2017-01-21 Thread Nikita N. 
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, and IP Dst gateway
bugged.
No matter that, I see those DHCP request frames in the server network
where I run dnsmasq (because my net conf is so), so also dnsmasq sees
them.
I believe the option I'm looking for is smtng like: if a UDP frame with
Dst Port: 67 comes from Src: macX, and is *NOT* protocol/standard valid,
then dnsmasq sends a DHCP NAK with Dst: macX (e.g. similar to the
different cases when dnsmasq sends NAK with option Message wrong
network, whatever)
Is that possible?
Thanks
-- 
  Nikita N.
  niki...@operamail.com


On Fri, Jan 20, 2017, at 02:55 PM, Albert ARIBAUD wrote:
> 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 works?
> 
> > 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_gateway)
> > -Internet Protocol Version 4, Src: 1.2.3.4 (1.2.3.4), Dst: 10.0.0.1
> > (correct_gateway_ip)
> > -User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
> > -Bootstrap Protocol (Request)
> > --Client IP address: 1.2.3.4 (1.2.3.4)
> > --Your (client) IP address: 1.2.3.4 (1.2.3.4)
> > --Client MAC address: correct_mac_aa:bb:cc (mac_client)
> > --Option: (53) DHCP Message Type (Request)
> > --Option: (61) Client identifier
> > --Option: (60) Vendor class identifier
> > --Option: (55) Parameter Request List
> > ---Parameter Request List Item: (1) Subnet Mask
> > ---Parameter Request List Item: (121) Classless Static Route
> > ---Parameter Request List Item: (33) Static Route
> > ---Parameter Request List Item: (3) Router
> > ---Parameter Request List Item: (6) Domain Name Server
> > ---Parameter Request List Item: (15) Domain Name
> > ---Parameter Request List Item: (28) Broadcast Address
> > ---Parameter Request List Item: (51) IP Address Lease Time
> > ---Parameter Request List Item: (58) Renewal Time Value
> > ---Parameter Request List Item: (59) Rebinding Time Value
> > ---Parameter Request List Item: (119) Domain Search
> > --Option: (255) End
> > 
> > The mac correct_mac is the correct mac of the bugged client, that is
> > always correct.
> > The ip 1.2.3.4 is the bug, this value changes randomly time by time
> > (no workaround), it can be anything: but luckily is coherent (same)
> > in the relevant positions of the single DHCP frame.
> 
> And it always matches the IP layer address? Because if it does, then
> the frame is valid; that is what a machine moved from one subnet to
> another might do, and a DHCP server (dnsmasq or other) is designed to
> handle this.
> 
> > Finally, as you notice, the relevant "Option: (50) Requested IP
> > Address" is always missing.
> 
> IIUC option 50 is not required, so I don't think its absence causes
> dnsmasq to skip answering this.
> 
> > What I need is: dnsmasq sends a DHCP Answer NAK with
> > Dst:correct_mac_aa:bb:cc (and possibly also ip Dst:1.2.3.4 whatever)
> > How can I set this?
> 
> That's what --dhcp-authoritative is about. Hence my suggestion to
> test with a working client that the server is indeed running in
> authoritative mode.
> 
> > Thanks
> 
> Amicalement,
> -- 
> Albert.

-- 
http://www.fastmail.com - mmm... Fastmail...


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss