Adding static arp entries in non-global zones

It doesn't seem to be working:
# arp -s 10.0.73.8 02:23:23:23:32:12 permanent
10.0.73.8: Not owner
Any privileges or devices I have to add to the non-global zone to get this working?
Thanks.

swiergot wrote:
It doesn't seem to be working:
# arp -s 10.0.73.8 02:23:23:23:32:12 permanent
10.0.73.8: Not owner
Any privileges or devices I have to add to the non-global zone to get this working?
Thanks.Unless you're running exclusive IP, the ARP table is under control of the global zone. Have you made the change in the global zone, to determine if it propogates or not? It should.
Best,

Similar Messages

Adding a cdrw to a non-global zone

Hi all,
I am attempting to add a cdrw on a laptop running Solaris 10 to a
non-global zone via the following (after browsing the archives of this
list as well as related forums and documentation):
"cdrw -l" when run in the global zone reports
"/dev/rdsk/c1t0d0s2" as the sole CD writer attached. I have previously
burnt cdr(s) using this, so the functionality of the drive is not an issue.
I then proceeded to configure a zone, "zulu01", and added a device via
the following using zonecfg (I have omitted the other configuration data
which is standard, root path, standard inherit-pkg-dir)
"add device"
"set match=/dev/rdsk/*"
"end"
"commit"
"verify"
I then installed the zone
"zoneadm -z zulu01 install"
zoneadm does the usual and reports success.
I boot the zone
"zoneadm -z zulu01 boot"
and login via "zlogin -C zulu01"
Inside zulu01, running "cdrw -l"
reports "No CD Writers found."
a "ls /dev/rdsk" shows that c1t0d0s2 is present.
I am aware that adding such a device is not recommended, but it is
supposedly possible?
Please advise on what I am doing wrong, or is it not possible to add a
cdrw to a non-local zone?
Thanks in advance.
Regards,
Jeremy.

This should work. A shot in the dark: can you try with another tool than cdrw, cdrecord for example? Also make sure that volume management is not running in the global zone (/etc/init.d/volmgt stop).
Blaise

Dynamically adding a device to a non-global zone

How can you add a new device to a non-global zone without having
to reboot the zone ? Obviously using zonecfg and then rebooting the
zone works but often rebooting the zone would be very user unfriendly.
In particular we occasionally need to add a new disk mirror in the global
zone and then let the non-global zone have access to it.

So each zone has a /dev tree that's private in <zoneroot>/dev which gets lofs mounted to /dev in the zone. You can mknod a new device in here and it appears instantly in the zone. Use the same major and minor numbers that device has in the global zone. If it's a disk device, make sure to major both the block and character device.
Of course, you want to edit the zone config to make it permanent (though I suspect it may actually be permanent if you mknod the device...)

Static arp entries in zones

Hi
I'm aware of, and experiencing the problem with my arp table being poisoned. I'm working on updating the Broadcom drivers but in the meantime need to set some static entries in arp. My setup has the global zone configured on e1000g0, with a second interface e1000g1 used by a non-global-zone, alll interfaces are shared. The global zone has no ip and neither is it up on e1000g1, only plumbed. My point being this, when I create a static arp entry for my the non-global-zones default gateway, which can only be done in the global zone, it is assigned to the e1000g0 device. There is a learnt entry for the same gateway (same ip) but on the e1000g1 interface. Ideally I want the learnt entry removed and the static entry assigned to the e1000g1 interface.
Is this possible, and if not am I worrying about a problem that doesn't exist. My fear is that the non-global-zone only being aware of the e1000g1 device will only use the learnt arp entry which is in danger of changing.
If any of this made sense, please can you advise whether there is a potential problem and if it can be rectified.
Thanks

