Documentation > Miscellaneous > FAQ
Troubleshooting/FAQ
This sums up problems we’ve seen users run into.
I modprobed Jool but it doesn’t seem to be doing anything.
Modprobing Jool without enough arguments is legal. It will assume you intend to finish configuring using the userspace app, and sit idle until you’ve done so.
Use the userspace app’s --global
flag to figure out Jool’s status:
$ jool_siit --global
Status: Disabled
$ jool --global
Status: Disabled
SIIT Jool’s minimum configuration requirements are
- A prefix in the IPv6 pool or at least one entry in the EAM table.
- You must have not manually disabled it.
Stateful Jool’s minimum configuration requirements are
- At least one prefix in the IPv6 pool.
- At least one prefix/address in the IPv4 pool.
- You must have not manually disabled it.
If that doesn’t seem to be the problem, try the logs.
What do I do with this error message? It’s horribly ambiguous.
This happens if your text terminal is not listening to kernel messages of error severity.
The jist of it is, if a problem with the incoming configuration is detected in kernelspace, Jool doesn’t send the friendly version of the error message to the userspace application because it’s lazy. Instead, it writes it in the kernel logs. The userspace application is then stuck with a generic Unix error code, and that’s what it reports to the user.
Run dmesg
or one of its variats to query the kernel logs, as shown in the issue report.
Jool is intermitently unable to translate traffic.
Did you run something in the lines of
ip addr flush dev eth1
?
Then you might have deleted the interface’s Link address.
Link addresses are used by several relevant IPv6 protocols. In particular, they are used by the Neighbor Discovery Protocol, which means if you don’t have them, the translating machine will have trouble finding its IPv6 neighbors.
Check the output of ip addr
.
user@T:~$ /sbin/ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:83:d9:40 brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:aaaa::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe83:d940/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:c6:01:48 brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:bbbb::1/64 scope global tentative
valid_lft forever preferred_lft forever
Interface eth0 is correctly configured; it has both a “scope global” address (used for typical traffic) and a “scope link” address (used for internal management). Interface eth1 lacks a link address, and is therefore a headache inducer.
The easiest way to restore scope link addresses, we have found, is to just reset the interface:
ip link set eth1 down
ip link set eth1 up
Yes, I’m serious:
user@T:~$ /sbin/ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:83:d9:40 brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:aaaa::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe83:d940/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:c6:01:48 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a00:27ff:fec6:148/64 scope link
valid_lft forever preferred_lft forever
(Note, you need to add the global address again)
Also, for future reference, keep in mind that the “correct” way to flush an interface is
ip addr flush dev eth1 scope global
IPv4 doesn’t need link addresses that much.
The throughput is terrible!
If you’re running Jool in a guest virtual machine, something important to keep in mind is that you might rather or also have to disable offloads in the VM host’s uplink interface.