Hi all,
It's probably only me, but I can't connect to a kgdb host because
of bouncing ICMP unreachables. I'll be glad if you could take a look
to see if it's a bug or not.
Details:
- running a cloned version of kgdb_2.6.23 branch of Jason's
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
- "modprobe kgdboe kgdboe='@10.0.0.28/,@10.0.0.11/'" works fine,
and var/log/messages get filled with six kgdboe network configuration
messages (local port 6443, local ip 10.0.0.28, interface eth0,
remote port 6442, remote ip 10.0.0.11, remote mac ff:ff:ff:ff:ff:ff).
- "netstat -aun" does not show an open 6643 UDP port (should it ?)
- When trying to connect via remote gdb, I get a connection refused:
(gdb) target remote udp:10.0.0.28:6433
warning: The remote protocol may be unreliable over UDP.
Some events may be lost, rendering further debugging impossible.
Remote debugging using udp:10.0.0.28:6433
Remote communication error: Connection refused.
- tcpdump ouput shows two UDP messages traveling to the kgdb host
only to immediately invoke ICMP unreachables:
19:30:53.424248 IP 10.0.0.11.32785 > 10.0.0.28.6433: UDP, length 5
19:30:53.424323 IP 10.0.0.11.32785 > 10.0.0.28.6433: UDP, length 14
19:30:53.426292 IP 10.0.0.28 > 10.0.0.11: ICMP 10.0.0.28 udp port 6433
unreachable, length 41
19:30:53.427542 IP 10.0.0.28 > 10.0.0.11: ICMP 10.0.0.28 udp port 6433
unreachable, length 50
- Network between 10.0.0.28 and 10.0.0.11 is just fine; I successfully work
on NFS mounts (with 10.0.0.28 as a client)
- the kgdb host has selinux=0 and iptables with accept-all policies
- i386 (running inside a bridged qemu/vmplayer host)
- config attached
If you have any idea how to further debug this problem,
or maybe if you know if I did something wrong,
please share !
Thanks,
naziir.
On Thu, Dec 06, 2007 at 08:22:15PM +0200, Ramagudi Naziir wrote:
> Hi all,
>
> It's probably only me, but I can't connect to a kgdb host because
> of bouncing ICMP unreachables. I'll be glad if you could take a look
> to see if it's a bug or not.
>
> Details:
> - running a cloned version of kgdb_2.6.23 branch of Jason's
> git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
>
> - "modprobe kgdboe kgdboe='@10.0.0.28/,@10.0.0.11/'" works fine,
> and var/log/messages get filled with six kgdboe network configuration
> messages (local port 6443, local ip 10.0.0.28, interface eth0,
> remote port 6442, remote ip 10.0.0.11, remote mac ff:ff:ff:ff:ff:ff).
...
> 19:30:53.424248 IP 10.0.0.11.32785 > 10.0.0.28.6433: UDP, length 5
> 19:30:53.424323 IP 10.0.0.11.32785 > 10.0.0.28.6433: UDP, length 14
Hmmm, 6443 != 6433 (typo?) and 32785 != 6442 (config problem). Yes,
netpoll will ignore incoming UDP -from- the wrong port/ip/mac, since
it's otherwise bypassing the firewall layer. And of course, it won't
accept packets -to- the wrong address either. I forget how to deal
with the source address issue in connection with GDB, perhaps Jason
will remind us.
--
Mathematics is the supreme nostalgia of our time.
On 12/6/07, Matt Mackall <[email protected]> wrote:
> On Thu, Dec 06, 2007 at 08:22:15PM +0200, Ramagudi Naziir wrote:
> > It's probably only me, but I can't connect to a kgdb host because
> > of bouncing ICMP unreachables. I'll be glad if you could take a look
...
> Hmmm, 6443 != 6433 (typo?) and 32785 != 6442 (config problem). Yes,
...
Sigh (I had both...).
Thank you, Matt, SO much (it's been a long day :).
Now everything works just great !
naziir
On 12/6/07, Matt Mackall <[email protected]> wrote:
> netpoll will ignore incoming UDP -from- the wrong port/ip/mac, since
> it's otherwise bypassing the firewall layer.
...
> I forget how to deal
> with the source address issue in connection with GDB, perhaps Jason
> will remind us.
I have checked it out.
Seems like there is absolutely no way to configure the source
port gdb uses for the udp connection. So one must invoke a
"target remote udp:ip:port" command, see what was the
chosen source port (tcpdump/netstat), and reconfigure kgdb on the target.
While this works, it is rather awkward.
Do you think there is/can be another way to solve this issue
(like allowing NETPOLL to listen to a wildcard udp source port) ?
thank you
naziir
>
> --
> Mathematics is the supreme nostalgia of our time.
>
Ramagudi Naziir wrote:
> On 12/6/07, Matt Mackall <[email protected]> wrote:
>
>> netpoll will ignore incoming UDP -from- the wrong port/ip/mac, since
>> it's otherwise bypassing the firewall layer.
>>
> I have checked it out.
> Seems like there is absolutely no way to configure the source
> port gdb uses for the udp connection. So one must invoke a
> "target remote udp:ip:port" command, see what was the
> chosen source port (tcpdump/netstat), and reconfigure kgdb on the target.
> While this works, it is rather awkward.
>
> Do you think there is/can be another way to solve this issue
> (like allowing NETPOLL to listen to a wildcard udp source port) ?
>
>
What module parameters did you pass to kgdboe and what kernel are you
using and are you using the kgdb source forge patches?
I had not looked to see if anything changed in the latest net poll api,
but previously with the 2.6.21 kernel as example, the net poll api
ignored the source port parameter entirely. If this has changed, I
would be happy to make a further change to zero out the port or do what
is needed to make it dynamic again, in a similar fashion to the way the
MAC address parsing is dynamic for KGDB + the net poll api.
Jason.
Also you can omit the linux-kernel mailling and take this up at:
[email protected] if you are using the source forge
patches.
On 12/19/07, Jason Wessel <[email protected]> wrote:
> What module parameters did you pass to kgdboe and what kernel are you
> using and are you using the kgdb source forge patches?
I am running the kgdb_2.6.23 branch of your kgdb git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git).
my kgdb parameter is "[email protected]/,[email protected]/",
where 10.0.0.28 is my target and 10.0.0.11 is the host running gdb.
I have to sniff gdb in order to find out the value of 32323...
> I had not looked to see if anything changed in the latest net poll api,
> but previously with the 2.6.21 kernel as example, the net poll api
> ignored the source port parameter entirely. If this has changed, I
I don't know about 2.6.21, but now it seems that NETPOLL do not
ignore the source port.
> would be happy to make a further change to zero out the port or do what
> is needed to make it dynamic again, in a similar fashion to the way the
> MAC address parsing is dynamic for KGDB + the net poll api.
Oh that would be great.
Thanks,
naziir
>
> Jason.
>
> Also you can omit the linux-kernel mailling and take this up at:
> [email protected] if you are using the source forge
> patches.
I didn't find source forge patches that are still applicable to nowadays
kernels, so I am using your git tree.
>
On Wed, Dec 19, 2007 at 06:22:55PM +0200, Ramagudi Naziir wrote:
> On 12/6/07, Matt Mackall <[email protected]> wrote:
> > netpoll will ignore incoming UDP -from- the wrong port/ip/mac, since
> > it's otherwise bypassing the firewall layer.
> ...
> > I forget how to deal
> > with the source address issue in connection with GDB, perhaps Jason
> > will remind us.
>
> I have checked it out.
> Seems like there is absolutely no way to configure the source
> port gdb uses for the udp connection. So one must invoke a
> "target remote udp:ip:port" command, see what was the
> chosen source port (tcpdump/netstat), and reconfigure kgdb on the target.
> While this works, it is rather awkward.
>
> Do you think there is/can be another way to solve this issue
> (like allowing NETPOLL to listen to a wildcard udp source port) ?
Here are the checks from net/core/netpoll.c:__netpoll_rx:
if (np->local_ip && np->local_ip != ntohl(iph->daddr))
goto out;
if (np->remote_ip && np->remote_ip != ntohl(iph->saddr))
goto out;
if (np->local_port && np->local_port != ntohs(uh->dest))
goto out;
In other words, we DON'T check remote_port and we don't check the
local_port, local_ip, or remote_ip if they're zero. Sorry for the
earlier confusion.
My hazy memory here is that my version of kgdboe took the first packet
it got and set remote_port from it so that it could reply. Not sure
whether that got copied as I can't seem to find the relevant bits in
the latest -mm.
--
Mathematics is the supreme nostalgia of our time.