Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Simon Kelley]

Thanks for the offer. I think there may be a simpler answer, worth
trying first.

Looking back through the git history, this looks like a bug introduced
into 2.78 by the patches for security problems found by Google, in 2017.

It was fixed for 2.79, by  patch


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974

So, first either move to 2.79 (or preferably 2.80) or apply that patch.

If that doesn't fix it, we'll go for debugging.


Cheers,

Simon.



On 10/01/2019 12:18, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks again for the response.
> 
> I will be happy to be your tester :)
> 
> Its fairly a simple setup with two hosts and a switch. I can create this
> any time you want.
> 
> Please provide me the instructions. I am using dnsmasq version 2.78.
> 
> Thanks
> -Sandeep
> 
> On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley  > wrote:
> 
> On 04/01/2019 06:25, Sandeep K M wrote:
> > Hi Simon,
> >
> > Thanks a lot for your prompt reply.
> >
> > Attached are the packet captures:
> >
> > 1. Packets exchanged between client and relay (client-relay.pcap)
> > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > 3. strace of dnsmasq (dnsmasq.trace)
> >
> > Please let me know if any other information is required.  
> >
> > I am not an expert in reading pcap's or strace but I do see in the
> > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE"
> message is
> > being written to the same interface from which it received the
> > "DHCPSOLICIT" packet. But still it is fails to go out of that
> interface.
> >
> > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> >
> > Any help on this would be greatly appreciated. Also is there any
> example
> > configuration of dnsmasq dhcpv6 working with relay ? Any reference
> would
> > be of great help.
> >
> 
> I'm sure this was tested with a relay, but the current test harnesses
> here would take some work to get into a position to test this code, so
> I'm going to try and use you as a tester, if that's OK?
> 
> 
> Looking at the strace output, dnsmasq logs that it's sending a
> DHCPADVERTISE reply, but it never calls sendto() to actually send the
> packet. This is definitely a dnsmasq bug, and not something in your
> network that's causing the packet to get lost: it never gets sent.
> 
> 
> What's confusing me is that manually tracing the code paths from what's
> known to be working (log the DHCPADVERTISE) to the sendto() call that
> should send that packet, I can't see any reason why the code should
> fail.
> 
> Are you in a position to run dnsmasq under gdb and step through the
> relevant code? I can give you detailed instructions on where to set
> breakpoints and where the reply packet could be getting lost. The path
> is maybe 50 lines.
> 
> Staring at the code has found me one bug, but it's not relevant in this
> case. (The code to avoid copying an RFC6939 link address option in a
> relay request to the reply to the relay actually sends a zero-length
> option, instead of eliding it entirely.)
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 

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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Simon Kelley]

On 04/01/2019 06:25, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks a lot for your prompt reply.
> 
> Attached are the packet captures:
> 
> 1. Packets exchanged between client and relay (client-relay.pcap)
> 2.  Packets exchanged between relay and server (relay-server.pcap)
> 3. strace of dnsmasq (dnsmasq.trace)
> 
> Please let me know if any other information is required.  
> 
> I am not an expert in reading pcap's or strace but I do see in the
> attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" message is
> being written to the same interface from which it received the
> "DHCPSOLICIT" packet. But still it is fails to go out of that interface.
> 
> 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> 
> Any help on this would be greatly appreciated. Also is there any example
> configuration of dnsmasq dhcpv6 working with relay ? Any reference would
> be of great help.
> 

I'm sure this was tested with a relay, but the current test harnesses
here would take some work to get into a position to test this code, so
I'm going to try and use you as a tester, if that's OK?


Looking at the strace output, dnsmasq logs that it's sending a
DHCPADVERTISE reply, but it never calls sendto() to actually send the
packet. This is definitely a dnsmasq bug, and not something in your
network that's causing the packet to get lost: it never gets sent.


What's confusing me is that manually tracing the code paths from what's
known to be working (log the DHCPADVERTISE) to the sendto() call that
should send that packet, I can't see any reason why the code should fail.