813137 wrote:
Hi
I'm aware of, and experiencing the problem with my arp table being poisoned. I'm working on updating the Broadcom drivers but in the meantime need to set some static entries in arp. My setup has the global zone configured on e1000g0, with a second interface e1000g1 used by a non-global-zone, alll interfaces are shared. The global zone has no ip and neither is it up on e1000g1, only plumbed. My point being this, when I create a static arp entry for my the non-global-zones default gateway, which can only be done in the global zone, it is assigned to the e1000g0 device. There is a learnt entry for the same gateway (same ip) but on the e1000g1 interface. Ideally I want the learnt entry removed and the static entry assigned to the e1000g1 interface.
Is this possible, and if not am I worrying about a problem that doesn't exist. My fear is that the non-global-zone only being aware of the e1000g1 device will only use the learnt arp entry which is in danger of changing.
If any of this made sense, please can you advise whether there is a potential problem and if it can be rectified.Unless your global zone gets an address on the same subnet as the NGZ for e1000g1, it can't add
a static arp entry in the shared IP configuration..
OTOH, you can do this with exclusive IP zones, which is really a much cleaner config/administrative model.
I'd suggest: set up the NGZ as ip-type exclusive, assign it e1000g1, and let the NGZ itself add the static arp entry
--Sowmini

Adding remote printer to non-global zone

I have a non-global zone with a remote printer defined, and lpstat shows
# lpstat -lp abcdef
printer abcdef disabled since Thu Jun 06 13:18:43 2013. available.
Remote Name: abcdef
Remote Server: 192.168.x.x
On another non-global zone I want to print to the same printer. I referred to the Solaris Printing SAG, and I thought all I had to do is
lpadmin -p abcdef -s abcdefserver
but lpstat -lp abcdef gives
Failed to get printer info for abcdef: not-found
The zone is
SunOS myzone 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-V490
and the destination (abcdefserver) is a Windows server with the LPD service installed.
What else do I have to do? I can ping and telnet abcdefserver:515, so the network part seems to be fine.

Please follow the procedure that you can find there : http://docs.oracle.com/cd/E19082-01/819-7761/ertsp/index.html

Non-Global Zone Routing

I have a V20z running a global zone on an IANA private network of 172.30.0.x and nic bge0
I also have a non-global zone on a public IP of 207.246.20.169 and nic bge1.
I am unable to ping from one zone to the next via a gateway. Normally the global zone would use a standard gateway for that network and my public network would also use a standard gateway for that network.
What appears to be happening is that despite what is in my /etc/defaultrouter the zone itself is the gateway.
For example, to ping something from either zone which would require the gateway results in:
ICMP Host Unreachable from gateway 'zone name' (zone ip address)
What I want to happen is that the global zone honors the gateway that is normally used in this network and the non-global zone uses/honors the gateway that is normally used in that network.
It doesn't seem to matter if I have the normal internal gateway in my /etc/defaultrouter or if I have the normal public gateway in /etc/defaultrouter or if I have both in /etc/defaultrouter (all in the global zone of course).
Do I need to use routed to achieve this? Am I missing something here?

I hammered the problem out by adding a static route in the global zone:
route add 172.30.0.0 207.246.20.161
Where 207.246.20.161 is my gateway on the public side.
I slapped this into an /etc/init.d script in the global zone and ran it from /etc/rc2.d like the article below suggests:
http://www.sun.com/bigadmin/content/submitted/persistent_routing.html

Separate private ip addresses for non-global zones

I'm testing zones on one of our administrative servers and I'm wondering about the following scenario.
Zones can easily run away with a lot of ip addresses and I decided to try this. The machine has, in its global zone, a standard private address in the admin (192.168.129.0) segment on hme0. I have also given it another address, 192.168.229.1, configured on hme0:1 which I intend to be the defaultrouter for non-global zones.
Zone 1 has as its primary address 192.168.229.10, and I have tried to set the default router to 192.168.229.1 by various methods based on what I have read in here., including adding that address to the defaultrouter file in the global zone.
Zone 2 has 192.168.229.20 as its primary address and is intended to have the same default of 192.168.229.1.
So far I've not been able to make this work . Am I barking up the wrong tree?
TIA

