Forum - FreeBSD 6.2 not connecting :: SixXS - IPv6 Deployment & Tunnel Broker

FreeBSD 6.2 not connecting

Shadow Hawkins on Saturday, 14 February 2009 15:23:14

hello, I'm getting this error message from /var/log/messages: Feb 14 15:12:08 cuba sixxs-aiccu: Buffer almost flowed over without receiving a newline Feb 14 15:12:08 cuba sixxs-aiccu: Couldn't retrieve first tunnel for the above reason, aborting The tunnel has been approved. I can telnet to the tic.sixxs.net server. ta, t.

FreeBSD 6.2 not connecting

Shadow Hawkins on Thursday, 19 September 2013 12:02:19

tim matthews wrote:

Feb 14 15:12:08 cuba sixxs-aiccu: Buffer almost flowed over without receiving a newline Feb 14 15:12:08 cuba sixxs-aiccu: Couldn't retrieve first tunnel for the above reason, aborting

Very old post, but maybe still useful for others. I recently noticed that error too and I found not anything about it online. The config is correct, since it worked in other networks, only in one network there was this problem. In this specific network was a Websense server running. He was sending RST packets. aiccu client showed this with verbose true. # aiccu tunnels sock_getline() : "200 SixXS TIC Service on nlhaa01.sixxs.net ready (http://www.sixxs.net)" sock_printf() : "client TIC/draft-00 AICCU/2007.01.15-console-linux Linux/2.6.18-308.13.1.el5" sock_getline() : "200 Client Identity accepted" sock_printf() : "get unixtime" Buffer almost flowed over without receiving a newline The tcpdump without the payload looked like this here. 13:17:08.233228 IP 10.115.26.7.38169 > 94.75.219.73.sixxsconfig: S 3953066170:3953066170(0) win 5840 <mss 1460,sackOK,timestamp 162172520 0,nop,wscale 2> 13:17:08.241804 IP 94.75.219.73.sixxsconfig > 10.115.26.7.38169: S 3982176496:3982176496(0) ack 3953066171 win 14480 <mss 1380,sackOK,timestamp 2222217713 162172520,nop,wscale 10> 13:17:08.242148 IP 10.115.26.7.38169 > 94.75.219.73.sixxsconfig: . ack 1 win 1460 <nop,nop,timestamp 162172529 2222217713> 13:17:08.379076 IP 94.75.219.73.sixxsconfig > 10.115.26.7.38169: P 1:73(72) ack 1 win 15 <nop,nop,timestamp 2222217748 162172529> 13:17:08.379218 IP 10.115.26.7.38169 > 94.75.219.73.sixxsconfig: . ack 73 win 1460 <nop,nop,timestamp 162172666 2222217748> 13:17:08.379424 IP 10.115.26.7.38169 > 94.75.219.73.sixxsconfig: P 1:78(77) ack 73 win 1460 <nop,nop,timestamp 162172666 2222217748> 13:17:08.387946 IP 94.75.219.73.sixxsconfig > 10.115.26.7.38169: . ack 78 win 15 <nop,nop,timestamp 2222217750 162172666> 13:17:08.388580 IP 94.75.219.73.sixxsconfig > 10.115.26.7.38169: P 73:102(29) ack 78 win 15 <nop,nop,timestamp 2222217750 162172666> 13:17:08.388860 IP 10.115.26.7.38169 > 94.75.219.73.sixxsconfig: P 78:91(13) ack 102 win 1460 <nop,nop,timestamp 162172675 2222217750> 13:17:08.389063 IP 94.75.219.73.sixxsconfig > 10.115.26.7.38169: R 3982176598:3982176598(0) win 0 That "R" at the end came from internal. We verified that on the firewall in that network. I'm sure Websense has "http://www.sixxs.net" in it's filter list.

FreeBSD 6.2 not connecting

Jeroen Massar SixXS Staff

on Thursday, 19 September 2013 12:19:04