Are you in a position to run dnsmasq under gdb and step through the
relevant code? I can give you detailed instructions on where to set
breakpoints and where the reply packet could be getting lost. The path
is maybe 50 lines.

Staring at the code has found me one bug, but it's not relevant in this
case. (The code to avoid copying an RFC6939 link address option in a
relay request to the reply to the relay actually sends a zero-length
option, instead of eliding it entirely.)

Cheers,

Simon.





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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Geert Stappers]

On Mon, Jan 07, 2019 at 01:09:11PM +0530, Sandeep K M wrote:
> On Fri, Jan 4, 2019 at 7:32 PM Geert Stappers wrote:
> > On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote:
> >
> > > Please let me know if any other information is needed.
> >
> > Not yet mentioned in this thread is working connectity between "server"
> > and "client".  This will require temporary manual configuration
> > of an IPv6 address at client. Let say it is 2020::2/120.
> > Then verify with more than "ping". Example given:  `ssh 1040::2`
> >
> > It shall reveal how well router ( with the odd name 'Switch' ) is
> > configured for routing between 1040::/120 and 2020::/120.
> > Also if the ssh deamon is able to send packets out on the right
> > interface.
> >
> > I do know that it might seem a detour. And we also known that
> > original poster is already stuck with current setup. So the "detour"
> > could be a step forward.   Good luck.
> >
> >
> Hi,
> 
> As you suggested I added the IPv6 address 2020::2/120 manually to my client
> 
> # ip -6 addr add 2020::2/120 dev eth1
> 
> when I pinged the server it failed :
> 
> root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> ping: sendmsg: Network is unreachableping: sendmsg: Network is unreachale
> 
> Then I added a default route:
> 
> 
> root@Ubuntu3481:~# ip -6 route add default via 2020::1
> root@Ubuntu3481:~# ip -6 route
> 2020::/120 dev eth1  proto kernel  metric 256
> fe80::/64 dev eth0  proto kernel  metric 256
> fe80::/64 dev eth1  proto kernel  metric 256
> default via 2020::1 dev eth1  metric 1024
> 
> I see the ping is working fine now:
> 
> root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> 64 bytes from 1040::2: icmp_seq=1 ttl=63 time=0.278 ms
> 64 bytes from 1040::2: icmp_seq=2 ttl=63 time=0.178 ms
> 64 bytes from 1040::2: icmp_seq=3 ttl=63 time=0.172 ms
 
So ICMP packets can roundtrip across the router.
If other packets can, is still unknown.
(As in '> > Then verify with more than "ping". Example given:  `ssh 1040::2`')


Idea is finding out if the original problem could be caused
by incomplete routing rules.



> But when I remove the manually configured IPv6 address and try to get a new
> IPv6 using "dhclient -6 eth1" again it fails. I see the same log lines in
> dnsmasq log:
> 
> Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> 
> When we have enable-ra configured wont dnsmasq advertise the gateway IP's ?
> Do we need to enable RA even in the switch where relay agent is running ?
> can we configure default gateway to the clients via dhcpv6 options similar
> to IPv4 ?
> 
> 
> PS: If I replace dnsmasq server with ISC DHCP server everything works fine.

And the essential configuration items of the working setup
are correctly transposed to the non-working setup?


Regards
Geert Stappers
Curious about why the DHCPADVERTISE packets aren't seen with a network sniffer.

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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Sandeep K M]

Hi,

As you suggested I added the IPv6 address 2020::2/120 manually to my client
using the below command:

*ip -6 addr add 2020::2/120 dev eth1*

when I pinged the server it failed :




*root@Ubuntu3481:~# ping6 -I 2020::2 1040::2PING 1040::2(1040::2) from
2020::2 : 56 data bytesping: sendmsg: Network is unreachableping: sendmsg:
Network is unreachale*

Then I added a default route:






*root@Ubuntu3481:~# ip -6 route add default via 2020::1root@Ubuntu3481:~#
ip -6 route2020::/120 dev eth1  proto kernel  metric 256fe80::/64 dev eth0
proto kernel  metric 256fe80::/64 dev eth1  proto kernel  metric 256default
via 2020::1 dev eth1  metric 1024*

I see the ping is working fine now:





*root@Ubuntu3481:~# ping6 -I 2020::2 1040::2PING 1040::2(1040::2) from
2020::2 : 56 data bytes64 bytes from 1040::2: icmp_seq=1 ttl=63 time=0.278
ms64 bytes from 1040::2: icmp_seq=2 ttl=63 time=0.178 ms64 bytes from
1040::2: icmp_seq=3 ttl=63 time=0.172 ms*

But when I remove the manually configured IPv6 address and try to get a new
IPv6 using "dhclient -6 eth1" again it fails. I see the same log lines in
dnsmasq log:

Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7)
00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19
00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7)
00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19
00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c

When we have enable-ra configured wont dnsmasq advertise the gateway IP's ?
Do we need to enable RA even in the switch where relay agent is running ?
can we configure default gateway to the clients via dhcpv6 options similar
to IPv4 ?


*PS: If I replace dnsmasq server with ISC DHCP server everything works
fine.*

Thanks
-Sandeep




On Fri, Jan 4, 2019 at 7:32 PM Geert Stappers 
wrote:

> On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote:
> > Hi,
> >
> > On Fri, Jan 4, 2019 at 3:59 PM Geert Stappers wrote:
> > > On Fri, Jan 04, 2019 at 02:47:11PM +0530, Sandeep K M wrote:
> > > > On Fri, Jan 4, 2019 at 2:30 PM Geert Stappers wrote:
> > > > > On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> > > > > > [  ]
> > > > > > Please let me know if any other information is required.
> > > > >
> > > > > At the server
> > > > >   ip link   # what interfaces are there
> > > > >   ip -6 address
> > > > >   ip -6 route
> > > >
> > > > Here are the output of the commands:
> > > >
> > > > root@8320:~# *ip -6 addr*
> > > > 49: m1s1p7:  mtu 1500 state UNKNOWN
> qlen 1000
> > > > inet6 1040::2/120 scope global
> > > >valid_lft forever preferred_lft forever
> > > > inet6 fe80::480f:cf00:7af:8444/64 scope link
> > > >valid_lft forever preferred_lft forever
> > >
> > > Based upon that: there is only 1 interface
>
> But it are about sixty
>
>
> > > > root@8320:~# *ip -6 route*
> > > > 1040::/120 dev m1s1p7  proto kernel  metric 256  pref medium
> > > > 2020::/120 via 1040::1 dev m1s1p7  proto static  metric 512  pref
> medium
> > >
> > > So there is some kind of routing information where the 2020::/120
> network
> > > is ...
> > >
>
> In the non-stripped version
> > fe80::/64 dev bridge-vrf  proto kernel  metric 256  pref medium
> > fe80::/64 dev tap0  proto kernel  metric 256  pref medium
> > fe80::/64 dev tap-br0  proto kernel  metric 256  pref medium
> > fe80::/64 dev m1s1p7  proto kernel  metric 256  pref medium
> (do notice there is no default route)
>
> > > > Sorry forgot to capture "ip link" output. The setup is disassembled
> as of
> > > > now but if it is required then I will recreate the setup and send
> you the
> > > > output.
> > >
> > > Come again?
> > > As in: "How was the output of `ip -6 addr` and `ip -6 route`
> generated?"
> > >
> > These command output is what I have captured previously for my reference
> > before dissembling the setup.
>
> OK. Thanks for explaining.
>
> > *I have recreated the setup and attached (ip-command-output.txt) is the
> > output of the commands that you have requested in full*.
>
> > Please let me know if any other information is needed.
>
> Not yet mentioned in this thread is working connectity between "server"
> and "client".  This will require temporary manual configuration
> of an IPv6 address at client. Let say it is 2020::2/120.
> Then verify with more than "ping". Example given:  `ssh 1040::2`
>
> It shall reveal how well router ( with the odd name 'Switch' ) is
> configured for routing between 1040::/120 and 2020::/120.
> Also if the ssh deamon is able to send packets out on the right
> interface.
>
> I do know that it might seem a detour. And we also known that
> original poster is already stuck with current setup. So the "detour"
> could be a step forward.   Good luck.
>
>
> Groeten
> Geert Stappers
>
>
> ___
> Dnsmasq-discuss mailing list
> 

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Geert Stappers]

