|
AICCU fails DHCP request ?
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Sunday, 07 October 2012 21:26:29
I am a long term user of Gentoo and aiccu runs like a dream. I have just installed Fedora v17 on my LapTop and it just bombs. I collected a load of info and sent it to info@sixxs.net as an attachment.
Apparently it was never read and I was told continuously told to pue a question on the "forum"! I have expanded the information and supply it below. I do hope it not only gets read, but that I actually receive a sensible an usable reply.
In fact, having just read the "fun" with OpenWRT, I would really like to know how I can implement the whole thing in the Fritz!BOX's own TIC-client.
NIC-handle:PDK7-SIXXS
Tunnel Id : T46537
PoP Name : nlams05 (nl.surfnet [AS1103])
TIC Server : tic.sixxs.net (which is the default in AICCU)
Your Location : sGravenhage, nl
Tunnel Type : Dynamic (ayiya)
## Command
[root@lt1-tst ~]# uname -a
Linux lt1-tst 3.5.4-2.fc17.x86_64 #1 SMP Wed Sep 26 21:58:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@lt1-tst ~]#
[root@lt1-tst ~]# aiccu version ; echo "Exit(${?})"
AICCU 2007.01.15-console-linux by Jeroen Massar
Exit(0)
[root@lt1-tst ~]#
[root@lt1-tst ~]# ntpdate -4v pool.ntp.org
7 Oct 17:58:35 ntpdate[23893]: ntpdate 4.2.6p5@1.2349-o Fri Apr 27 08:36:47 UTC 2012 (1)
7 Oct 17:58:44 ntpdate[23893]: adjust time server 85.12.35.12 offset -0.003112 sec
[root@lt1-tst ~]#
[root@lt1-tst ~]# aiccu autotest ; echo "Exit(${?})"
Exit(255)
[root@lt1-tst ~]# dig nlams05.sixxs.net any
; <<>> DiG 9.9.1-P3-RedHat-9.9.1-9.P3.fc17 <<>> nlams05.sixxs.net any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32936
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nlams05.sixxs.net.INANY
;; ANSWER SECTION:
nlams05.sixxs.net.3600INA192.87.102.107
nlams05.sixxs.net.3600INAAAA2001:610:1:80bb:192:87:102:107
nlams05.sixxs.net.3600INTXT"SURFnet, Amsterdam, Netherlands, The"
;; AUTHORITY SECTION:
sixxs.net.3244INNSns.paphosting.net.
sixxs.net.3244INNSns.paphosting.nl.
sixxs.net.3244INNSns.paphosting.eu.
;; Query time: 88 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Oct 7 17:30:29 2012
;; MSG SIZE rcvd: 227
[root@lt1-tst ~]# ping -c 3 nlams05.sixxs.net
PING nlams05.sixxs.net (192.87.102.107) 56(84) bytes of data.
64 bytes from sixxs.surfnet.nl (192.87.102.107): icmp_req=1 ttl=56 time=83.9 ms
64 bytes from sixxs.surfnet.nl (192.87.102.107): icmp_req=2 ttl=56 time=40.7 ms
64 bytes from sixxs.surfnet.nl (192.87.102.107): icmp_req=3 ttl=56 time=9.75 ms
--- nlams05.sixxs.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2115ms
rtt min/avg/max/mdev = 9.750/44.801/83.926/30.419 ms
[root@lt1-tst ~]#
[root@lt1-tst ~]# traceroute -s 1500 nlams05.sixxs.net
traceroute to nlams05.sixxs.net (192.87.102.107), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@lt1-tst ~]#
[root@lt1-tst ~]# traceroute -6s 1500 nlams05.sixxs.net
1500: Address family for hostname not supported
Cannot handle `-s' option with arg `1500' (argc 2)
[root@lt1-tst ~]#
## /var/log/messages (snippet)
8649 Oct 4 17:03:51 lt1-tst aiccu: Couldn't resolve host , service 3874
8650 Oct 4 17:03:51 lt1-tst aiccu: Couldn't connect to the TIC server
8651 Oct 4 17:03:51 lt1-tst aiccu: Couldn't retrieve first tunnel for the above reason, aborting
## /etc/services (snippet)
7160 sixxsconfig 3874/tcp # SixXS Configuration
7161 sixxsconfig 3874/udp # SixXS Configuration
## Additional Info (command)
[root@lt1-tst ~]# dig tic.sixxs.net any
; <<>> DiG 9.9.1-P3-RedHat-9.9.1-9.P3.fc17 <<>> tic.sixxs.net any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9526
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;tic.sixxs.net.INANY
;; ANSWER SECTION:
tic.sixxs.net.3600INA213.204.193.2
tic.sixxs.net.3600INA94.75.219.73
;; Query time: 156 msec
;; SERVER: 10.254.0.1#53(10.254.0.1)
;; WHEN: Thu Oct 4 17:12:44 2012
;; MSG SIZE rcvd: 63
[root@lt1-tst ~]#
## Notes
0:/etc/aiccu.conf [T46537] is as you would expect, except defaults set (not comment), including "Behind NAT Frirewall" (NAT-only).
1:This is a Dell Latitude D820 (Laptop) with Intel T7600 CPU, 4GiB Memory and Fedora v17 (Beefy Miracle) Linux.
2:Desktop is ASUS ???? Motherboard, AMD PHenon X4 CPU, 4 GiB Memory and Gentoo V2.Ref Policy (SELinux) Linux.
3:Works on Gentoo, tried it yesterday or just before, all OK.
4:10.254.0.1 is a "!FRITZ Box" (aka ADSL modem) From Scarlet Internet Services, Lelystad, NL.
## SIXXS Info
Netherlands, The (.nl)Netherlands, The
AmsterdamUpnlams04Scarlet Internet B.V.
AmsterdamUpnlams05SURFnet
5:I was registered on "SURFNet" - as far as I know Scarlet is a newbie, but I suppoae it should be that now.
## Link Dump
[root@lt1-tst ~]# tcpdump -A -b -e -f -i eth0 -n -N -s 1500 -xx -XX -z pim |& tee aiccu.log
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
18:42:07.381231 00:19:b9:64:db:b2 > Broadcast, ethertype IPv4 (0x0800), length 154: 10.253.0.81.db-lsp-disc > 255.255.255.255.db-lsp-disc: UDP, length 112
0x0000: ffff ffff ffff 0019 b964 dbb2 0800 4500 .........d....E.
0x0010: 008c 0000 4000 4011 2f14 0afd 0051 ffff ....@.@./....Q..
0x0020: ffff 445c 445c 0078 0bd7 7b22 686f 7374 ..D\D\.x..{"host
0x0030: 5f69 6e74 223a 2033 3438 3138 3339 3139 _int":.348183919
0x0040: 2c20 2276 6572 7369 6f6e 223a 205b 312c ,."version":.[1,
0x0050: 2038 5d2c 2022 6469 7370 6c61 796e 616d .8],."displaynam
0x0060: 6522 3a20 2233 3438 3138 3339 3139 222c e":."348183919",
0x0070: 2022 706f 7274 223a 2031 3735 3030 2c20 ."port":.17500,.
0x0080: 226e 616d 6573 7061 6365 7322 3a20 5b31 "namespaces":.[1
0x0090: 3639 3734 3632 3433 5d7d 69746243]}
18:42:07.384156 00:19:b9:64:db:b2 > Broadcast, ethertype IPv4 (0x0800), length 154: 10.253.0.81.db-lsp-disc > 10.253.0.255.db-lsp-disc: UDP, length 112
0x0000: ffff ffff ffff 0019 b964 dbb2 0800 4500 .........d....E.
0x0010: 008c 0000 4000 4011 2318 0afd 0051 0afd ....@.@.#....Q..
0x0020: 00ff 445c 445c 0078 17d3 7b22 686f 7374 ..D\D\.x..{"host
0x0030: 5f69 6e74 223a 2033 3438 3138 3339 3139 _int":.348183919
0x0040: 2c20 2276 6572 7369 6f6e 223a 205b 312c ,."version":.[1,
0x0050: 2038 5d2c 2022 6469 7370 6c61 796e 616d .8],."displaynam
0x0060: 6522 3a20 2233 3438 3138 3339 3139 222c e":."348183919",
0x0070: 2022 706f 7274 223a 2031 3735 3030 2c20 ."port":.17500,.
0x0080: 226e 616d 6573 7061 6365 7322 3a20 5b31 "namespaces":.[1
0x0090: 3639 3734 3632 3433 5d7d 69746243]}
18:42:13.351239 00:19:b9:64:db:b2 > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:19:b9:64:db:b2, length 300
0x0000: ffff ffff ffff 0019 b964 dbb2 0800 4500 .........d....E.
0x0010: 0148 0001 0000 3c11 7da5 0000 0000 ffff .H....<.}.......
0x0020: ffff 0044 0043 0134 2f5d 0101 0600 1201 ...D.C.4/]......
0x0030: 9719 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 0019 b964 dbb2 0000 0000 .........d......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 013d 0701 ......c.Sc5..=..
0x0120: 0019 b964 dbb2 ff00 0000 0000 0000 0000 ...d............
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 ......
18:42:13.353086 00:4f:67:00:df:ba > Broadcast, ethertype IPv4 (0x0800), length 352: 10.253.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 310
0x0000: ffff ffff ffff 004f 6700 dfba 0800 4500 .......Og.....E.
0x0010: 0152 3f39 0000 8011 ef64 0afd 0001 ffff .R?9.....d......
0x0020: ffff 0043 0044 013e 34b0 0201 0600 1201 ...C.D.>4.......
0x0030: 9719 0000 0000 0000 0000 0afd 0051 0afd .............Q..
0x0040: 0001 0000 0000 0019 b964 dbb2 0000 0000 .........d......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00
^C
[root@lt1-tst ~]#
## Network
[root@lt1-tst ~]# ifconfig ; route -nNv
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.253.0.81 netmask 255.255.255.0 broadcast 10.253.0.255
inet6 fe80::219:b9ff:fe64:dbb2 prefixlen 64 scopeid 0x20<link>
ether 00:19:b9:64:db:b2 txqueuelen 1000 (Ethernet)
RX packets 142312466 bytes 215905382626 (201.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 74695144 bytes 5339092867 (4.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 141121 bytes 9777842 (9.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 141121 bytes 9777842 (9.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 10.1.0.81 netmask 255.255.255.0 broadcast 10.1.0.255
ether 52:54:00:4c:5a:60 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.253.0.1 0.0.0.0 UG 0 0 0 eth0
10.1.0.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
10.253.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
[root@lt1-tst ~]#
## Network additinal
10.253.0.1:
+ Basic Setting
+ Port Forwarding
+ Firewall Setting
+ Advanced Setting
+ Maintenance
System Status
Item WAN Status Sidenote
Remaining Lease Time 121:29:57
IP Address 10.254.0.254
Subnet Mask255.255.255.0
Gateway10.254.0.1
Domain Name Server10.254.0.1
Statistics of WANInboundOutbound
Octets2014219801 2940643041
Unicast Packets52903 61542
Non-unicast Packets10708 2
Item Setting
Wireless MAC Address 00-4F-67-00-DF-BA
Network ID(SSID)pdnet.eu
Channel4
Security TypeWPA2-PSK(AES)
DDNS ProviderDynDNS.org(Dynamic)
System Time: Sun Oct 07 16:50:07 2012
Firmware Upgrade
Firmware Filename
Current firmware version is R1.97g8-R61-MBSSID. The upgrade procedure takes about 20 seconds. Note! Do not power off the unit when it is being upgraded. When the upgrade is done successfully, the unit will be restarted automatically.
10.254.0.1:
Start Menu
Settings
Log off Overview Contents Help
Overview
Calls
Telephone Book
Telephony Devices
Network
Event Log
Overview
Product Information
FRITZ!Box Fon WLAN 7113 Annex A Firmware version 90.04.84
Interface Information
DSL
ready
WLAN
enabled, secured, no WLAN station registered
LAN
connected (LAN)
Connection Information
Internet
The FRITZ!Box uses a direct IP connection to an Internet Service Provider. IP address: 213.204.210.59
Internet telephony Number 0707070242, registered
Convenience Features
Night Service enabled from 23:00 until 07:00 WLAN will be switched off - Do Not Disturb is active.
Remote access enabled, https://213.204.210.59:999, User name: nobody
INFO display blinks for incoming calls during absence.
Connenction by 60:FB:42:DE:CF:32 refused.
AICCU fails DHCP request ?
Shadow Hawkins on Sunday, 07 October 2012 22:23:11
Additional info
I just wandered around a bit - I know I am just plain nosy!
Anyway, I happened to notice that I have a named "Router" entry, which was disabled. I have enabled it.
I am also very impatient, so I tested it right-away. Just the same. I guess I will just have to wait another 15 mins (min) and try, try again.
AICCU fails DHCP request ?
![[fi]](/s/countries/fi.gif) Shadow Hawkins on Monday, 08 October 2012 02:33:55
Did the autotest produce any output? It should go trough a number of steps to verify the needed services are working and output a log of the steps.
AICCU fails DHCP request ?
It seems gentoo builds do something weird as the autotest results do not print out anything but apparently things do go to syslog... normally there would be output though as daemonize is disabled and verbosity gets turned on...
AICCU fails DHCP request ?
I collected a load of info and sent it to info@sixxs.net as an attachment. Apparently it was never read and I was told continuously told to pue a question on the "forum"!
For the record, it was read, and we replied to every single one of your mails.
That you are unable to read the links that we kindly point you to, or that you do not seem to understand that info@sixxs.net is not a helpdesk, is not our problem.
Note that your subject of "AICCU fails DHCP request" is quite bogus as AICCU has nothing to do with DHCP, unless you think that TIC is the DHCP for a tunnel which is partially correct in a way.
But it seems that you finally understand that we indeed do not help you there, no matter how many mails you try to send, as we do not have the time for that, there are lots of other things that we need to do.
But to give you a little hint, a detail you omitted in your "load of info":
## /var/log/messages (snippet) 8649 Oct 4 17:03:51 lt1-tst aiccu: Couldn't resolve host , service 3874 8650 Oct 4 17:03:51 lt1-tst aiccu: Couldn't connect to the TIC server 8651 Oct 4 17:03:51 lt1-tst aiccu: Couldn't retrieve first tunnel for the above reason, aborting
Don't you find it weird that there is no hostname after the 'Couldn't resolve host' portion, as normally there is a hostname there. You might want to check your aiccu.conf and either comment out the server line or configure it properly, that is put a valid hostname for a real TIC server there (default: tic.sixxs.net).
AICCU fails DHCP request ?
Shadow Hawkins on Monday, 08 October 2012 14:43:37
Do you find?
NO! Why should I _ I do not posses a "Messages and Codes" for AICCU, etc.
How would I actually know that the message is supposed to contain an Host-Name?
I commented out the "server tic.sixxs.net" statement and tried yet once more - bingo, up in the air again - fantastic.
So what is the current name of the TIC-Server? Where would one find it? How does one get notified about such minor changes?
And, no, I am not being silly! These are very real questions that any sensible user would ask.
DHCP?
Why on earth would I suddenly come-up with "bootp/DHCP" as being what is going wrong? Just because the "tcpdump" shows only these messages going back and forth. Something which, quite frabkly, frightened the hell out of me!
I just happen to be running on an O/S (Linux) and am I seriously asking just anyone on the internet to supply me with a "boot image" so I can get started? That is exactly what "bootp" is doing! I doubt that, so why on earth would I happen to think it just might be "DHCP"? Particularly as "aiccu" will need to know the external address (IPv4) to send out to the TIC-Server, something returned by DHCP's "Renew" request. Silly, silly me - I just completely know nothing of what, how or why ...
I reckon, if I am to believe your statements, you knew this from day one and could have said so.
Now I know why the impressive discourse on OpenWRT is so long and complicated.
Nonetheless, please accept my heartfelt thanks for finally pointing out the correct area for research.
Pim
AICCU fails DHCP request ?
How would I actually know that the message is supposed to contain an Host-Name?
Because the example configuration file delivered with AICCU has:
# Protocol and server to use for setting up the tunnel (default: tic.sixxs.net)
#protocol <tic|tsp|l2tp>
#server <server to use>
So what is the current name of the TIC-Server?
tic.sixxs.net
Where would one find it?
As shown above, it is documented in the example configuration file. Next to that it is shown in various places on the SixXS website including the FAQ.
How does one get notified about such minor changes?
There was no change, that DNS label has been the same since we deployed TIC along with AICCU some 8 years ago.
Something changed your configuration file, it was not SixXS though.
And, no, I am not being silly! These are very real questions that any sensible user would ask.
A sensible user would look at the provided documentation and the FAQ and would notice 'hey, that is odd'.
Just because the "tcpdump" shows only these messages going back and forth. Something which, quite frabkly, frightened the hell out of me!
But it has nothing to do with anything. Unfortunately we do not have a supply of happy teddybears to resolve your fears either.
Particularly as "aiccu" will need to know the external address (IPv4) to send out to the TIC-Server, something returned by DHCP's "Renew" request.
TIC does not care about the external IPv4 address.
And if something would need it DHCP would be rather bad to look for such a thing as that would be only contain the local IP address, better to just check the local interface configuration then, or heck, make an outbound connection and let the remote server figure out the address which is most likely behind NAT anyway in IPv4.
I reckon, if I am to believe your statements, you knew this from day one and could have said so.
Given the wrong things that you are insinuating it is really hard to make much sense at all from your statements.
AICCU fails DHCP request ?
Shadow Hawkins on Monday, 08 October 2012 14:56:02
A Silly Question
As you, above, state that the server name is tic.sixxs.net, I just checked that in my aiccu.conf.
Guess what? I had exactly that string. So why does this configuration fail and in such an invisible manner?
Could it be, that like any good bookkeeper, I like to keep things lined-up. How do I do that? Easy, I use "\t" aka TAB-character. This is normal accepted practice and is included in the definition of "white space". Does your conf-parser actually keep to the rules.
It is hard to know what the rules actually are. There are no man-pages, only internal comments.
AICCU fails DHCP request ?
I had exactly that string.
Obviously you had not, otherwise it would have worked.
This is normal accepted practice
But it is not how the AICCU configuration file works.
There are lots of configuration files which do not give one that freedom.
There are no man-pages, only internal comments.
There is a man page (doc/aiccu.1) and the configuration file shows exactly what it accepts and how it should be formatted.
That you try to do something else, well, your problem, nobody else has had a problem with it in the last 8 years and actually the parser used in AICCU has been re-used in several other projects, thus you'll find the same behaviour there too.
|
![[ch]](/s/countries/ch.gif)
on Monday, 08 October 2012 08:12:35
Posting is only allowed when you are