Ifconfig nxge2 external ethernet card on global zone

Hello,
I'm trying to configure a NIC on an external quad ethernet card on the global zone. I can ifconfig the NIC, but it doesn't show RUNNING.
However, I was able to configure nxge1 as an exclusive-ip to a local zone.
Is there a special setup for external ethernet cards on the global zone?
# ifconfig nxge2 plumb
# ifconfig nxge2 192.125.255.89 netmask 255.255.255.0 up
nxge2: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 6
inet 192.125.255.90 netmask ffffff00 broadcast 192.125.255.255
ether 0:14:4f:89:73:46
5.10 Generic_137111-01 sun4v sparc SUNW,Sun-Blade-T6300
# dladm show-dev
e1000g0 link: up speed: 1000 Mbps duplex: full
e1000g1 link: up speed: 1000 Mbps duplex: full
nxge0 link: down speed: 0 Mbps duplex: unknown
nxge1 link: up speed: 1000 Mbps duplex: full
nxge2 link: down speed: 0 Mbps duplex: unknown
nxge3 link: down speed: 0 Mbps duplex: unknown
Only nxge1 is showing link_up=1
# kstat -p nxge|grep link_up
nxge:0:Port Stats:link_up 0
nxge:0:mac:link_up 0
nxge:1:Port Stats:link_up 1
nxge:1:mac:link_up 1
nxge:2:Port Stats:link_up 0
nxge:2:mac:link_up 0
nxge:3:Port Stats:link_up 0
nxge:3:mac:link_up 0

You can do it with dedicate IP

Similar Messages

NAT / cant select my external Ethernet Card (for use with PPPoE)