On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote:
> Hi,
> 
> On Fri, Jan 4, 2019 at 3:59 PM Geert Stappers wrote:
> > On Fri, Jan 04, 2019 at 02:47:11PM +0530, Sandeep K M wrote:
> > > On Fri, Jan 4, 2019 at 2:30 PM Geert Stappers wrote:
> > > > On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> > > > > [  ]
> > > > > Please let me know if any other information is required.
> > > >
> > > > At the server
> > > >   ip link   # what interfaces are there
> > > >   ip -6 address
> > > >   ip -6 route
> > >
> > > Here are the output of the commands:
> > >
> > > root@8320:~# *ip -6 addr*
> > > 49: m1s1p7:  mtu 1500 state UNKNOWN qlen 
> > > 1000
> > > inet6 1040::2/120 scope global
> > >valid_lft forever preferred_lft forever
> > > inet6 fe80::480f:cf00:7af:8444/64 scope link
> > >valid_lft forever preferred_lft forever
> >
> > Based upon that: there is only 1 interface

But it are about sixty


> > > root@8320:~# *ip -6 route*
> > > 1040::/120 dev m1s1p7  proto kernel  metric 256  pref medium
> > > 2020::/120 via 1040::1 dev m1s1p7  proto static  metric 512  pref medium
> >
> > So there is some kind of routing information where the 2020::/120 network
> > is ...
> >

In the non-stripped version
> fe80::/64 dev bridge-vrf  proto kernel  metric 256  pref medium
> fe80::/64 dev tap0  proto kernel  metric 256  pref medium
> fe80::/64 dev tap-br0  proto kernel  metric 256  pref medium
> fe80::/64 dev m1s1p7  proto kernel  metric 256  pref medium
(do notice there is no default route)

> > > Sorry forgot to capture "ip link" output. The setup is disassembled as of
> > > now but if it is required then I will recreate the setup and send you the
> > > output.
> >
> > Come again?
> > As in: "How was the output of `ip -6 addr` and `ip -6 route` generated?"
> >
> These command output is what I have captured previously for my reference
> before dissembling the setup.

OK. Thanks for explaining.

> *I have recreated the setup and attached (ip-command-output.txt) is the
> output of the commands that you have requested in full*.

> Please let me know if any other information is needed.

Not yet mentioned in this thread is working connectity between "server"
and "client".  This will require temporary manual configuration
of an IPv6 address at client. Let say it is 2020::2/120.
Then verify with more than "ping". Example given:  `ssh 1040::2`

It shall reveal how well router ( with the odd name 'Switch' ) is
configured for routing between 1040::/120 and 2020::/120.
Also if the ssh deamon is able to send packets out on the right
interface.

I do know that it might seem a detour. And we also known that
original poster is already stuck with current setup. So the "detour"
could be a step forward.   Good luck.


Groeten
Geert Stappers


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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Sandeep K M]

Hi,

These command output is what I have captured previously for my reference
before dissembling the setup. I tried to capture only the relevant
interface output but not all.

*I have recreated the setup and attached (ip-command-output.txt) is the
output of the commands that you have requested in full*. Please let me know
if any other information is needed.

PS: As the command outputs are pretty big I have captured in a file.

Thanks
-Sandeep