Sorry for the late reply.
So if I understand correctly, you want to put all your zones in a dedicated IP network (192.168.229.0/24).
To do this, you don't need to configure the global zone as default gateway for the zones (which doesn't work, as you noticed). You want to indicate to the zones that they can reach the other network (192.168.129.0/24) just by sending packets on hme0. To do so, you need to create interface routes in every zone:
# route add net 192.168.129.0/24 192.168.229.10 -interface(same for Zone 2, etc.)
The global zone then needs to advertise itself as gateway for the 192.168.229.0/24 network to the other hosts. I think in.routed(1M) can do this using special configuration in the gateways(4) file, but I don't know how. Otherwise, if you can administer the real router that the other hosts use, you can add a static route: destination 192.168.229.0/24, gateway [global zone IP].
hope this helps,
Blaise

How to know global zone in case non global zone is hung

....I have nongloabazone1,nongloabazone1,nongloabazone2,nongloabazone3...
i am working on nongloabazone1 ..
suppose i am giving remote support ...
if my nongloabazone1 is hung ..i need to know the global zone on which this nongloabazone1 is installed and reboot from there ...if my nongloabazone1 is hung i cannot apply #arp -a and check it out by trial and error method and know the global zone....
in this case how can i reboot the nongloabazone1 .....i have the same question in case of Ldoms also..............
Thanks in Advance.......

Hi.
It's not clear what means "non global zone is hung".
In case it realy hangs you can't do anythins in this zone.
1) In case you have access to global zone. You can get list all zones running on this host:
zoneadm list -cv
For reboot local zone from global zone just need: zoneadm -z <zone_name> reboot
2) Zones not support live migration. So after zone started it can not change global zone.
Create script that put global zone name in file. When need - just read content of this file.
This file can be created from global zone when start (or create/move) local zone.
In case zone migration is not quickly operation, just create file (or database) for list what zone started on which host.
For LDOM it look wery same.
Regards.

*Missing utilities in Solaris11 Non global zone.*

Hi,
I created Non Global zone in Solaris 11, I found many utilities are missing in Non Global zone machine. For example in non global zone /usr/xpg4/bin contains only 2 utilities where as in global zone I have 68utilities. I copied few utilities from my global zone machine which ever is required for me(ex: id,grep,egrep....). I need to enable rlogin, telnet, ftp in my Solaris 11 non global zone machine. I installed pkg:/service/network/legacy-remote-utilities. But no luck. In some thread i found workaround to enable rlogin.
rlogin on zones in solaris 11 i found a workaround.
Need to copy 2 binaries and 2 .xml manifest from GZ to NGZ
cp /usr/sbin/in.rlogind
cp /lib/svc/manifest/network/login.xml
cp /usr/sbin/in.rshd
cp /lib/svc/manifest/network/shell.xml
Question1: how about other services?
Question2: As a concept It has to have all the utilities which is available in Global zone. Why these many utilities are missing? Am I doing any thing wrong or is it zone limitation? we are facing issue in only Solaris 11. where as in Solaris10 every thing works fine.

What you observed is normal. The basic Solaris 11 zone install gives you a somewhat minimal install. If you want additional packages, you can install them. If you want the zone install to have what you would install from a CD I suppose you could do a the following:
pkg install slim_install
pkg uninstall slim_install
My understanding is that the slim_install package contains dependencies which loads all of the desktop software but doesn't contain any content itself - which is why you can (and should) remove it afterwards.
That said, normally one uses a zone for a particular purpose. A better approach might be to install only the software in the zone which is needed for that purpose. That would save space, limit security exposure and reduce maintenance overhead. If your purpose is to have a full user environment, that may be to include all the slim_install packages and maybe others as well.
I would recommend that you not install services by copying files. If you need a service find out what package contains that service and install the package in the zone. That way you won't break maintenance via pkg update.
So - your questions:
1. A Solaris 11 zone install is minimal, presumably to make it easy to set up simple single function zones. Additional packages can be added as needed using "pkg install" as needed to provide any necessary services.
2. Solaris 10 zones work differently and import most packages from the global zone. With Solaris 10 sparse zones, you actually use the same files from the global zone. Solaris 11 zones are different in that they are actually a separate install. The basic install is minimal, presumably to allow for small and simple single function zones. You are not doing anything wrong with respect to the basic install, this is just how things work.