Hi i'm experiencing difficultys in setting up my server with a public IP adress on my external ethernetcard through PPPoe (xDSL). This setting is described as a sample setup in "ServerAdministrationv10.5.pdf" The following problems com up:
- When i try to settup trough Server Assistant and i come to Network settings both (external (WAN)& internal (LAN)) Ethernetcards show up. As an necessery information there is asked for "PPPoE Servicename" (besides accountname and password). My ISP doesnt require a PPPoE Service name and when i query (?) what is asked for Server Assistant tells me that except i get the information from my ISP i have to leave the field blank. Now, i cant continue with the setup when leaving the field blank . The information is required. When i just supply some information and continue with setup the setup ends with a long pause and an errormessage.
- Second try, after initial clean installation i Setup the server again localy with the default Serverassistant. When asked to post IP-Adress and Subnetmask for the first listed Ethernetcard i just leafe it with DHCP and continue. After initial Setup is complete i try to reconfigure the external (WAN) Ethernetcard with PPPoE. By doing that(in Systemettings / Networksettings) a get something like a new virtual Interface on my External EthernetCard. I enter the necessary information (accountname, password and leave the field for "PPPoE Servicename" blank. I connect to my ISP and get a perfect connection. No problem to brouse the Web or make FTP connection.
Now when i continue to finish the setup of my new leopard-server i'm asked to select the external Ethernetcardin NAT. Unfortunally i have know three Ethernetinterfaces (External with DHCP, External with PPPoE and the internal one for my LAN). The 2 externel EthernetInterfeces have both the same Name (in NAT)
and somehow i cant select the one where i have setup my PPPoE.
Now, i go back to Networksettings and delete the initial Externalcardsetting (leaving with only my working PPPoE setting on the External Ethernetinterface). As the result of this manipulation i cant select the external Ethernetinterface in NAT anymore. Only the internal (LAN) Ethernetinterface shows up.
Can anybody help me with to above discribed Problem? Somehow i have to be able to select my working PPPoE Setting (on my external Ethernetinterface) in NAT.

I have this exact problem on my new Intel Xserve. During setup I configure ethernet 1 with a manual IP address and try to set up ethernet 2 for PPPoE (it will connect to my ISP via the ADSL modem/bridge) but despite the help screen saying do NOT type anything in PPPoE Service Name unless requested to do so by the ISP (they don't), if I leave it blank it complains because that field is empty and returns to the same screen.
This brings the entire installation to a halt. Seems to me like it's a big bug - I cannot see any way around it. Someone please tell me I'm being stupid here and the solution is obvious:-)

Changing the speed of the ethernet card

Referring to this topic I posted earlier: http://discussions.apple.com/thread.jspa?threadID=568098&tstart=0
I called my ISP, and they could only think of one thing: that there is a conflict between my MacBook's fast ethernet card and my old DSL box (that is capable of only 10 Mb/s).
So, they suggested I try to change the speed of my ethernet card to 10 Mb/s.
The problem is, how do I do it?

I think your ethernet builtin is downgrade compatible, which mean it will run on 10 mbps too without you have to changed the speed.
It is the first time I hear that we should adjust the transfer rate to lower setting.
If your ethernet card max is 10 mbps and you want to use 100 mbps, than you must change the ethernet card or use other external ethernet card, not the other way around.
Good Luck

How can 2 non-global zones share a singe ethernet?

This may be a very basic question. I am new the this board and trying to learn more about the Solaris Zone.
I am trying to find out whether sharing an ethernet card between two non-global zones is possible.
Where can I get additional infor on this topic?
Thanks,

I just found the answer to my question. Thanks, Can you post a link to where you found the answer?
Birdman >>I'm not exactly sure what he found, but you might try this link, to the zones documentation:
http://docs.sun.com/db/doc/817-1592/6mhahuos1?a=view#z.admin.ov-12
The answer to the question is "yes" you can do this, and in fact it is somewhat trivial. We've long had a feature in Solaris called "logical network interfaces". This allows multiple logical interfaces to be defined atop a single physical one. Zones uses this feature and creates logical interfaces atop a single virtual interface. You can even have multiple network interfaces assigned to the same zone, without any problem.
-dp

Ethernet card no longer showing in ifconfig [solved]

Hey,
Normally I don't have any problems with my networking, but this morning my wireless decided not to work. I haven't made made any changes in the past couple of days, so unsure what has caused it. Last Syu was on Thursday and every day including up until last night was fine.
So spent a while trying stuff out and stressing my tiny little brain for ideas, quick version is I did this:
netcfg: said interface didn't exist.
ifconfig: didn't list the interface (wireless is usually eth1)
lsmod: confirmed the module (ipw2200) was loaded
lspci: confirmed the card was there
After copying the output of the above commands plus the obligatory rc.conf onto usb to move to this machine (and just before pushing <submit> on a much larger post than this :-) I decided to check the mac address listed in ifconfig with what is on the sticker under my machine. Voila! My wireless has actually moved to eth0. OK, that's that solved. (Wish I checked that first though...)
But that means that the reason that my wireless card is now eth0 instead of eth1 is because my old-skool wired ethernet card is no longer there to be numero 0. Why isn't it working? lsmod shows that the tg3 module is loading (it's an Intel card with Broadcom chipset in a Thinkpad T43) , but it no longer shows up in ifconfig. lspci is not showing it (see below), only the wireless card comes up. Does this mean the hardware is borken? What else can I do to check the card?
$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Mobility Radeon X300]
0b:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8d)
0b:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection (rev 05)
Appreciate any advice you can give.
Cheers,
vW
Edited subject
Last edited by von_Wanderlust (2009-07-28 16:10:22)

Yeah, doesn't give me anything about the ethernet card, but does show the wireless one. No, hang on, just found it. Hmmm, didn't see it before, but I was grepping for 'net' then.
$ dmesg | grep -i eth
eth1: Tigon3 [partno(BCM95751M) rev 4101] (PCI Express) MAC address 00:12:34:56:78:9a
eth1: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1])
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth1: dma_rwctrl[76180000] dma_mask[64-bit]
OK, so it is at eth1 now, that makes sense since I put ipw2200 right at the beginning and tg3 right at the end of the MODULES array in rc.conf to avoid the system getting crossed up while trying load them too close together. Thanks B, so at least we know something is happening at boot time.
Btw, my assumption is that ifconfig shows hardware once it is loaded correctly, is that right? But apart from the modules, what else do I need to do to get it showing up in ifconfig?

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.

Connecting a PC with an external wireless card

I have an iMac and am connected wirelessly to the Internet through the Airport Extreme. My roommate has a new Dell Laptop with Windows XP and has been connected through ethernet to the base station. She just recently purchased an external wireless card, and we can't seem to get her connected wirelessly. When searching for available networks to join on her computer, it recognizes my network and says that it has an excellent signal, but when we type in the WEP, it doesn't do anything. It does not give us an error, and it does not connect. Any idea what we are doing wrong and what we can do to fix it?

I still can't figure it out. I unchecked the option that says "enable encryption (using WEP)" and she was immediately connected. I don't think I have a huge problem leaving the network up without a password, I'm in a small residential area. Does that just mean that neighbors would be able to connect? How far does the signal generally travel? And is there any way to see the IP addresses of people connected to this specific network?