On Fri, Jan 4, 2019 at 3:59 PM Geert Stappers 
wrote:

> On Fri, Jan 04, 2019 at 02:47:11PM +0530, Sandeep K M wrote:
> > On Fri, Jan 4, 2019 at 2:30 PM Geert Stappers wrote:
> > > On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> > > > [  ]
> > > >
> > > > Please let me know if any other information is required.
> > >
> > >
> > > At the server
> > >
> > >   ip link   # what interfaces are there
> > >   ip -6 address
> > >   ip -6 route
> > >
> > Hi,
> >
> > Here are the output of the commands:
> >
> > root@8320:~# *ip -6 addr*
> > 49: m1s1p7:  mtu 1500 state UNKNOWN
> qlen 1000
> > inet6 1040::2/120 scope global
> >valid_lft forever preferred_lft forever
> > inet6 fe80::480f:cf00:7af:8444/64 scope link
> >valid_lft forever preferred_lft forever
>
> Based upon that: there is only 1 interface
>
> > root@8320:~# *ip -6 route*
> > 1040::/120 dev m1s1p7  proto kernel  metric 256  pref medium
> > 2020::/120 via 1040::1 dev m1s1p7  proto static  metric 512  pref medium
>
> So there is some kind of routing information where the 2020::/120 network
> is ...
>
>
> > Sorry forgot to capture "ip link" output. The setup is disassembled as of
> > now but if it is required then I will recreate the setup and send you the
> > output.
>
> Come again?
> As in: "How was the output of `ip -6 addr` and `ip -6 route` generated?
>
>
>
> Cheers
> Geert Stappers
> DevOps Engineer
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
root@8320:~# ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: bridge-vrf:  mtu 9198 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000
link/ether 52:3f:d2:26:79:d4 brd ff:ff:ff:ff:ff:ff
3: tap-br0@tap0:  mtu 9198 qdisc noqueue 
master bridge-vrf state UP mode DEFAULT group default qlen 1000
link/ether 52:3f:d2:26:79:d4 brd ff:ff:ff:ff:ff:ff
4: tap0@tap-br0:  mtu 9198 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000
link/ether 2e:e8:a4:b0:fe:1e brd ff:ff:ff:ff:ff:ff
6: m1s1p52:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
7: m1s1p8:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
8: m1s1p38:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
9: m1s1p13:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
10: m1s1p26:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
11: m1s1p35:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
12: m1s1p41:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
13: m1s1p42:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
14: m1s1p27:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
15: m1s1p48:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
16: m1s1p32:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
17: m1s1p3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
18: m1s1p18:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
19: m1s1p20:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
20: m1s1p40:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
21: m1s1p54:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd ff:ff:ff:ff:ff:ff
22: m1s1p5:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 70:72:cf:fd:e1:0d brd 

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Geert Stappers]

On Fri, Jan 04, 2019 at 02:47:11PM +0530, Sandeep K M wrote:
> On Fri, Jan 4, 2019 at 2:30 PM Geert Stappers wrote:
> > On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> > > [  ]
> > >
> > > Please let me know if any other information is required.
> >
> >
> > At the server
> >
> >   ip link   # what interfaces are there
> >   ip -6 address
> >   ip -6 route
> >
> Hi,
> 
> Here are the output of the commands:
> 
> root@8320:~# *ip -6 addr*
> 49: m1s1p7:  mtu 1500 state UNKNOWN qlen 1000
> inet6 1040::2/120 scope global
>valid_lft forever preferred_lft forever
> inet6 fe80::480f:cf00:7af:8444/64 scope link
>valid_lft forever preferred_lft forever

Based upon that: there is only 1 interface

> root@8320:~# *ip -6 route*
> 1040::/120 dev m1s1p7  proto kernel  metric 256  pref medium
> 2020::/120 via 1040::1 dev m1s1p7  proto static  metric 512  pref medium

So there is some kind of routing information where the 2020::/120 network is ...