That "R" at the end came from internal. We verified that on the firewall in that network.

How did you 'verify' this? Note that AICCU will close the connection when buffers are overflowing (eg from a too long response etc). And in the pcap output there is clearly a packet going back, thus that might be the close request. Note that the server-side indeed will close it on receipt of a 'quit' command.

The tcpdump without the payload looked like this here.

It would be very useful if you can send a *full* pcap, thus including payload of full packets, to info@sixxs.net. Then we can have a better peek at this.

I'm sure Websense has "http://www.sixxs.net" in it's filter list.

TIC is not HTTP. Thus that sentence does not make sense. Instead of blaming an organisation without proper evidence, please do proper research. An easy question there would be to check if you can access that URL...

FreeBSD 6.2 not connecting

Shadow Hawkins on Monday, 23 September 2013 15:59:15

Jeroen Massar wrote:

> That "R" at the end came from internal. We verified that on the firewall in that network. How did you 'verify' this?

I talked with the firewall admin and he checked the logs live and he did not see the RST packet coming from your server. He said it came from internal.

Note that AICCU will close the connection when buffers are overflowing (eg from a too long response etc). And in the pcap output there is clearly a packet going back, thus that might be the close request. Note that the server-side indeed will close it on receipt of a 'quit' command.

I'm sure the response on "get unixtime" should not be too long. Because that's when the rst comes.

> The tcpdump without the payload looked like this here. It would be very useful if you can send a *full* pcap, thus including payload of full packets, to info@sixxs.net. Then we can have a better peek at this.

I can send you the full pcap file.

> I'm sure Websense has "http://www.sixxs.net" in it's filter list. TIC is not HTTP. Thus that sentence does not make sense. Instead of blaming an organisation without proper evidence, please do proper research. An easy question there would be to check if you can access that URL...

Yes, the statement that "http://www.sixxs.net" is in the filter and the reason is wrong, since I can access the site. It may blocks it for whatever reason. I don't know what aiccu does all under the hood, but I was certain that websense is the reason, since it worked fine from another subnet, where no websense is monitoring traffic. I also just did two other tests. First I telnet'd to the tic server and the rst comes after "get unixtime". I also did a telnet to my own web server on port 80, where I can run a tcpdump. Yes, it's a different protocol, but as soon as I use a lowercase "get" and hit enter, I also receive a rst packet, which does not come from my web server. That all leads me to websense. Whatever it is doing. So that "get unixtime" after establishing the secure connection in aiccu would be nice.

FreeBSD 6.2 not connecting

Jeroen Massar SixXS Staff

on Monday, 23 September 2013 16:05:09

Marco Schirrmeister wrote:

First I telnet'd to the tic server and the rst comes after "get unixtime". I also did a telnet to my own web server on port 80, where I can run a tcpdump. Yes, it's a different protocol, but as soon as I use a lowercase "get" and hit enter, I also receive a rst packet, which does not come from my web server. That all leads me to websense. Whatever it is doing.

So that "get unixtime" after establishing the secure connection in aiccu would be nice.

One of the many for the 'get unixtime' is so that the client can check if the local time is correct compared with the TIC server time, this as crypto won't work without it. Thus doing SSL in front of it would not work then anyway... The in-svn version of AICCU even has an option for changing the localtime based on the time of the TIC server as way too many hosts seem to have broken clocks and it seems lots of them do not understand how to get NTP synced on them. (not that syncing it once does not cause the clock to drift in the long run...)

FreeBSD 6.2 not connecting

Shadow Hawkins on Monday, 23 September 2013 20:43:50

Jeroen Massar wrote:

Ok, I see. Is there maybe at least a chance to implement something, that would say the connection was reseted or interrupted in a not normal way? It was really driving me nuts to find the real reason. Because of that error I first thought it is somehow OS related and something is not compatible, or wrong config.

Please note Posting is only allowed when you are logged in.