SFTP chroot from non-global zone to zfs pool

Hi,
I am unable to create an SFTP chroot inside a zone to a shared folder on the global zone.
Inside the global zone:
I have created a zfs pool (rpool/data) and then mounted it to /data.
I then created some shared folders: /data/sftp/ipl/import and /data/sftp/ipl/export
I then created a non-global zone and added a file system that loops back to /data.
Inside the zone:
I then did the ususal stuff to create a chroot sftp user, similar to: http://nixinfra.blogspot.com.au/2012/12/openssh-chroot-sftp-setup-in-linux.html
I modifed the /etc/ssh/sshd_config file and hard wired the ChrootDirectory to /data/sftp/ipl.
When I attempt to sftp into the zone an error message is displayed in the zone -> fatal: bad ownership or modes for chroot directory /data/
Multiple web sites warn that folder ownership and access privileges is important. However, issuing chown -R root:iplgroup /data made no difference. Perhaps it is something todo with the fact the folders were created in the global zone?
If I create a simple shared folder inside the zone it works, e.g. /data3/ftp/ipl......ChrootDirectory => /data3/ftp/ipl
If I use the users home directory it works. eg /export/home/sftpuser......ChrootDirectory => %h
FYI. The reason for having a ZFS shared folder is to allow separate SFTP and FTP zones and a common/shared data repository for FTP and SFTP exchanges with remote systems. e.g. One remote client pushes data to the FTP server. A second remote client pulls the data via SFTP. Having separate zones increases security?
Any help would be appreciated to solve this issue.
Regards John

sanjaykumarfromsymantec wrote:
Hi,
I want to do IPC between inter-zones ( commnication between processes running two different zones). So what are the different techniques can be used. I am not interested in TCP/IP ( AF_INET) sockets.Zones are designed to prevent most visibility between non-global zones and other zones. So network communication (like you might use between two physical machines) are the most common method.
You could mount a global zone filesystem into multiple non-global zones (via lofs) and have your programs push data there. But you'll probably have to poll for updates. I'm not certain that's easier or better than network communication.
Darren

Unable to add a device (e.g. /dev/cua0) to a non-global zone

Hi,
I've installed solaris 10u4 on a x86 machine with the latest patches, installed with the smpatch utility
The history:
I've installed solaris 10u3 without any patches, a quite minimum installation; I 've created a non-global zone, added a zfs dataset, added networking, add one serial device (/dev/cua0); installed hylafax from blastwave in the created zone using the attached modem on /dev/cua0, all was working fine, except some sendmail issues. Due to issues with samba, which I needed on this machine, I've tried to update the machine, after ending up in dependency hell, due the minimum installation, I gave up. I did a fresh install of solaris 10u4 instead also with latest patches applied with the smpatch utility, the I've created a new zone and want to add the device /dev/cua0 like in the s10u3 installation, but the device doesn't appear in the non-global zone, so I've installed hylafax in the global-zone temporary.
The question, any ideas or workarrounds to bring the async device into a non-global zone again ?
I'm not a newbie in nix like systems (several years with BSD and GNU/Linux), but for solaris I would classify myself as a newbie ;-)
thanks in advance.

Hmm. If that didn't work, then it's possible you're running into a different problem.
But I checked again and this is the one I was thinking of. Toward the bottom, some patches are referenced. I suppose they won't hurt, but I'm worried you're seeing something related to the 'cua' device rather than the general problem of device creation.
http://www.opensolaris.org/jive/thread.jspa?messageID=171187
Darren

Non-global zone sending TCP SYN-ACK packet over wrong interface.