> Sorry forgot to capture "ip link" output. The setup is disassembled as of
> now but if it is required then I will recreate the setup and send you the
> output.

Come again?
As in: "How was the output of `ip -6 addr` and `ip -6 route` generated?



Cheers
Geert Stappers
DevOps Engineer

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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Sandeep K M]

Hi,

Here are the output of the commands:

root@8320:~# *ip -6 addr*

49: m1s1p7:  mtu 1500 state UNKNOWN qlen
1000

inet6 1040::2/120 scope global

   valid_lft forever preferred_lft forever

inet6 fe80::480f:cf00:7af:8444/64 scope link

   valid_lft forever preferred_lft forever

root@8320:~# *ip -6 route*

1040::/120 dev m1s1p7  proto kernel  metric 256  pref medium

2020::/120 via 1040::1 dev m1s1p7  proto static  metric 512  pref medium

Sorry forgot to capture "ip link" output. The setup is disassembled as of
now but if it is required then I will recreate the setup and send you the
output.

Thanks
-Sandeep


On Fri, Jan 4, 2019 at 2:30 PM Geert Stappers 
wrote:

> On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> > Attached are the packet captures:
> >
> > 1. Packets exchanged between client and relay (client-relay.pcap)
> > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > 3. strace of dnsmasq (dnsmasq.trace)
> >
> > Please let me know if any other information is required.
>
>
> At the server
>
>   ip link   # what interfaces are there
>   ip -6 address
>   ip -6 route
>
>
>
> Cheers
> Geert Stappers
> DevOps Engineer
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Geert Stappers]

On Fri, Jan 04, 2019 at 11:55:49AM +0530, Sandeep K M wrote:
> Attached are the packet captures:
> 
> 1. Packets exchanged between client and relay (client-relay.pcap)
> 2.  Packets exchanged between relay and server (relay-server.pcap)
> 3. strace of dnsmasq (dnsmasq.trace)
> 
> Please let me know if any other information is required.


At the server

  ip link   # what interfaces are there
  ip -6 address
  ip -6 route



Cheers
Geert Stappers
DevOps Engineer

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

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Sandeep K M]

Hi Simon,

Thanks a lot for your prompt reply.

Attached are the packet captures:

1. Packets exchanged between client and relay (client-relay.pcap)
2.  Packets exchanged between relay and server (relay-server.pcap)
3. strace of dnsmasq (dnsmasq.trace)

Please let me know if any other information is required.

I am not an expert in reading pcap's or strace but I do see in the attached
strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" message is being
written to the same interface from which it received the "DHCPSOLICIT"
packet. But still it is fails to go out of that interface.

06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73

Any help on this would be greatly appreciated. Also is there any example
configuration of dnsmasq dhcpv6 working with relay ? Any reference would be
of great help.

Thanks
-Sandeep

On Fri, Jan 4, 2019 at 3:21 AM Simon Kelley  wrote:

> It would be useful to get full packet dumps rather than just tcpdump
> output.
>
> It would also be useful to run dnsmasq under strace and see what
> syscalls it's making: that would tell use where the reply might be going.
>
>
> Cheers,
>
> Simon.
>
>
>
>
> On 03/01/2019 07:41, Sandeep K M wrote:
> > Hi All,
> >
> >
> >
> > I have a simple setup with a relay agent as shown below:
> >
> >
> > +--+-+
> > |dnsmasq server |
> >
> > | (ubuntu) |
> >
> > +-+
> > | m1s1p7 (1040::2/120)
> > | (IP route : 2020::/120 via 1040::1 dev m1s1p7  proto
> > static  metric 512  pref medium)
> > |
> > |
> > | 1/1/2 (1040::1/120)
> > +--++
> > |Switch|
> > | (Relay Agent )  |
> > +---+
> > | 1/1/1 (2020::1/120)
> > |
> > |
> > | eth1
> > +--+--+
> > | Client (Ubuntu)  |
> > +--+
> >
> >
> > It is exactly the same as explained in the video :
> > https://www.youtube.com/watch?v=2Lt1aXpCzvQ
> >
> >
> > Whenever the client is requesting an IPv6 address dnsmasq is failing to
> > respond with “DHCPADVERTISE” message. The “DHCPADVERTISE” has not been
> > sent via the interface. The tcpdump clearly shows that “DHCPADVERTISE”
> > message has not gone through the interface (m1s1p7), its only showing
> > the “DHCPSOLICIT” message which has been received:
> >
> >
> >
> > /root@8320:~# tcpdump -i *m1s1p7* udp port 547 or 546 -vvv -n/
> >
> > //
> >
> > /tcpdump: listening on m1s1p7, link-type EN10MB (Ethernet), capture size
> > 262144 bytes/
> >
> > //
> >
> > / /
> >
> > //
> >
> > /06:32:37.214798 IP6 (hlim 64, next-header UDP (17) payload length: 110)
> > 2020::1.547 > 1040::2.547: [udp sum ok] dhcp6 relay-fwd
> > (linkaddr=2020::1 peeraddr=fe80::250:56ff:febd:7c93 (relay-message
> > (*dhcp6 solicit* (xid=1894f2 (client-ID hwaddr/time type 1 time
> > 599811159 005056bd7c93) (option-request DNS-server DNS-search-list
> > Client-FQDN SNTP-servers) (elapsed-time 0) (IA_NA IAID:1455258771
> > T1:3600 T2:5400))) (interface-ID 0024...))/
> >
> >
> >
> > But the dnsmasq logs shows that it is trying to send the “DHCPADVERTISE”
> > message but for some reason it’s not been sent via the interface
> *m1s1p7. *
> >
> > * *
> >
> > **
> >
> > /root@8320:~# tail -f /var/log/dnsmasq_swns/dnsmasq6.log/
> >
> > //
> >
> > /Jan  3 06:11:20 dnsmasq[4151]: started, version 2.78 DNS disabled/
> >
> > //
> >
> > /Jan  3 06:11:20 dnsmasq[4151]: compile time options: IPv6 GNU-getopt
> > no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
> > no-DNSSEC loop-detect inotify/
> >
> > /Jan  3 06:11:20 dnsmasq-dhcp[4151]: DHCPv6, IP range 2020::10 --
> > 2020::20, lease time 1h/
> >
> > /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPSOLICIT(m1s1p7)
> > 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> >
> > //
> >
> > /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPADVERTISE(m1s1p7) 2020::12
> > 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> >
> >
> >
> > *Does anyone has any clue on what is going on here ? Am I missing
> > something ? Here is my dnsmasq config file contents:*
> >
> >
> >
> > /root@8320:~# cat /var/run/dnsmasq_swns/dnsmasq6.conf/
> >
> > //
> >
> > /enable-ra/
> >
> > //
> >
> > /log-dhcp/
> >
> > //
> >
> > /log-queries/
> >
> > //
> >
> > /log-facility=/var/log/dnsmasq_swns/dnsmasq6.log/
> >
> > //
> >
> > /port=0/
> >
> > //
> >
> > /dhcp-script=/usr/bin/dhcp_server_leases/
> >
> > //
> >
> > /leasefile-ro/
> >
> > //
> >
> > /dhcp-lease-max=64000/
> >
> > //
> >
> > /dhcp-range=set:default+test,2020::10,2020::20,120/
> >
> >
> >
> > Thanks
> >
> > -Sandeep
> >
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
> 

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Simon Kelley]

It would be useful to get full packet dumps rather than just tcpdump
output.

It would also be useful to run dnsmasq under strace and see what
syscalls it's making: that would tell use where the reply might be going.


Cheers,

Simon.




