Hi!
nc shows some interessting behavior.
When listeing part running on the host itself I can write as many lines
of text to the server as I want.
20:33:03.489755 IP 192.168.1.24.32831 > 192.168.1.254.33020: UDP, length 5
20:33:05.352968 IP 192.168.1.24.32831 > 192.168.1.254.33020: UDP, length 5
20:33:06.345795 IP 192.168.1.24.32831 > 192.168.1.254.33020: UDP, length 5
20:33:07.393783 IP 192.168.1.24.32831 > 192.168.1.254.33020: UDP, length 5
20:33:08.513780 IP 192.168.1.24.32831 > 192.168.1.254.33020: UDP, length 5
Running the listeing part inside the vserver I can only write exactly
one line to the server. The second
line does not get to the server and the clients exits.
20:32:05.777390 IP 192.168.1.24.32830 > 192.168.1.223.33020: UDP, length 5
20:32:08.913378 IP 192.168.1.24.32830 > 192.168.1.223.33020: UDP, length 5
20:32:08.913409 IP 192.168.1.223 > 192.168.1.24: ICMP 192.168.1.223 udp
port 33020 unreachable, length 41
Something seems to interrupt the "connection", but what is it?
The setup is a normal debian testing box without any fancy software. I
also tried on antoher debian
testing box, no luck neither :(
Corin
Thomas Weber schrieb:
> Am Dienstag, den 19.02.2008, 16:09 +0100 schrieb Corin Langosch:
>
>> Hi!
>>
>> I added all caps, but it still does not work :-(
>>
>> buero:/etc/vservers# cat system/bcapabilities
>> NET_RAW
>> NET_BROADCAST
>> SYS_TIME
>> SYS_NICE
>> SYS_RESOURCE
>>
>> The caps must be set as the dhcp server inside the vserver is running
>> fine, which
>> wont without the caps.
>>
>> No tftp server is not running inside the host, I unsinatlled it there.
>> "netstat -l -p" confirms this.
>> Otherwise the tftpd inside the host wouldn't be able to bind to the
>> port neither..?
>>
>
> yep, i'd think so.
>
>
>> This is my tcpdump from the host:
>>
>> buero:/etc/vservers# tcpdump -n | grep '\.1\.203'
>>
>
> you might wanna try tcpdump src or dst 192.168.1.203
>
>
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>> 16:02:32.108114 IP 192.168.1.203.67 > 255.255.255.255.68: BOOTP/DHCP,
>> Reply, length 300
>> 16:02:34.198749 IP 192.168.1.203.67 > 255.255.255.255.68: BOOTP/DHCP,
>> Reply, length 300
>> 16:02:34.206389 arp who-has 192.168.1.203 tell 192.168.1.32
>> 16:02:34.206410 arp reply 192.168.1.203 is-at 00:13:8f:56:02:96
>> 16:02:34.206614 IP 192.168.1.32.2070 > 192.168.1.203.69: 27 RRQ
>> "pxelinux.0" octet tsize 0
>> 16:02:34.207638 IP 192.168.1.32.2070 > 192.168.1.203.32973: UDP,
>> length 17
>> 16:02:34.207674 IP 192.168.1.203 > 192.168.1.32: ICMP 192.168.1.203
>> udp port 32973 unreachable, length 53
>> 16:02:34.214165 IP 192.168.1.32.2071 > 192.168.1.203.69: 32 RRQ
>> "pxelinux.0" octet blksize 1456
>> 16:02:34.215175 IP 192.168.1.32.2071 > 192.168.1.203.32974: UDP,
>> length 4
>> 16:02:34.215207 IP 192.168.1.203 > 192.168.1.32: ICMP 192.168.1.203
>> udp port 32974 unreachable, length 40
>> 16:02:37.968200 IP 192.168.1.32.2071 > 192.168.1.203.32972: UDP,
>> length 4
>> 16:02:37.968234 IP 192.168.1.203 > 192.168.1.32: ICMP 192.168.1.203
>> udp port 32972 unreachable, length 40
>>
>
>
>> For me it seems that the chosen data-port for the transfer by the
>> server is somehow not reachable?
>> What could the reason be, how to solve it?
>>
>
> Firewalling or other security stuff?
> Did you try testing with netcat?
> Inside the vserver: nc -l -u -p 32974
>
>> >From the client: nc -u 192.168.1.32 32974
>>
> and type some stuff there, see if it gets through.
>
> I'm running this setup on various boxes witch different vserver
> versions, and i haven't had a problem with it for years.
>
> Tom
>
>
>
Received on Tue Feb 19 19:58:56 2008