After spending many hours looking at ipmon/ethereal logs, I believe I've found
a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
=====
The non-global zone has this setup:
zonecfg:ws1> info
...snip...
net:
address: 62.146.25.34
physical: e1000g2
zonecfg:ws1>
=====
The relevant (as of the IPF log) IPF rules are:
rule 1: block out log all
rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
=====
If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
Any hints?
Thx,
Tobias
"att1.txt":
LINE     PACKET_DT     PACKET_FS     PACKET_IFC     RULE_NUMBER     RULE_ACTION     SOURCE_IP     SOURCE_PORT     DEST_IP     DEST_PORT     PROTOCOL     TCP_FLAGS
1     08.05.2006 21:24:09     786741     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     S
2     08.05.2006 21:24:09     786863     e1000g0     16     p     62.146.25.34     80     84.56.16.159     60693     tcp     AS
3     08.05.2006 21:24:09     808218     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     A
4     08.05.2006 21:24:09     837170     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
5     08.05.2006 21:24:09     837189     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
6     08.05.2006 21:24:09     837479     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
7     08.05.2006 21:24:12     823801     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
8     08.05.2006 21:24:12     823832     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
9     08.05.2006 21:24:13     210039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
10     08.05.2006 21:24:18     839318     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
11     08.05.2006 21:24:18     839351     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
12     08.05.2006 21:24:19     970040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
13     08.05.2006 21:24:24     840073     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AF
14     08.05.2006 21:24:30     870503     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
15     08.05.2006 21:24:30     870538     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
16     08.05.2006 21:24:33     480059     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
17     08.05.2006 21:24:45     347464     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AF
18     08.05.2006 21:24:45     347498     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
19     08.05.2006 21:24:47     857068     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     S
20     08.05.2006 21:24:47     857118     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AS
21     08.05.2006 21:24:47     878257     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
22     08.05.2006 21:24:47     907630     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
23     08.05.2006 21:24:47     907644     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
24     08.05.2006 21:24:47     907892     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
25     08.05.2006 21:24:47     976361     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
26     08.05.2006 21:24:47     976375     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
27     08.05.2006 21:24:47     976487     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
28     08.05.2006 21:24:48     127599     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
29     08.05.2006 21:24:54     932569     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
30     08.05.2006 21:24:54     932595     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
31     08.05.2006 21:25:00     490052     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
32     08.05.2006 21:25:02     980057     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AF
33     08.05.2006 21:25:03     1890     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
34     08.05.2006 21:25:09     907916     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AF
35     08.05.2006 21:25:09     907949     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
36     08.05.2006 21:25:42     948502     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
37     08.05.2006 21:25:42     948535     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
38     08.05.2006 21:25:54     500051     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
39     08.05.2006 21:26:54     510046     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
40     08.05.2006 21:27:54     520041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
41     08.05.2006 21:28:54     530040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
42     08.05.2006 21:29:54     540039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
43     08.05.2006 21:30:54     550039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
44     08.05.2006 21:31:54     560041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
"dump_failed.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x0269 (617)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde9d [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x5c3c [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x002f (47)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ed8 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1079 (1079)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xd017 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x026a (618)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdea4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbdac]
No. Time Source Destination Protocol Info
4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x026b (619)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcfd [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 5 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0276 (630)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcf2 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 6 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x027f (639)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce9 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 7 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0284 (644)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x029a (666)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde74 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbc05]
"dump_success.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x02a3 (675)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde63 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x70ca [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x006b (107)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2e9c [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xb530 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02a4 (676)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde6a [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xa2c5]
No. Time Source Destination Protocol Info
4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x02a5 (677)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcc3 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xb2be]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006c (108)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea3 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xe046 [correct]
No. Time Source Destination Protocol Info
6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
Frame 6 (413 bytes on wire, 413 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 399
Identification: 0x006d (109)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d3b [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Next sequence number: 360 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x29b8 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
Frame 7 (407 bytes on wire, 407 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 393
Identification: 0x02aa (682)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdd03 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Next sequence number: 776 (relative sequence number)
Acknowledgement number: 360 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65176
Checksum: 0x1b3d [incorrect, should be 0x1e0c]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006e (110)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea1 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xdd7e [correct]
No. Time Source Destination Protocol Info
9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
Frame 9 (464 bytes on wire, 464 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 450
Identification: 0x006f (111)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d06 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Next sequence number: 770 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x7a71 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02af (687)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde5f [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 776 (relative sequence number)
Acknowledgement number: 770 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64766
Checksum: 0x19dc [incorrect, should be 0x9fbe]

lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
Thus I created a bug report: https://bugs.archlinux.org/task/40089
i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
Client connecting to 10.10.10.6, TCP port 5001
TCP window size: 416 KByte
[ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
[ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
[ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
[ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
[ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
[ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
[ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec

Non-global zone networking

I've created a non-global zone with a pair of anet devices. I plan to do IPMP inside the non-global zone to manage interface redundancy. The anet config is rather simple -- I have a net0 and net1 whose lower-link's are net2 and net3 respectively.
Inside the zone, it looks like everything is ready to go. My two VNICs are up.
zone# dladm show-link
LINK CLASS MTU STATE OVER
net0 vnic 1500 up ?
net1 vnic 1500 up ?
So I try to plumb them (if I can still use that term).
zone# ipadm create-ip net0
zone# ipadm create-ip net1
zone# ipadm show-if
IFNAME CLASS STATE ACTIVE OVER
lo0 loopback ok yes --
net0 ip down no --
net1 ip down no --
That's strange -- why are they not up?
zone# ifconfig net0 up; ifconfig net1 up
zone# ipadm show-if
IFNAME CLASS STATE ACTIVE OVER
lo0 loopback ok yes --
net0 ip ok yes --
net1 ip ok yes --
Aaah. Much better. Now I can get on with my life.
# ipadm create-ipmp -i net0 -i net1 ipmp0
# ipadm create-addr -T static -a 192.168.1.104/24 ipmp0/v4
So my quesion is why did I have to resort to running an ifconfig up on these interfaces? ifconfig is dead to me -- or so I'd like to think. :)
What is the "right" way to deal with this problem?

Figured this out.
The issue was that I had just done a zlogin to the zone after it was built (which was 3 weeks ago). I had completely forgotten that I had not yet completed the system configuration so the svc:/milestone/config:default service was offline, along with it's many dependancies.
Basically I manually configured the network information before I had told the system config that I was going to do so.
Strange behaviour -- but that's what happens when you don't follow order of operation.

Non-global zone installation problem

I have created a non-global zone sqa45-zone as follows:
zonecfg -z sqa45-zone
zonecfg:sqa45-zone> info
zonepath: /export/home/zones/sqa45-zone
autoboot: false
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 10.4.105.105
physical: bge0
zonecfg:sqa45-zone> exit
When I try to install the zone, this is the error message I see.
sqa45# zoneadm -z sqa45-zone install
could not verify net address=10.4.105.105 physical=bge0: No such device or address
zoneadm: zone sqa45-zone failed to verify
sqa45#
I'm not sure how I can correct this. Any help is appreciated.
Thanks.

You havent specified a netmask.
That might be causing it.
You can specifiy it as address=10.4.105.105/24 or by a separate netmask entry.

How to add a second nic card to non global zone

hi every one
i have a issue like
my non global zone has hme0 as the nic card
i want to add a secondary nic card like pcn0 to the non global zone . how can i add to the nonglobal zone so that both the nic cards should exist in the nonglobal zone
please tell me the command and procedure for that
thanks in advance ....

If your non-global zone is a shared IP zone, then you can add like
zonecfg -z <zonename>
add net
set physical=pnc0
set address=<IP Address>
end
verify
commit
exit
If your non-global zone is an exclusive IP zone, then remember that the interface pnc0 you are adding will be in control of non-global zone exclusively.
Steps to add it are same as above.

Adding static arp entries in non-global zones

Similar Messages

Maybe you are looking for