On 03/01/2019 07:41, Sandeep K M wrote:
> Hi All,
> 
>  
> 
> I have a simple setup with a relay agent as shown below:
> 
> 
> +--+-+
> |    dnsmasq server |
> 
> |     (ubuntu) |
> 
> +-+
>     | m1s1p7 (1040::2/120)
>             | (IP route : 2020::/120 via 1040::1 dev m1s1p7  proto
> static  metric 512  pref medium)
>             |
>     |
>     | 1/1/2 (1040::1/120)
> +--++
> |    Switch    |
> | (Relay Agent )  |
> +---+
>     | 1/1/1 (2020::1/120) 
>         |
>     | 
>     | eth1 
> +--+--+
> | Client (Ubuntu)  |
> +--+
> 
> 
> It is exactly the same as explained in the video :
> https://www.youtube.com/watch?v=2Lt1aXpCzvQ
> 
> 
> Whenever the client is requesting an IPv6 address dnsmasq is failing to
> respond with “DHCPADVERTISE” message. The “DHCPADVERTISE” has not been
> sent via the interface. The tcpdump clearly shows that “DHCPADVERTISE”
> message has not gone through the interface (m1s1p7), its only showing
> the “DHCPSOLICIT” message which has been received:
> 
>  
> 
> /root@8320:~# tcpdump -i *m1s1p7* udp port 547 or 546 -vvv -n/
> 
> //
> 
> /tcpdump: listening on m1s1p7, link-type EN10MB (Ethernet), capture size
> 262144 bytes/
> 
> //
> 
> / /
> 
> //
> 
> /06:32:37.214798 IP6 (hlim 64, next-header UDP (17) payload length: 110)
> 2020::1.547 > 1040::2.547: [udp sum ok] dhcp6 relay-fwd
> (linkaddr=2020::1 peeraddr=fe80::250:56ff:febd:7c93 (relay-message
> (*dhcp6 solicit* (xid=1894f2 (client-ID hwaddr/time type 1 time
> 599811159 005056bd7c93) (option-request DNS-server DNS-search-list
> Client-FQDN SNTP-servers) (elapsed-time 0) (IA_NA IAID:1455258771
> T1:3600 T2:5400))) (interface-ID 0024...))/
> 
>  
> 
> But the dnsmasq logs shows that it is trying to send the “DHCPADVERTISE”
> message but for some reason it’s not been sent via the interface *m1s1p7. *
> 
> * *
> 
> **
> 
> /root@8320:~# tail -f /var/log/dnsmasq_swns/dnsmasq6.log/
> 
> //
> 
> /Jan  3 06:11:20 dnsmasq[4151]: started, version 2.78 DNS disabled/
> 
> //
> 
> /Jan  3 06:11:20 dnsmasq[4151]: compile time options: IPv6 GNU-getopt
> no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
> no-DNSSEC loop-detect inotify/
> 
> /Jan  3 06:11:20 dnsmasq-dhcp[4151]: DHCPv6, IP range 2020::10 --
> 2020::20, lease time 1h/
> 
> /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPSOLICIT(m1s1p7)
> 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> 
> //
> 
> /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPADVERTISE(m1s1p7) 2020::12
> 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> 
>  
> 
> *Does anyone has any clue on what is going on here ? Am I missing
> something ? Here is my dnsmasq config file contents:*
> 
>  
> 
> /root@8320:~# cat /var/run/dnsmasq_swns/dnsmasq6.conf/
> 
> //
> 
> /enable-ra/
> 
> //
> 
> /log-dhcp/
> 
> //
> 
> /log-queries/
> 
> //
> 
> /log-facility=/var/log/dnsmasq_swns/dnsmasq6.log/
> 
> //
> 
> /port=0/
> 
> //
> 
> /dhcp-script=/usr/bin/dhcp_server_leases/
> 
> //
> 
> /leasefile-ro/
> 
> //
> 
> /dhcp-lease-max=64000/
> 
> //
> 
> /dhcp-range=set:default+test,2020::10,2020::20,120/
> 
>  
> 
> Thanks
> 
> -Sandeep
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

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