Time Machine not working after ethernet card failed

A couple of weeks back my iMac Core Duo's ethernet failed. As a logic board replacement for a 3.5 year old iMac would be expensive I instead bought an Apple USB Ethernet adapter (which works great). However, now Time Machine will not work, it says it cannot find the built in network interface. It does not matter whether I connect the external drive directly via firewire or over the network to my Mac Mini (which will backup with either connection).
Here is the console error:
+Time Machine: Error setting backup path: Error Domain=com.apple.TimeMachine.Preferences Code=-1 UserInfo=0x1864bdf0 "Time Machine could not be configured. The built-in network interface could not be found."+
+_CSBackupGetMachineMACAddress - IOServiceGetMatchingServices did not find an ethernet service with kIOPrimaryInterface true+
I tried the instructions on the Apple Support page http://support.apple.com/kb/HT3275#5, but that did not work. Can anyone help?

Hi, and welcome to the forums.
It's a long shot, but try a "Full Reset" of Time Machine, per item #B3 of the Time Machine - Troubleshooting *User Tip* at the top of this forum.
TM uses your Mac's Ethernet Address, which is embedded in the hardware of, guess what, your logic board, to identify your computer. This is how it keeps the backups for each Mac separate, so you can back-up more than one Mac to the same place without conflicts.
To find this address, use the System Profiler app (click the Apple icon at the left of your Menubar, then +About this Mac,+ then +More Info.+
Select Network in the sidebar, then Ethernet then find a line like this: +*MAC Address: 0a:1b:2c:3d:4e:5f+* That code, omitting the colons, is what TM puts in a hidden file on your TM volume to identify it as your Mac's backups.
Since your internal Ethernet card failed, you may not see that at all. If not, neither, apparently, can Time Machine. Other than getting a new logic board, I don't think there's a workaround.

Ssh takes me to the global zone instead of the non-global zone

I have set up my first Solaris 10 server with a new zone. The ce device is set up on the zone as well as the global zone.
Output from ifconfig on the global zone:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.16.1.217 netmask ffffff00 broadcast 172.16.1.255
ether 0:3:ba:f2:a1:54
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 172.16.1.199 netmask ffffff00 broadcast 172.16.1.255
ether 0:3:ba:f2:a1:54
Output from the non-global zone:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.16.1.199 netmask ffff0000 broadcast 172.16.255.255
ether 0:3:ba:f2:a1:54
When I ssh into the non-global zone, I end up in the global zone? Can I ssh straight into the non-global zone? Am I missing something in the zone setup that keeps me from being able to ssh into the non-global zone?
Any help is appreciated. I have been racking my brain on this for several hours.
Thanks ahead of time.

TAdriver wrote:
The one thing I have found in the documentation is that if you set the network as an exclusive IP, you can only assign the physical name using zonecfg. You can't set the IP address or the default router. In fact, if you try to set either of those, you get an error saying you can't set those using an exclusive IP type.Correct. When doing a shared-IP zone, the zone has no privileges to do IP-level things. So the global zone (via the zone configuration) creates the virtual interface and sets the IP address. Then when the zone is booted, the interface is given to it.
With an exclusive-IP zone, the zone can do all this work itself. From its perspective, it's handed an interface like a regular machine. So the IP settings are done within the zone (/etc/hosts, /etc/hostname.XXX, /etc/netmasks).
Darren

Can I import one non-global zone from one machine to another?

If create a non-global zone on one disk on machine A, is it possible to make a copy of that disk, and import the non-global zone to machine B? If yes, how to import the non-global zone?
Thanks!

It should be possible if your machines are installed at the same way, because you need the same environment (patches, packages,..).
If this is true you should export your zone definition on machine A (zonecfg export) and import it on machine B (zonecfg -f ...).
Then create the new zone on B. If finished get your zonepath with all data on A an copy it to B. That should be all.
With this solution I hope it would be possible to have a shadow instance on B and the aktiv instance on A. If you have your whole zonepath on external disks like EMC, you only have to mount your disks on B and start your zone.
harruh

SMCnsnmp in shared-ip non-global zone errors due to duplicate I/F index

Hi all,
I have Solaris 10 zones using the shared-ip model, with Net SMTP installed in the global and non-global zones.
Smtpd starts normally in the global zone, but fails to start in the non-global zones, reporting this error ...
$ sudo tail /zones/roots/uxNNNz4/root/var/log/snmpd.log
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
error on subcontainer 'interface container' insert (-1)
This error was reported on OpenSolaris some time ago, reference ...
(http://prefetch.net/blog/index.php/2009/05/10/net-snmp-should-now-work-in-an-opensolaris-non-global-zone) ...
Net-snmp does not work in an opensolaris non-global zone:
+"error on subcontainer ‘interface container’ insert (-1)"+
These errors are caused by opensolaris bug #6640675, which causes all interfaces to be assigned an index value of 0 (this leads net-snmp to think there are duplicate interfaces). The fix was just integrated into Nevada, so hopefully the code will be back ported to Solaris 10.
Example ifconfig in global zone (note index 2 for global and shared-ip VIPs)...
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
zone ux560z1
inet 127.0.0.1 netmask ff000000
lo0:2: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
zone ux560z2
inet 127.0.0.1 netmask ff000000
lo0:3: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
zone ux560z3
inet 127.0.0.1 netmask ff000000
lo0:4: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
zone ux560z4
inet 127.0.0.1 netmask ff000000
nxge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.25.4.2 netmask fffffc00 broadcast 172.25.7.255
ether 0:21:28:ba:9e:e4
nxge0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone ux560z1
inet 172.25.4.3 netmask fffffc00 broadcast 172.25.7.255
nxge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone ux560z2
inet 172.25.4.4 netmask fffffc00 broadcast 172.25.7.255
nxge0:3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone ux560z3
inet 172.25.4.5 netmask fffffc00 broadcast 172.25.7.255
nxge0:4: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone ux560z4
inet 172.25.4.6 netmask fffffc00 broadcast 172.25.7.255
QUESTIONS:
1. Has the bug been reported for Solaris 10 ?
2. Is a Solaris 10 patch available ?
3. Is there a work-around or other ideas to get SMTP working in a Solaris shared-ip zoned.
4. Exclusive-IP should fix it, but does that require a dedicated NIC per zone ?
Thank You,
KW

The CR you cite: 6640675
was fixed in S10 over a year ago. You'll need a contract to get the patch.

Non-global zone devices

We are currently trying to port an application from a Solaris 9 server to a branded Solaris 9 zone on a T5220. The application accesses the /dev/fb devises which link to the screen card device. We cant get the zone to see the devices. Is this possible? Does anyone have any comments or suggestions?
Regards
Howard

Blocking signature link in response #1.
db
Michele_Vecchiato wrote:
Hi,
I do not think is supported[1], but try this:
You configure yuor Solaris 9 Branded zone and «add device»
global-zone# zonecfg -z myWHOLEzone
zonecfg:myWHOLEzone> add device
zonecfg:myWHOLEzone:device>set match=/dev/fb
zonecfg:myWHOLEzone:device>end
zonecfg:myWHOLEzone>verify
zonecfg:myWHOLEzone>commit
global-zone#
global-zone# zoneadm -z myWHOLEzone reboot
global-zone# zlogin myWHOLEzone "ls -lart /dev/fb"
1.< [http://docs.sun.com/app/docs/doc/820-4490/gfjbk?a=view|http://docs.sun.com/app/docs/doc/820-4490/gfjbk?a=view] >
HTH
Michele

Non-global zone network configuration

Hi,
Zones are a new thing for me so please excuse me if this is a basic query... I have recently jumpstarted a system using a jumpstart script that was developed by somebody else. It creates two non-global zones and configures their network interfaces.
I have unplumbed one of the virtual interfaces for a particular zone because the IP address it was using is actually being used by another system on the network. However, when I reboot the zone, the interface is re-assigned the same IP address again. The IP address in question is not in /etc/hosts on any of the zones, and in the non-global zones the "hostname.<interface>" files do not exist at all. Also, the IP address is not in sysidcfg in any of the zones.
So basically, interface e1000g0:2 is being assigned an IP address that was configured by the jumpstart script, so perhaps the jumpstart script has placed that IP address in some file that is read when the zone is booting. I have even checked rc scripts just in case but I cannot find the IP address anywhere. Would anybody please be able to tell me where the configuration information could be coming from in this scenario (nsswitch.conf specifies only files).
Thank you in advance...

its in the zone config.
zonecfg -z <zone in question> info
it should list a net address and physical device. you can then use:
zonecfg -z <zone in question>
from here you can remove the net statements, or change the address if you want to keep using the net card in your zone.

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.

Ifconfig nxge2 external ethernet card on global zone

Similar Messages

Maybe you are looking for