Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK
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." <niki...@operamail.com> 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
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." <niki...@operamail.com> 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
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." <niki...@operamail.com> 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
Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK
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_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. Finally, as you notice, the relevant "Option: (50) Requested IP Address" is always missing. 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? Thanks -- Nikita N. niki...@operamail.com On Fri, Jan 20, 2017, at 12:25 PM, Albert ARIBAUD wrote: > Le Fri, 20 Jan 2017 11:20:17 -0800 > "Nikita N." <niki...@operamail.com> 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/bugged IP, dnsmasq default behavior is not to > > answer nothing: unfortunately when that happens the client hangs > > forever waiting for the DHCP answer (only workaround is reboot). > > Now, I want to force dnsmasq to answer NAK to every wrong/bugged DHCP > > request incoming (instead of keeping silent). > > Thanks. > > Hi Nikita, > > As per 'man dnsmasq', what you want is probably --dhcp-authoritative. > The man page says this about it: > > Should be set when dnsmasq is definitely the only DHCP server > on a network. For DHCPv4, it changes the behaviour from strict > RFC compliance so that DHCP requests on unknown leases from > unknown hosts are not ignored. This allows new hosts to > get a lease without a tedious timeout under all > circumstances. It also allows dnsmasq to rebuild its lease > database without each client needing to reacquire a lease, if > the database is lost. For DHCPv6 it sets the priority in > replies to 255 (the maximum) instead of 0 (the minimum). > > Note however that this will do what you want or not, depending on what > you mean by 'bugged'. If you mean "a request that could be legitimate > in some circumstances but is not valid here", then --dhcp-authoritative > will do the job. If you mean "a request which may have been randomly > damaged" then there's no way dnsmasq will catch all these. > > Amicalement, > -- > Albert. -- http://www.fastmail.com - The way an email service should be ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnsmasq always answer dhcp NAK
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: unfortunately when that happens the client hangs forever waiting for the DHCP answer (only workaround is reboot). Now, I want to force dnsmasq to answer NAK to every wrong/bugged DHCP request incoming (instead of keeping silent). Thanks. -- Nikita N. niki...@operamail.com -- http://www.fastmail.com - Does exactly what it says on the tin ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS - ICMP - Destination unreachable (Port unreachable) ?
Hi Albert, thank you for your hints, I'm going to setup as you suggest, and see what happens. Anyway, you wrote something very interesting here: a DNS answer is always through IPv4, either over UDP or TCP. TCP?? :) Do you mean, I can send a TCP frame from port 53 to Dnsmasq with a DNS query? And I will receive a TCP frame from Dnsmasq with the DNS query response? -- Nikita N. niki...@operamail.com On Wed, May 13, 2015, at 12:43 AM, Albert ARIBAUD wrote: Hi Nikita, Le Tue, 12 May 2015 23:49:55 -0700, Nikita N. niki...@operamail.com a écrit : Hi Simon, thanks for the bet! :) So if I'm understanding correctly, it is nothing related to Dnsmasq, right? Right. By your opinion, what is the purpose of such a ICMP/UDP frame sent from src port 53? Is that some kind of alternate DNS mechanism? Is that anything standard behavior? It is standard behaviour. ICMP(v4) is used as a signalling mechanism alongside IPv4 (e.g. for 'unreachable host' notifications) When the answer comes back, there's nothing listening on the destination port I always see those ICMP at gateway side, so I guess the gateway must have received at least that answer back. Is that answer back supposed to be a simple UDP frame or another ICMP frame? ICMP is never used for application data; a DNS answer is always through IPv4, either over UDP or TCP. Also, client and gateway are on different machines, loopback is not possible, why I can't see neither the UDP/ICMP answer back, nor the query? How would I set Wireshark, to sniff out those 2 mysterious UDP frame? Ideally, running Wireshark on a dual-Ethernet machine inserted on the client's wire. In less ideal cases, run an instance of wireshark or tcpdump on the client and one on the server, capture to file with both, then fire two wireshark instances on any machine, have each one load a capture and compare them visually. Amicalement, -- Albert. -- http://www.fastmail.com - The professional email service ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS - ICMP - Destination unreachable (Port unreachable) ?
Hi Simon, thanks for the bet! :) So if I'm understanding correctly, it is nothing related to Dnsmasq, right? By your opinion, what is the purpose of such a ICMP/UDP frame sent from src port 53? Is that some kind of alternate DNS mechanism? Is that anything standard behavior? When the answer comes back, there's nothing listening on the destination port I always see those ICMP at gateway side, so I guess the gateway must have received at least that answer back. Is that answer back supposed to be a simple UDP frame or another ICMP frame? Also, client and gateway are on different machines, loopback is not possible, why I can't see neither the UDP/ICMP answer back, nor the query? How would I set Wireshark, to sniff out those 2 mysterious UDP frame? -- Nikita N. niki...@operamail.com On Tue, May 12, 2015, at 02:22 PM, Simon Kelley wrote: The most likely reason is that something opens a UDP port and sends the query, and then gives up, or gets an answer from somewhere else, and closes the UDP socket. When the answer comes back, there's nothing listening on the destination port, so the kernel generates the ICMP port unreachable message. My money would be a on Web browser. Cheers, Simon. On 12/05/15 18:35, Nikita N. wrote: Hi All, was wandering about those ICMP frames, which keep coming out always right after every Dnsmasq responses. What is their origin? What is their purpose? Just to be sure what I'm talking about, here how it happens: 1) client (192.168.2.2) - gateway (192.168.2.1), DNS Standard query about mylocalsite.com 2) gateway - client, DNS Standard query response A 192.168.2.1 (Wireshark Request in pointer is to #1) 3) client - gateway, ICMP Destination unreachable (Port unreachable) (Wireshark Request in pointer is also to #1) That ICMP frame has IPv4 section, Src: 192.168.2.2 (client), Dst: 192.168.2.1 (gateway) But the ICMP section shows the opposite, Src: 192.168.2.1, Dst: 192.168.2.2 Whose UDP section, Src Port: 53 (53), Dst Port: 5 I googled around, and I can't see any ICMP echo ping preceding, so I don't understand where those ICMP are from, and/what are their purpose. Maybe are generated by Dnsmasq, as some kind of alternate DNS response? Maybe are generated by gateway linux kernel, as some kind of standard behavior? Maybe are generated by the client software/web browser? Thanks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- http://www.fastmail.com - Choose from over 50 domains or use your own ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DNS - ICMP - Destination unreachable (Port unreachable) ?
Hi All, was wandering about those ICMP frames, which keep coming out always right after every Dnsmasq responses. What is their origin? What is their purpose? Just to be sure what I'm talking about, here how it happens: 1) client (192.168.2.2) - gateway (192.168.2.1), DNS Standard query about mylocalsite.com 2) gateway - client, DNS Standard query response A 192.168.2.1 (Wireshark Request in pointer is to #1) 3) client - gateway, ICMP Destination unreachable (Port unreachable) (Wireshark Request in pointer is also to #1) That ICMP frame has IPv4 section, Src: 192.168.2.2 (client), Dst: 192.168.2.1 (gateway) But the ICMP section shows the opposite, Src: 192.168.2.1, Dst: 192.168.2.2 Whose UDP section, Src Port: 53 (53), Dst Port: 5 I googled around, and I can't see any ICMP echo ping preceding, so I don't understand where those ICMP are from, and/what are their purpose. Maybe are generated by Dnsmasq, as some kind of alternate DNS response? Maybe are generated by gateway linux kernel, as some kind of standard behavior? Maybe are generated by the client software/web browser? Thanks -- Nikita N. niki...@operamail.com -- http://www.fastmail.com - The way an email service should be ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP over a wireless bridge
Hi Albert :) you didnt mention last time you had a wifi based configuration too, nice to know! :) To answer John, if I can try to help, yes, your requirement looks little unclear to me too.. FYI, Im playing too with a wifi loopback bridge project, and its indeed not very easy to implement from scratch.. ;) Im running too dnsmasq on the AP side, absolutely DHCP dynamic (nothing static) but only because the AP is a Linux fully operational dedicated server.. Running dnsmasq on a AP router bought and used as is of course you cant.. I suspect you need to install your own Linux, lots of infos on web about that .. As for me, a common issue Im encountering here is the server/AP not hearing the client frames (even if client/AP are close each other), so you would need to implement also your own logic for retransmission if that happens in your tests.. Also be very attentive on the option you give to dnsmasq: you pick the wrong ones, things will not work as you want! :) so you could also post your dnsmasq.conf here.. Im encountering also other issues, unfortunately, but Im still working on them.. On Tue, Jan 7, 2014, at 09:45 PM, Albert ARIBAUD wrote: Le 08/01/2014 03:11, John Kaye a écrit : Hi All, I'm developing a transparent wireless bridge for a client who manufactures printers. The printers connect through the Ethernet side of the bridge and the wireless side of the bridge associates with an AP. The AP will reject frames from the printers because their source address is different from the source address that is associated with the AP; to resolve that, ebtables is used to snat the source address of the frames from the printers, and everything flows. Everything flows nicely when the printers are configured with static IPs. When the printers are configured to use DHCP, the AP never delivers an IP, even though it receives a discovery request from the printers. I assume the AP doesn't respond because the DCHP DISCOVER frame has the client mac address encoded within it, which doesn't match the address that it is associated with, so it's ignored. Does that sound correct? To enable the printers to get IP addresses from the AP, it would seem that a DHCP relay proxy of some sort would need be to implemented to run on the bridge. The proxy would relay DHCP requests to the AP and return addresses to the printers. Does that sounds feasible? If my assumptions are correct, can dnsmasq be configured as a DHCP relay proxy? If so, are there examples of how it can be done? If my assumptions are not correct (which I imagine they are), are there other options? I truly appreciate any guidance. My networking knowledge is limited, though it is growing by leaps and bounds! Cheers, -John I am not sure I understand your requirements fully, but I have a setup similar to yours, or more exactly, I have a setup where DHCP clients are on one side of a wireless link and the dnsmasq server is on the other side, and I did not have to snat because I did not experience this: he AP will reject frames from the printers because their source address is different from the source address that is associated with the AP Can you elaborate on the symptom (the rejection): what do you try, what do you expect and what do you actually see that makes you conclude the AP has rejected the printer's frames? Amicalement, -- Albert. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- http://www.fastmail.fm - Send your email first class ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ARP ignores DHCP ACKs !
Hi Albert :) Still, would like to ask you about ICMP frames, if I can.. ;) because you say client uses ARP, the GW uses ICMP.. right? Not the gateway, the DHCP server (which may or may not be a gateway). Yes yes, I run on 1 Linux machine, it does all, gw and dnsmasq (dns+dhcp). Then I have another machine which does the client job. Finish, end of machines :) Well, I cant see that.. the only ICMP I see are from the client to GW, sent after DNS answers from dnsmasq (dnsmasq runs on GW).. You mean the client pings the IP of the gateway? Well, obviously I don't have the same setup as you have, but I have two Windows machines in my LAN, and none of them ever emits ICMP echo requests unless someone actually runs a ping on them in a DOS window. They do emit ARP requests, though, just like any other hosts in my LAN. ... well, dont know what to say.. I see ICMP always, mostly after DNS resp arrive.. I see them symmetrically the same in both client and GW machines (wireshark) Yes: do a Wireshark / tcpdump on both the DHCP server and client, force a DHCP exchange, see what is emitted by one machine and not received by the other. Yes, I see DHCP frames req/ack symmetrically the same in both client and GW ICMPv6: you can't block it if you want routing to happen at all. Please, explain me better this, if you have time.. what do you mean as routing to happen? If you think its too much offtopic here, just send mail only to me, thanks :) What's the point of blocking ICMP on the local network? I can understand blocking IMCP ECHO REQUESTs coming from the Internet and directed at your local network (well, at those machines from your LAN which can be addressed from the Internet); but local traffic is not really an issue. Or is it? As I said, I always see those ICMP from clients, which are really useless as there is no internet, and they always end up as host/port unreach.. I believe they produce disturbance.. Im not fully sure, but they could have caused drop of connection (red X) few times.. Now with iptables dropping ICMP on GW, the connections look more stable, I still didnt experience other drop of conn.. im talking clients XP and Vista of course... In Win7 is still fog.. :P But Im sure there is a logical explanation for that, which im trying to find.. ;) -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Ping does not work but nslookup works (Use dnsmasq on Mac OS X)
.. btw of log facility, if I can give a suggestion.. would be nice to make it more verbose.. eg. when some behavioral exception is taken, eg. frame comes and some action should be taken, but it is NOT taken (or vice) .. a message would be nice, the user will understand whats going on.. typical my example, if a message would have come to logs, eg. timeout upstream server- switching to authoritative mode, that would have helped :) just an idea btw.. :P On Mon, Dec 23, 2013, at 08:09 AM, Peng Yu wrote: When I run dig oxygen.yulab, I see the following log. Dec 23 10:05:35 dnsmasq[51588]: query[A] oxygen.yulab from 127.0.0.1 Dec 23 10:05:35 dnsmasq[51588]: forwarded oxygen.yulab to 192.168.1.25 Dec 23 10:05:35 dnsmasq[51588]: reply oxygen.yulab is 192.168.1.163 When I run dig @192.168.1.25 oxygen.yulab, I see the following log. Dec 23 10:07:24 dnsmasq[51588]: query[A] oxygen.yulab from 127.0.0.1 Dec 23 10:07:24 dnsmasq[51588]: cached oxygen.yulab is 192.168.1.163 So this means dnsmasq is running correctly? Does mac's ping use something else to resolve ip addresses? Thanks. -- http://www.fastmail.fm - 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
[Dnsmasq-discuss] LLMNR?
Hi :) I searched the man page but didnt find any mention to LLMNR.. my Windows7 client keeps sending queries to LLMNR, but they all stay unanswered.. I dont have others dns servers, Im in the authoritative case. So wanted to ask, how can I configure dnsmasq to answer also LLMNR queries ( 224.0.0.252:5355 )? Thanks :) -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
Hi All, its the first time for me on this maillist :) Im trying some tests with dnsmasq, but I cant make it work.. sorry :( I dont know if its a bug.. or its just me missing something.. So here what I want to do: I created a tap ethernet interface (on wireless, because I have only that, but thats not important I guess..). I called at0, and I enabled it with ifconfig at0 up 192.168.0.1 netmask 255.255.255.0 All works ok, I see the interface receive/transmit Ethernet frames, also I see ip6 management frames around, and so on.. Now I want to provide DHCP and DNS functionality to at0, so I found dnsmasq which should do both (isn't it?) So what are the requirements for dnsmasq: after providing an ip by DHCP, every *every* page request by DNS must be answered 192.168.0.1. In fact Im not providing any wan/internet connection at all, its just a test, so e.g., if appears on at0 a DNS request for www.google.com, dnsmasq must send *at-once* a DNS answer with 192.168.0.1 - always! Here my dnsmasq.conf: no-hosts no-resolv no-poll no-negcache no-ping address=/#/192.168.0.1 dhcp-range=192.168.0.2,192.168.0.254,255.255.255.0,12h interface=at0 .. unfortunately it doesnt work.. :( The following is not working: 1) when appears on at0 a DHCP request as first, without the discover first, no answer comes! it *always* happens that after the first connection, my network does not send the any discover anymore, dnsmasq no answer, so my network sends a ARP gratuitous, but still dnsmasq keeps silent.. if a discover comes on at0, then ok, dnsmasq sends answer ACK.. but I repeat, it very rare that my network sends a discover, so I need dnsmasq to always answer DHCP ACK anyway! 2) when appears on at0 a DNS request for any website, www.google.com, just any, dnsmasq keeps silent, no answer.. after repeated requests, maybe after half hour repeated requests, then dnsmasq finally decides to answer correctly with DNS answer=192.168.0.1.. but only after half hour! thats unacceptable.. Any help? Thanks :) -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/help/overview_quotes.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
Hi Albert :) what I wrote you is what in fact I *see* from Wireshark. I see all traffic there, I see exactly when and where appears the frame into at0, the DHCP and DNS request frames from me, the correct answers from dnsmasq and the silences from dnsmasq :) Any help? On Mon, Dec 9, 2013, at 02:07 AM, Albert ARIBAUD wrote: Le 09/12/2013 09:29, Nikita N. a écrit : Hi All, its the first time for me on this maillist :) Im trying some tests with dnsmasq, but I cant make it work.. sorry :( I dont know if its a bug.. or its just me missing something.. So here what I want to do: I created a tap ethernet interface (on wireless, because I have only that, but thats not important I guess..). I called at0, and I enabled it with ifconfig at0 up 192.168.0.1 netmask 255.255.255.0 All works ok, I see the interface receive/transmit Ethernet frames, also I see ip6 management frames around, and so on.. Now I want to provide DHCP and DNS functionality to at0, so I found dnsmasq which should do both (isn't it?) So what are the requirements for dnsmasq: after providing an ip by DHCP, every *every* page request by DNS must be answered 192.168.0.1. In fact Im not providing any wan/internet connection at all, its just a test, so e.g., if appears on at0 a DNS request for www.google.com, dnsmasq must send *at-once* a DNS answer with 192.168.0.1 - always! Here my dnsmasq.conf: no-hosts no-resolv no-poll no-negcache no-ping address=/#/192.168.0.1 dhcp-range=192.168.0.2,192.168.0.254,255.255.255.0,12h interface=at0 .. unfortunately it doesnt work.. :( The following is not working: 1) when appears on at0 a DHCP request as first, without the discover first, no answer comes! it *always* happens that after the first connection, my network does not send the any discover anymore, dnsmasq no answer, so my network sends a ARP gratuitous, but still dnsmasq keeps silent.. if a discover comes on at0, then ok, dnsmasq sends answer ACK.. but I repeat, it very rare that my network sends a discover, so I need dnsmasq to always answer DHCP ACK anyway! 2) when appears on at0 a DNS request for any website, www.google.com, just any, dnsmasq keeps silent, no answer.. after repeated requests, maybe after half hour repeated requests, then dnsmasq finally decides to answer correctly with DNS answer=192.168.0.1.. but only after half hour! thats unacceptable.. Any help? Thanks :) I would suggest that you run tcpdump on the same machine where dnsmasq is running in order to see what DHCP traffic the machine itself sees. That'll help determine where the request is dropped exactly. Amicalement, -- Albert. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- http://www.fastmail.fm - Does exactly what it says on the tin ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
Hi Albert :) I see you want a complete log/trace session for your debugging, isnt it? :) Well I didnt think to prepare that, I was thinking you could give me some more easy answer.. First of all I would like to know, is my config file correct? With such config file, am I supposed to get what I want? Because, if my usage is correct and the config file is correct, then its some kind of bug, and so I can prepare you some traces, if you really need.. Honestly, since dnsmasq didnt work, in fact I dropped dnsmasq.. I tested with dhcpd for the DHCP support, and with dnsspoof for the DNS, and all works great. But as you know, dhcpd is very heavy app, king of too exaggerate for my needs, and dnsspoof is a dirty hack tool.. So was hoping in dnsmasq for a clean,small, all-in-one solution.. but maybe Im wrong..? On Mon, Dec 9, 2013, at 03:11 AM, Albert ARIBAUD wrote: Le 09/12/2013 11:50, Nikita N. a écrit : Hi Albert :) what I wrote you is what in fact I *see* from Wireshark. I see all traffic there, I see exactly when and where appears the frame into at0, the DHCP and DNS request frames from me, the correct answers from dnsmasq and the silences from dnsmasq :) Any help? Sorry, I did not see that you were speaking about wireshark traces. The detailed output from Wireshark/tcpdump in the working and failing cases could help -- more if you can get one from the DHCP client and one from the server at the same time for each case. You don't need to post it to the list; you can 'pastebin' it somewhere and just post the 'pastebin' URL. Amicalement, -- Albert. -- http://www.fastmail.fm - 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] address=/#/192.168.0.1 - does not work!
OH my god! :)) I see now you are not the author of dnsmasq.. I see the author id Simon Kelley.. apologies, I thought I was talking with the author :) Of course you dont have to debug that issue! :D No, really, im pretty sure of what I saw in wireshark traces, even because I spent few hours in testing dnsmasq, and it really didnt work as I expected.. Mostly the DNS feature half-hour-delayed disappointed me enough.. So my question is directed to the author of dnsmasq - I still dont know, can I use dnsmasq for my needs? or im just wasting time? Thanks :) On Mon, Dec 9, 2013, at 04:14 AM, Albert ARIBAUD wrote: Le 09/12/2013 12:26, Nikita N. a écrit : Hi Albert :) I see you want a complete log/trace session for your debugging, isnt it? :) *My* debugging? No. I don't intend to debu your issue, only have a look at it and see if, as a user of dnsmasq to another, I can help *you* debugging. :) Also, I don't think a complete log/trace is needed. Only DHCP packets are useful, and only from the request or discovery packet to the ack packet (or clear lack thereof). Well I didnt think to prepare that, I was thinking you could give me some more easy answer.. Rule number one of problem solving: you cannot solve a problem if you do not know what the problem is. Since your problem is a missing packet in a DHCP exchange, the first thing I'd do is to have a look at the exact DHCP messages sent and received by the DHCP client and server, as seen by either machine. I would also suggest logging ARP packets. First of all I would like to know, is my config file correct? With such config file, am I supposed to get what I want? Because, if my usage is correct and the config file is correct, then its some kind of bug, and so I can prepare you some traces, if you really need.. Well, I did not look at the config file because you mentioned that your use scenario works in case the DHCP discover packet is sent first, which means the interfaces, the ranges, the leases are basically ok; and that, as far as I know, there is no way to configure dnsmasq so that it answers differently depending on there being a discover message or not. Honestly, since dnsmasq didnt work, in fact I dropped dnsmasq.. I tested with dhcpd for the DHCP support, and with dnsspoof for the DNS, and all works great. But as you know, dhcpd is very heavy app, king of too exaggerate for my needs, and dnsspoof is a dirty hack tool.. So was hoping in dnsmasq for a clean,small, all-in-one solution.. but maybe Im wrong..? We can only know by investigating. Apart from logging the issues you meett, you could also perform some tests if you have another machine which can connect to the server through Ethernet. This would help discriminate between a server- or client-related issue and a network equipment-related issue. Also: could you avoid top-posting? Amicalement, -- Albert. -- http://www.fastmail.fm - The way an email service should be ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
On Mon, Dec 9, 2013, at 04:59 AM, Albert ARIBAUD wrote: Mostly the DNS feature half-hour-delayed disappointed me enough.. So my question is directed to the author of dnsmasq - I still dont know, can I use dnsmasq for my needs? or im just wasting time? Thanks :) AFAICT, yes, you should be able to obtain what you are looking for. Ok then :) since I found such professional support here (indeed very rare to find,congratulations!) Im willing to give dnsmasq another chance.. ;) Its weekend, I have some spare time, im going to perform the tests you suggest, and dump some traces. Thanks and CU later! :) -- http://www.fastmail.fm - mmm... Fastmail... ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
Yes, it did the trick, worked at first shot :) Still remains that silence after DHCP requests without previous discover.. really unpleasant.. Probably its not 100% protocol compliant, but I see also from dhcpd, its common behaviour to accept DHCP requests from returning clients.. Maybe implement a new option also in dnsmasq to enable such behavior/exception? On Mon, Dec 9, 2013, at 09:04 AM, Simon Kelley wrote: I think this may be what you need. -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- http://www.fastmail.fm - Access your email from home and the web ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!
Sorry sorry, it works it works :) I was looking at an old trace, apologies.. Going to trash dhcpd and that dirty disgusting wtf dnsspoof.. ;) Thanks and keep on the good work! :D On Mon, Dec 9, 2013, at 03:01 PM, Nikita N. wrote: Yes, it did the trick, worked at first shot :) Still remains that silence after DHCP requests without previous discover.. really unpleasant.. Probably its not 100% protocol compliant, but I see also from dhcpd, its common behaviour to accept DHCP requests from returning clients.. Maybe implement a new option also in dnsmasq to enable such behavior/exception? -- http://www.fastmail.fm - Same, same, but different... ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
